良好的資料庫設計規範是系統穩定、高效運行的基石。本文整理了 18 條核心建表與索引規範,涵蓋欄位設計、索引策略、命名規範及 EXPLAIN 執行計劃分析,並附贈實戰 FAQ 案例分析。
LIKE 'abc%' 可用索引,LIKE '%abc' 或 LIKE '%abc%' 會全表掃描。COUNT(*) 比 COUNT(col) 快(MyISAM 直接讀元資料);有 WHERE 時 COUNT(*) 更快。FORCE INDEX 強制走索引。ANALYZE TABLE 更新關鍵字分佈統計資訊。key_buffer_size、query_cache_size(全域);sort_buffer_size(Session,建議 ≤4MB)。| 物件 | 前綴 | 格式範例 | 長度限制 |
|---|---|---|---|
| 主鍵 | pk_ | pk_user_order | ≤30 字元 |
| 外鍵 | fk_ | fk_order_user | ≤30 字元 |
| 唯一索引 | uni_ | uni_user_email | ≤30 字元 |
| 普通索引 | ind_ | ind_user_status | ≤30 字元 |
命名統一使用小寫英文單詞,過長時依表名縮寫規則縮寫。
-- 建立索引
CREATE INDEX ind_log_url ON logaudit_log(url);
-- 查看索引
SHOW INDEX FROM logaudit_log;
-- 刪除索引
DROP INDEX log_request_time ON logaudit_log;
在 SELECT 前加 EXPLAIN 即可查看執行計劃,重點關注以下欄位:
Using filesort、Using temporary 為危險信號,需優化。場景:10 萬筆資料,datetime 欄位
created_at有索引。
查詢:SELECT * FROM t WHERE created_at < '2010-01-20'
EXPLAIN 顯示 type=ALL,key=NULL。
根因:COUNT(*) 發現符合條件 6 萬筆(佔總量 60%),優化器判斷走索引需大量回表,不如全表掃描快。
解法:縮小範圍 BETWEEN '2009-12-06' AND '2010-01-20',符合條件僅幾百筆,type 變為 range,key 生效。
核心準則:索引目的是「極致縮小結果集」,選擇性低(如性別欄位)的索引無意義甚至有害。