索引設計原則 選對索引類型： 範圍查詢（>, <, BETWEEN）、ORDER BY/GROUP BY 多 → 叢集索引 多欄常一起查詢、各有重

腳本核心功能 逐庫匯出（mysqldump --opt --lock-all-tables） 自動排除系統庫（information_schema、mysql

用戶名與密碼體系 MySQL 用戶名獨立於作業系統帳號，最長 16 字元（Unix 通常 8 字元）。 密碼經 PASSWORD() 非可逆加密，與 Unix

核心觀念篇 1. 讀懂執行計劃 執行計劃是優化器依據 SQL 與統計資訊產生的查詢方案。 關鍵在於：SQL 是否清晰表達意圖？統計資訊是否最新？ 定期 UPD

問題根源：LIMIT 深分頁掃描機制 LIMIT 10000, 20 意味著掃描 10,020 行、丟棄前 10,000 行、回傳後 20 行。 EXPLAIN

七大 SQL 注入攻擊類型 1. 未正確過濾轉義字元 使用者輸入 a OR t=t 導致 WHERE name = a OR t=t 恆真，繞過驗證。更嚴重者

環境規劃 角色IP版本 Master192.168.1.22CentOS 5.2 / MySQL 5.1.35 Slave192.168.1.33Cen

INSTR 函數語法與行為 INSTR(欄位名, 字串) 回傳字串在欄位內容中的位置（從 1 起算），找不到回傳 0。大小寫不敏感。 實戰範例 1. 依關鍵

核心優化原則 在確保功能正確的前提下，SQL 查詢優化的核心在於：減少資料庫存取次數、縮小掃描範圍、最小化結果集、降低網路負載。以下原則能幫助你撰寫高效能的查詢

前言：重用不只是存儲過程 許多開發者將「可重用 SQL」等同於「存儲過程」，實則視圖、內建函數、使用者定義函數 (UDF) 同樣重要，甚至更輕量。本文示範如何組

為什麼選擇 mysqldump？ 官方原生工具、無額外依賴、跨平台支援。 邏輯備份（SQL 文本），可視、可編輯、跨版本遷移相容性佳。 支援單表、單庫、全例、

核心結論先行 WHERE 條件書寫順序對查詢效能無實質影響（CBO/RBO 模式皆然）。優化器會根據統計資訊、索引、連接順序自動決定最佳存取路徑，而非按書寫順序

核心優化原則速覽 善用索引加速遍歷：叢集索引適合範圍/排序/分組；複合索引覆蓋高頻查詢；索引非越多越好，維護成本隨寫入線性增長。 海量查詢避免格式轉換：應用層

前言：系統化排查慢查詢 慢查詢成因跨越應用、SQL、索引、架構、硬體、作業系統、網路七大層面。本文將 50 個成因歸類為 7 大維度，並提供對應優化對策與工具鏈

一、儲存引擎選型：InnoDB vs MyISAM 實戰取捨 場景推薦實戰經驗補充 高併發讀寫、事務必要、資料一致性關鍵InnoDB預設首選。注意：極高頻批量

核心定位差異 維度InnoDBMyISAM 事務支援✅ 完整 ACID、行鎖、MVCC❌ 無事務、表鎖 外鍵✅ 支援❌ 不支援 崩潰恢復✅ Redo/Undo

前言：MySQL 生態的大分裂時代 2008 年 Sun 收購 MySQL AB，2009 年 Oracle 收購 Sun，MySQL 核心團隊紛紛出走，催生出

隨機查詢核心挑戰 資料庫無原生「隨機排序」功能，需借助隨機函數產生亂數欄位再排序。不同資料庫函數名稱、語法差異大，且大量資料排序效能極差，需根據資料量選擇策略。

實驗背景與目的 Oracle 資料庫中綁定變數是效能調優標準動作，能減少硬解析、提升快取命中、防止 SQL 注入。MySQL 5.1+ 透過 mysqli_st

案例背景：為何選擇 MySQL Cluster 某證券公司 OA 系統初期規劃 30 萬用戶在線，後需求激增至 50 萬並發且皆有寫入需求。原 Master-M