優化四大原則 結果集極小（本案例僅 1 行），優化信心足 驅動表選擇關鍵，觀察 EXPLAIN rows 估算 梳理關聯關係，確保關聯欄位有索引 用 STRA

案例一：ORDER BY 主鍵 + WHERE 過濾的陷阱 問題 SQL = 2.00 ORDER BY tran_id DESC LIMIT 10; 表結構

效能災難現場 = 2011-10-07 00:00:00 ) GROUP BY i_id; 表 70 萬行，子查詢結果含大量重複 i_id。MySQL 將子查

問題場景 單表 10GB+，統計 UV 查詢： SELECT COUNT(DISTINCT nick) FROM user_access; 雖有 nick 索引

觸發警告的場景 對 VARCHAR(512) 的 url 欄位建立索引時出現警告： ALTER TABLE article ADD INDEX ind_arti

安裝環境與前置準備 作業系統：SUSE Linux Enterprise Server 10 資料庫版本：MySQL 5.0.22（原始碼包 mysql-5.

版本變更背景 MySQL 5.1.46 引入 find_shortest_key 函數，改變覆蓋索引掃描的索引選擇邏輯。核心變化：InnoDB 叢集主鍵不再被優

深分頁效能痛點 某論壇回覆表 reply_0004 單執行緒擁有 123 萬條資料，索引為 (thread_id, deleted, id)。查詢最後一頁： S

優化背景與問題現象 在處理大數據量的差集查詢時，NOT IN 子查詢常因執行計劃退化為全表掃描而導致效能極差。本文記錄一個真實案例：原查詢耗時 35 分鐘，優化

sysbench 是模組化、跨平台、多執行緒的基準測試工具，支援 CPU、磁碟 IO、記憶體、執行緒、資料庫（OLTP）等測試模式。本文詳述從源碼編譯到 OLT

InnoDB 存儲長列（BLOB/TEXT/VARCHAR>255）會觸發 Off-page 機制：溢出資料獨佔獨立頁面，聚集索引僅存 20 字節指標，導

實測索引策略與提交頻率對 InnoDB 批量寫入（30 萬行）的影響，得出明確量化結論指導實務優化。 測試環境 表結構：id INT AUTO_INCREM

從庫複寫報錯 SAVEPOINT 6e86db84_14847168f19__8000 語法錯誤。經排查，識別字元串中含 e 且後接數字，被解析器誤判為科學記號

單看 Seconds_Behind_Master (SBM) 判斷從庫延遲往往不準。本文分析 SBM 計算邏輯缺陷，提出基於 Binlog 序號與位置的三步精準

需要批量終止特定使用者、長時間運行或鎖定的 MySQL 連線時，四種方法各有適用場景。 方法一：information_schema.processlist

大偏移 LIMIT 935500, 10 導致查詢從 0.05 秒暴增至 2.39 秒。本文提出「子查詢先取 ID」與「INNER JOIN 關聯 ID」兩種改

MySQL 中 ORDER BY RAND() 或 WHERE ... = RAND() 會導致全表掃描、臨時表排序，效能極差。本文通過 7 組實測對比，證明將

mysqldump --where / -w 可指定備份條件，但單雙引號嵌套與函式呼叫極易出錯。本文實測避坑指南。 基本用法 mysqldump --sing

執行 SELECT DATE_FORMAT(...) > TIMEDIFF(...) 報錯 Illegal mix of collations (utf8

MySQL 5.1 對整型溢出採用靜默回繞（wrap-around），5.5+ 預設啟用嚴格模式報錯攔截。版本混用（主 5.1、從 5.5）會導致複寫中斷或資料