（本文與 ID 178475 主題相同，此處提供不同切入點的精簡實戰版，側重「如何在生產環境快速落地」。）
-- 查詢：WHERE a=1 AND b=2 ORDER BY c
-- 最佳索引：INDEX idx_a_b_c (a, b, c)
-- 失效案例：WHERE b=2 （未用最左列 a）查詢只需掃描索引樹即可滿足，無需回表。`EXPLAIN` 出現 `Using index` 即命中。例：`SELECT id, name FROM users WHERE status=1` + `INDEX idx_status_name (status, name)`。
| 關鍵欄 | 優化解讀 |
|---|---|
| type | system/const > eq_ref > ref > range > index > ALL。目標至少達 ref。 |
| possible_keys / key | 可能用到的索引 vs 實際用到的。NULL 表示無索引可用。 |
| key_len | 實際用到的索引長度。判斷組合索引用了幾列。 |
| rows | 預估掃描行數。越小越好，配合 `filtered` 看過濾效率。 |
| Extra | Using index（覆蓋索引佳）、Using where（Server層過濾）、Using temporary（需優化）、Using filesort（排序未走索引）。 |
進階工具：`EXPLAIN FORMAT=TREE` (8.0.16+)、`EXPLAIN ANALYZE` 顯示實際耗時與迴圈次數。
| 參數 | 建議起始值 | 調整觀測指標 |
|---|---|---|
| innodb_buffer_pool_size | 物理記憶體 60-75% | Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests < 1% |
| innodb_log_file_size | 1-4 GB | 寫入延遲、檢查點頻率 |
| innodb_flush_log_at_trx_commit | 1（安全） / 2（高效） | 資料安全性 vs 寫入吞吐權衡 |
| max_connections | 應用峰值連線數 + 余量 | Threads_connected、Connection_errors_max_connections |
| table_open_cache | 4000+（高併發） | Opened_tables / Uptime > 2 時需調大 |
| sort_buffer_size / read_buffer_size | 256K-1M（每線程） | Sort_merge_passes、全表掃描頻率 |
| long_query_time | 1 秒 | 慢查詢日誌數量與品質 |
優化無終點，只有「當下足夠好」。建立度量、持續迭代，才是 DBA 的核心價值。
