首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
您现在的位置: 程式碼之家 >> 數據庫知識 >  >> MySQL 資料庫 >> MySQL 綜合教學

MySQL 建表與索引使用規範詳解:從命名規範到效能優化

     編輯:MySQL 綜合教學

MySQL 建表與索引使用規範詳解

良好的資料庫設計規範是系統穩定、高效運行的基石。本文整理了 18 條核心建表與索引規範,涵蓋欄位設計、索引策略、命名規範及 EXPLAIN 執行計劃分析,並附贈實戰 FAQ 案例分析。

一、核心建表與索引 18 條軍規

  1. 非空預設:所有欄位必須設為 NOT NULL 並指定預設值,避免 NULL 導致的索引失效與統計偏差。
  2. 必要時可空:業務確需 NULL 時,仍須給明確預設值(如空字串),不可留 NULL。
  3. 外鍵必索引:關聯欄位(等價外鍵)必須建立索引,否則 JOIN 效能極差。
  4. 跨表一致性:關聯欄位的類型、長度、非空屬性、預設值必須完全一致,否則無法使用索引關聯。
  5. 單表單索引:單條 SQL 僅能使用單表的一個索引;多欄索引最多 15 個欄位。
  6. 優選高選擇性:多索引可選時,MySQL 傾向使用「掃描行數最少」且「唯一值密度最高」的索引。
  7. 最左前綴原則:複合索引 (a,b,c) 等同於建立 (a)、(a,b)、(a,b,c) 三個索引,查詢需遵循最左前綴匹配。
  8. LIKE 索引條件:LIKE 'abc%' 可用索引,LIKE '%abc' 或 LIKE '%abc%' 會全表掃描。
  9. COUNT 效能:無 WHERE 時 COUNT(*) 比 COUNT(col) 快(MyISAM 直接讀元資料);有 WHERE 時 COUNT(*) 更快。
  10. AND 條件索引:多個 AND 條件需屬於同一複合索引且包含第一欄;若為單列索引,僅用選擇性最高者。
  11. OR 條件索引:每個 OR 條件都必須有可用索引,否則全表掃描。
  12. ORDER BY 索引序:排序欄位需屬於同一索引,且排序方向一致(全 ASC 或全 DESC)。
  13. GROUP BY 索引序:分組欄位需引用同一索引且索引按序儲存鍵值。
  14. JOIN 索引覆蓋:ON 和 WHERE 中的關聯/過濾欄位均需建立合適索引。
  15. 強制索引:全表掃描效率低時,可用 FORCE INDEX 強制走索引。
  16. 定期 ANALYZE:執行 ANALYZE TABLE 更新關鍵字分佈統計資訊。
  17. 慢查詢分析:定期檢查 Slow Log,配合 EXPLAIN 發現優化空間。
  18. 關鍵參數調優: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;

四、EXPLAIN 執行計劃深度解析

在 SELECT 前加 EXPLAIN 即可查看執行計劃,重點關注以下欄位:

  • type:連接類型,效能由高到低:system > const > eq_ref > ref > range > index > ALL。
  • possible_keys / key:可能用到的索引 vs 實際用到的索引。
  • key_len:索引長度,越短越好(不損失精度前提下)。
  • rows:預估掃描行數,越少越好。
  • Extra:Using filesort、Using temporary 為危險信號,需優化。

五、實戰 FAQ:為何加了索引卻不走?

場景: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 生效。
核心準則:索引目的是「極致縮小結果集」,選擇性低(如性別欄位)的索引無意義甚至有害。

  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved