前言：臨時表是複雜查詢分解、中間結果緩存的利器 面對超大表多次掃描，將所需子集提取至臨時表，後續查詢在小表上執行，可大幅降低 IO 與 CPU。本文系統講解建立

前言：分區表達式並非任意 SQL，嚴格受限於白名單 MySQL 5.1 分區表的 PARTITION BY 子句僅允許使用 19 個特定函數，且 FLOOR()

前言：分區表與唯一約束的「硬性綁定」規則 MySQL 5.1 分區表強制要求：**每個唯一索引 (含主鍵) 的所有欄位，必須包含分區鍵欄位**。違反即報錯 ER

前言：大表分表遷移的核心挑戰——如何縮短停機窗口 單表達到 800 萬~1000 萬行時，分表勢在必行。單純 INSERT ... SELECT ... WHE

前言：行鎖是高併發 OLTP 的基石，但非銀彈 InnoDB 行鎖粒度最細、併發度最高，卻伴隨記憶體開銷大、全表掃描災難、鎖升級風險等副作用。本文系統剖析行鎖優

前言：表鎖是 MyISAM 並發控制的唯一手段 除 InnoDB/BDB 外，所有引擎採用表級鎖。理解 LOCK TABLES、鎖優先級、並發插入機制、爭用優化

前言：鎖是資料庫並發控制的核心基礎設施 MySQL 不同存儲引擎支援不同粒度鎖：MyISAM/MEMORY 表鎖、BDB 頁鎖、InnoDB 行鎖。本文系統剖析

前言：單表能存多少資料？取決於引擎與作業系統 常見誤區以為 MySQL 單表限制 4GB/2TB。實則：MyISAM 理論 64PB、InnoDB 共享表空間

前言：理解表類型演進，洞察引擎設計哲學 MySQL 歷經 ISAM → MyISAM → InnoDB 演進，每種表類型代表一代存儲引擎設計理念。本文系統梳理六

前言：引擎選擇決定了資料庫的「性格」 MyISAM 與 InnoDB 是 MySQL 兩大核心存儲引擎，前者主打讀密集、後者主打寫密集與事務。本文從架構、鎖粒度

前言：COUNT 是最常用卻最易誤解的聚合函數 網上關於 COUNT(*) 與 COUNT(col) 效能的說法眾說紛紜。本文通過實測數據（7.9 萬行測試表）

前言：多欄位多關鍵字檢索的常見痛點 需求：單表 magazine 有 title、tag、description 三欄，用戶輸入「關鍵字1 關鍵字2」以空格分隔

前言：ENUM 是「單選一」的極致壓縮儲存 ENUM 將固定字典映射為連續整數 (1,2,3...)，僅佔 1-2 字節，查詢極快。但其「序號與字面值雙重語義」

前言：SET 是「多選一」的高效位掩碼實現 SET 型別允許單欄位儲存 0~64 個預定義成員的任意組合，底層以位元組合儲存，極省空間且查詢高效。本文通過實戰演

前言：字串批量替換是資料清洗高頻需求 許多初學者遇到「將所有文章的『解決』替換為『解放』」時，會寫腳本逐行讀取、替換、寫回，效率極低且易併發衝突。MySQL 內

前言：精準掌握儲存開銷，做容量規劃與型別選型依據 每個欄位型別佔用的磁碟空間直接影響表體積、記憶體使用、備份時間、複製延遲。本文彙總 MySQL 官方文檔規範的

前言：DDL 操作是資料庫演進的日常 業務迭代中，欄位新增、刪除、重命名、型別變更、順序調整、索引維護屢見不鮮。本文彙總 MySQL ALTER TABLE 全

前言：時間欄位型選擇直接影響查詢效能 大數據量下，時間範圍查詢（ XX）極其高頻。是用 INT 存 Unix 時間戳，還是原生 DATETIME？本文在 MyS

前言：索引是查詢效能的「導航儀」 MySQL 提供六大索引類型，各有適用場景與限制。本文系統梳理定義語法、特性、優缺點、選型建議，並針對複合索引最左前綴、全文索

前言：選對型別，省空間、避坑、提效能 表結構設計的核心在於「欄位型別與約束」。合理選型能大幅減小表體積、避免數值溢位、日期格式錯誤、字串截斷等莫名其妙的 Bug