資料庫優化是系統工程，最終需要對作業系統、硬體、網路、應用架構有整體理解。雖然局部調校也能見效，但基礎架構設計 (Schema、索引、分區、分庫分表) 決定效能上限，參數調校只能逼近上限。
| 瓶頸類型 | 特徵 | 理論極限 | 優化方向 |
|---|---|---|---|
| 磁碟搜尋 | 磁頭移動尋找資料塊 | 現代磁碟 < 10ms，~100 IOPS | 資料分散多磁碟、SSD/NVMe、增加快取 |
| 磁碟讀寫傳輸 | 定位後連續讀寫 | 10-20 MB/s (HDD)，500+ MB/s (SSD) | 多磁碟並行 (RAID)、壓縮、順序讀寫 |
| CPU 週期 | 資料在記憶體中運算 | 受限於核心數、主頻 | 減少不必要運算、向量化、並行查詢 |
| 記憶體頻寬 | CPU 快取與主記憶體交換 | 現代系統極少成瓶頸 | 減少資料搬移、緊湊資料結構 |
診斷順序：iostat (磁碟) → vmstat (記憶體/CPU) → top (進程) → 慢查詢日誌 (SQL)。
NULL 不報錯啟示：不可依賴資料庫做資料驗證，必須在應用層寫入前完成檢核。
sql-bench 目錄，Perl + DBI 撰寫，單執行緒測最小執行時間/*! ... */ 註釋包裹，其他 DB 視為註釋忽略 (如 REPLACE INTO)當效能 > 精確一致性 (如 Web 高峰期)：
MySQL 內建替代方案：Query Cache (5.1+) — 自動快取 SELECT 結果，應用透明，大幅簡化架構。詳見手冊 5.11 章。
啟示：預計算彙總表 + 動態報表生成 + 直連分析，以空間換時間，支援大資料量即時查詢。
sql-bench 修改適配https://osdb.sourceforge.net)https://jeremy.zawodny.com/mysql/super-smack) — 可壓垮系統，**僅限測試環境**GRANT：無表/欄位權限 → 跳過 tables_priv/columns_priv 檢查SELECT BENCHMARK(1000000, 1+1);
-- P4 400MHz: 0.32 秒完成 100 萬次加法
-- 用途：比較函數/運算子相對速度，定位表達式熱點所有內建函數已高度優化，BENCHMARK 適合驗證自定義函數或複雜表達式效能。
key_buffer_size、innodb_buffer_pool_size、連接數、快取EXPLAIN 指導、避免全表掃描、善用覆蓋索引優化無終點，只有在特定業務、資料、硬體條件下的「足夠好」。建立度量體系，比單點調校更有價值。
