優化資料庫結構

最佳化資料大小

→ 減少磁碟寫入和讀取的資料量

→ 在查詢執行期間主動處理其內容時主記憶體較少

→ 產生較小的索引，可以更快地處理

表格列

• 盡可能使用最有效（最小）的資料類型
• 如果可能，將列宣告為 NOT NULL → 更好地使用索引並消除測試每個值是否為 NULL 的開銷。

索引

• 表的主索引應盡可能短
• 僅建立提高查詢效能所需的索引。索引有利於檢索，但會減慢插入和更新操作。
• 搜尋列的組合→建立複合索引
• 索引中的第一個欄位應該是重複最多的欄位→以獲得更好的索引壓縮。

連結

• 在具有相同資料類型的不同表中聲明具有相同資訊的欄位→相同資料類型
• 保持列名簡單，

正常化

• 通常情況下，盡量保持所有資料不冗餘
• 如果速度比磁碟空間和保留多個資料副本的維護成本更重要

最佳化資料類型

• 對於可以表示為字串或數字的唯一 ID 或其他值，→ 數字值可以比相應的字串以更少的位元組存儲，傳輸和比較它們速度更快，佔用的記憶體更少。
• 比較不同欄位中的值時，盡可能宣告具有相同字元集和排序規則的欄位 → 避免字串轉換
• 對於大小小於 8KB 的欄位值，請使用二進位 VARCHAR 而非 BLOB。 GROUP BY 和 ORDER BY 子句可以產生暫存資料表，如果原始資料表不包含任何 BLOB 資料列，這些暫存資料表可以使用 MEMORY 儲存引擎。
• 如果一個表包含字串列並且不經常訪問→拆分到另一個表並連接→當MySQL從一行中檢索任何值時，它會讀取包含該行所有列（可能還有其他相鄰行）的資料塊。保持每行較小，僅包含最常用的列，可讓每個資料區塊容納更多行。
• 當您使用隨機產生的值作為 InnoDB 表中的主鍵時，請在其前面加上升序值（例如當前日期和時間）（如果可能）。
• 對於具有多個列的表，為了減少不使用 BLOB 列的查詢的記憶體需求，請考慮將 BLOB 列拆分為單獨的表，並在需要時使用聯接查詢引用它
• • 由於檢索和顯示BLOB 值的效能需求可能與其他資料類型有很大不同，因此您可以將BLOB 特定表 放在不同的儲存裝置上，甚至是 單獨的儲存設備上資料庫實例。例如，要檢索 BLOB 可能需要大量順序磁碟讀取，這比 SSD 裝置更適合傳統硬碟。
• 您可以將列值的雜湊值儲存在單獨的列中，對該列建立索引，然後在查詢中測試雜湊值，而不是測試非常長的文字字串是否相等。 （使用 MD5() 或 CRC32() 函數產生雜湊值。）

最佳化SQL語句

我們發現分兩步驟分析效能不佳的查詢很有用：

• 了解您的應用程式檢索的資料是否超出您的需求。這通常意味著它訪問了太多行，但也可能訪問了太多列。
• 找出MySQL 伺服器 分析的行數是否超出其需求。

優化 SELECT 語句

• 避免在謂詞中使用函數
• 避免在謂詞開頭使用萬用字元 (%)
• 僅在必要時使用 DISTINCT 和 UNION