MySQL索引心得

場景分析

訂單表

CREATE TABLE test_innodb.torder (
  `id` int(11) NOT NULL,
	order_no varchar(100) NOT NULL,
	order_status varchar(100) NOT NULL,
	order_create_time DATETIME NOT NULL,
	order_amount BIGINT NOT NULL，
	PRIMARY KEY (`id`)
)
ENGINE=InnoDB
DEFAULT CHARSET=utf8mb4
COLLATE=utf8mb4_general_ci;
複製代碼

查詢需求

• 查詢最近（30天）內某個訂單狀態的全部訂單
• 統計處於某個訂單狀態的全部訂單
• 根據交易單號查詢訂單的狀態

索引定義 KEY order_status-order_no (order_status, order_no), KEY order_status-order_create_time (order_status, order_create_time), UNIQUE KEY order_no (order_no) USING BTREE

市民表

CREATE TABLE `tuser` (
  `id` int(11) NOT NULL,
  `id_card` varchar(32) DEFAULT NULL,
  `name` varchar(32) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  `ismale` tinyint(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB
複製代碼

查詢需求

1. 根據市民身份證號查詢全部信息
2. 根據市民的身份證號查詢他的姓名

索引定義 KEY id_card (id_card), KEY name_age (name,age)

優化原則：

1. 最左匹配原則

最左匹配原則的含義是，Mysql匹配索引時按照聯合索引的最左 N 個字段，或者是字符串索引的最左 M 個字符。

若是能經過新增聯合索引、調整聯合索引的順序達到減小索引的效果，那就能夠優先考慮這個順序。

2. 覆蓋索引

覆蓋索引和核心原理很簡單，就是避免查詢過程當中再去經過主鍵索引搜索樹，減小回表次數，也就是減小磁盤IO訪問。

若是增長覆蓋索引能匹配到高頻需求，能夠優先考慮創建這個索引，同時要注意的是索引增長後第一會增大空間的消耗，其次會下降插入數據的性能（必定程度上經過讀寫分離可解決），但通常業務場景下上面兩點是能夠忍受的。

3. 索引下推

MySQL 5.6 引入的索引下推優化（index condition pushdown)， 能夠在索引遍歷過程當中，對索引中包含的字段先作判斷，直接過濾掉不知足條件的記錄，減小回表次數。

這個優化原則能夠類比覆蓋索引的原則來判斷，根據具體SQL分析具體優化的表現。