資料庫效能優化是系統工程，涵蓋架構設計、索引建模、SQL 重寫、參數調優、硬體資源規劃等多個維度。本文從表結構定義、索引優化、查詢改寫三大核心面向，提煉出經實戰驗證的優化法則與避坑指南。
TINYINT 足夠時別用 INT，VARCHAR(20) 夠用別設 VARCHAR(255)CHAR 減少分頁分裂NULL 需額外位元組標記、複雜化索引統計、阻礙查詢優化器判斷ENUM 或 SET，儲存 1-2 字節 vs 字串長度| 類型 | 儲存長度 | 備註 |
|---|---|---|
| TINYINT | 1 字節 | -128~127 / 0~255 |
| SMALLINT | 2 字節 | |
| MEDIUMINT | 3 字節 | |
| INT / INTEGER | 4 字節 | |
| BIGINT | 8 字節 | |
| FLOAT | 4 字節 | 單精度 |
| DOUBLE | 8 字節 | 雙精度 |
| DECIMAL(M,D) | M+2 / D+2 字節 | 精確小數，金融必用 |
| DATE | 3 字節 | 1000-01-01 ~ 9999-12-31 |
| DATETIME | 8 字節 | 不帶時區 |
| TIMESTAMP | 4 字節 | 1970-2038，帶時區轉換 |
| CHAR(M) | M 字節 | 定長，右側空格填充 |
| VARCHAR(M) | 實際長度+1/2 字節 | 變長，<255 用 1 字節長度前綴 |
| TEXT/BLOB | 實際長度+2 字節 | 大物件，離頁儲存 |
| ENUM | 1-2 字節 | 取決於枚舉值數量 |
| SET | 1-8 字節 | 取決於成員數量 |
(a,b,c) 支援 a、a,b、a,b,c 查詢，不支援 b、c、b,c| # | 場景 | 索引策略 | 原理 |
|---|---|---|---|
| 1 | GROUP BY 子句 | 依欄位出現順序建複合索引 | 避免 filesort，直接利用索引有序性 |
| 2 | DISTINCT 查詢 | 依欄位出現順序建複合索引 | 同 GROUP BY，利用索引去重 |
| 3 | WHERE 多個 AND 條件 | 依條件出現順序建複合索引 | 最左前綴匹配，單次索引掃描 |
| 4 | WHERE 多個 OR 條件 | 對區分度最高欄位建單列索引 | OR 通常導致全表掃描，單列索引可用 index_merge |
| 5 | 內/外連接查詢 | 對關聯欄位建索引 | 驅動表關聯欄位有索引，被驅動表關聯欄位必須有索引 |
| 6 | 主鍵額外加 UNIQUE | 勿重複建立 | 主鍵本身已是唯一索引，多餘 |
| 7 | 被索引欄位 | 盡量 NOT NULL | NULL 值統計複雜，可能導致優化器誤判 |
| 8 | 寫入密集型表 | 極度克制索引數量，避免複合/唯一索引 | 每個索引都是寫入放大源頭 |
| 9 | 覆蓋索引 | SELECT 欄位全包含在索引中 | 避免回表，極大提升查詢速度 |
| 10 | 前綴索引 | 長字串取前 N 字元建索引 | INDEX idx_name(name(10)) 平衡空間與區分度 |
所有優化前後必須對比 EXPLAIN 輸出，重點關注：
type：system/const > eq_ref > ref > range > index > ALL（由好到壞）key：實際使用的索引rows：預估掃描行數（越小越好）Extra：Using index（覆蓋索引）、Using where、Using temporary、Using filesort（需優化）LIMIT 1000000, 10 → 子查詢先取主鍵再回表：SELECT * FROM t WHERE id > (SELECT id FROM t LIMIT 1000000,1) LIMIT 10WHERE DATE(create_time) = '2024-01-01' → WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'，保留索引可用性%keyword 無法用索引，keyword% 可用INNER/LEFT JOIN 或 WITH CTE（8.0+）WHERE a=1 OR b=2 → SELECT * FROM t WHERE a=1 UNION SELECT * FROM t WHERE b=2，各走各的索引INDEX(a,b,c) 對應 WHERE a=1 AND b=2 AND c=3WHERE price * 1.1 > 100 → WHERE price > 100/1.1，使欄位單獨出現在運算子一側long_query_time=1 + pt-query-digest 定期審視 Top N 慢查詢MySQL 優化無銀彈，唯有「正確的表結構 + 精準的索引 + 合理的 SQL + 持續的觀測」組合拳。建議建立優化閉環：慢查詢收集 → EXPLAIN 分析 → 索引/結構調整 → 效果驗證 → 固化規範，讓優化成為團隊基因而非個人英雄行為。
