前言
統一的開發規範是團隊協作效率與系統穩定性的基石。本文整理 35 條 MySQL 開發鐵律，涵蓋命名、設計、SQL 編寫、安全、運維等全生命週期，建議列入代碼審核清單。
一、命名與基礎規範 (1-4)
- 全小寫 + 下劃線：庫/表/欄位統一小寫，單詞間 `_` 分隔。避免 `lower_case_table_names` 參數導致跨平台大小寫敏感差異。
- 長度 ≤ 32 字符：雖支援 64 字符，但限制 32 字符利於識別、傳輸、工具兼容。
- 強制 InnoDB：5.5+ 預設引擎，支援事務、行鎖、崩潰恢復、熱備份、多核/SSD 優化。
- 禁用保留字：避免 `order`、`group`、`key` 等需反引號轉義，增加 SQL 複雜度與 Shell 腳本轉義地獄。
二、表結構設計規範 (5-13)
- 禁用分區表：分區鍵限制多、DDL/Sharding/單表恢復困難，建議業務層手動 Sharding。
- 非負數用 UNSIGNED：同位寬下範圍翻倍，如 `TINYINT UNSIGNED` 0-255 vs -128~127。
- IPv4 用 INT UNSIGNED：4 字節 vs `CHAR(15)` 15 字節，整數運算更快。用 `INET_ATON()`/`INET_NTOA()` 轉換。IPv6 用 `DECIMAL(39,0)` 或雙 `BIGINT`。
- TINYINT 代替 ENUM：ENUM 修改值需 DDL、數字值易混淆、內部實際儲存為整數。
- 大小寫敏感用 VARBINARY：無字符集開銷、比較更快、預設區分大小寫。
- INT(4) 只影響顯示寬度：儲存固定 4 字節，不限制範圍。應用層 (Java/Python) 無此功能。
- 時間類型精準選型：
- 年：`YEAR` (1 字節)
- 日期：`DATE` (3 字節)
- 精確到秒：優先 `TIMESTAMP` (4 字節，自動初始化/更新)；次選 `DATETIME` (8 字節)
- 全域 NOT NULL：NULL 需額外位圖標識、B+ 樹索引不存 NULL、聚合函數語義陷阱。用 0、空串、特殊值替代。
- 冷熱數據分離：大欄位 (TEXT/BLOB/JSON)、低頻欄位拆獨立表，提升緩存命中率、減少磁碟 I/O。
- 禁存明文密碼：鹽值 + 慢哈希 (bcrypt/Argon2/PBKDF2) 儲存，防字典攻擊/彩虹表。
- 必有主鍵，推薦 UNSIGNED AUTO_INCREMENT：無主鍵 InnoDB 產生隱藏 6 字節 RowID，定位困難、降低 Row 複寫效率。
三、索引設計規範 (14-19)
- 禁冗餘索引：`(a,b,c)` 覆蓋 `(a,b)`，後者為冗餘。用前綴索引平衡空間與效能。
- 禁重複索引：`PRIMARY KEY(a)` + `UNIQUE KEY(a)` 為重複，增加維護成本無收益。
- 低基數列禁建索引：如「性別」、「狀態」。全表掃描往往更快，索引反增 I/O。
- 善用覆蓋索引：Secondary Index 儲存 PK 值，回表代價大。`SELECT email, uid FROM user WHERE uid=xx` 可建 `INDEX(uid, email)` 避免回表。
- IN 代替 OR，值數 < 1000：MySQL 內部排序 IN 列表後範圍查找，效率高於 OR。
- 表字符集 UTF8MB4：統一通用、無轉碼亂碼風險，Emoji 需申請 `utf8mb4`。
四、SQL 編寫規範 (20-28)
- UNION ALL 代替 UNION：省去排序去重開銷。
- 禁 ORDER BY RAND()：生成偽列排序、產生磁碟臨時表。改用應用層隨機 PK 查詢。
- 分頁優化兩大模式：
- 模式一 (小結果集/複雜查詢)：`LIMIT M,N` 直接查全欄位。適用中間結果 < 1 萬行。
- 模式二 (大結果集/有覆蓋索引)：延遲關聯 `SELECT t.* FROM (SELECT id FROM t WHERE ... ORDER BY ... LIMIT M,N) a JOIN t ON a.id=t.id`。先走覆蓋索引取 PK，再回表，翻頁效能恆定。
- SELECT 只取必要欄位：減少網路/IO、利用覆蓋索引、結構變更不影響程式。
- 禁不確定函數：`NOW()`、`RAND()`、`SYSDATE()`、`CURRENT_USER()` 導致主從不一致、Query Cache 失效。
- 合理分庫分表策略：如「千庫十表」、「十庫百表」，利用多線程複寫特性。
- 批量 SQL 減少交互：`INSERT ... ON DUPLICATE KEY UPDATE`、`REPLACE INTO`、`INSERT IGNORE`、`INSERT INTO VALUES(),(),()`。
五、DDL 變更與進階規範 (29-35)
- 拆分複雜 SQL，避免大事務：簡單 SQL 利用 Query Cache、減少鎖表時間、利用多核 CPU。
- 同表多 ALTER 合併執行：`ALTER TABLE t ADD COLUMN b VARCHAR(10), ADD INDEX idx_aa(aa);` 避免多次鎖表重建。
- 禁存儲過程/觸發器/視圖/自定義函數：效能問題、未知 Bug、阻礙 DDL/Sharding/Scale Out，業務邏輯上移至應用層。
- 禁應用賬號擁有 SUPER 權限：導致 `read_only` 失效、難追蹤詭異問題。
- 上線變更必提交全量 SQL 供 DBA 審核：含 INSERT/UPDATE/DELETE，非僅 SELECT 需索引。
- 業務邏輯不入庫：資料庫為有狀態儲存層，邏輯上移至前端/中間層，實現邏輯與儲存分離。
- 建表語句規範範例：參考團隊統一 DDL 模板 (含註釋、引擎、字符集、索引命名規範)。
總結
這 35 條規範並非教條，而是無數線上故障總結出的經驗紅線。團隊應將其內化為代碼審核標準、CI/CD 檢查項、新人入職必讀文檔，從源頭杜絕低級錯誤，保障資料庫平穩演進。
