高手檢查與調優 MySQL 效能方法 (五)：SQL 複雜度、配置參數、架構擴展

接續前四篇，本文聚焦 SQL 寫法過於複雜、配置錯誤、機器資源耗盡三大進階調優方向。

2. SQL 寫法過於複雜

涉及 GROUP BY、多表聯查等特殊功能時，用 EXPLAIN (或 DESC) 分析執行計畫。筆者環境複雜 SQL 較少，暫無通用建議，核心原則：拆解大 SQL、避免臨時表、善用覆蓋索引。

3. 關鍵配置參數調優

其餘參數保持預設即可。提醒：配置非效能問題主因；穩定性與資料正確性永遠優先於效能。

4. 機器資源耗盡：架構層面擴展

1. MySQL 主從同步：主寫從讀分流。但增加程式複雜度、易引發資料不一致，筆者傾向謹慎使用。
2. 前端加入緩存 (Squid/Varnish/Redis)：命中率高時效果顯著，解決並發壓力。推薦前端反向代理緩存，避免業務邏輯層引入複雜緩存邏輯。
3. 應用拆分 + 多庫部署：業務拆解為多獨立服務，各接專屬資料庫。若有跨庫需求，可維護一個「全量庫」同步彙總，或定時同步全量庫。
4. 暴力多庫輪詢：全量複製 N 個資料庫，寫入時同步執行 N 次，讀取輪詢。雖笨拙但比主從同步更安全 (無複寫延遲/衝突風險)。

架構調優無銀彈，需根據業務特點、團隊能力、成本預算在一致性、可用性、分區容錯 (CAP) 中權衡。