MySQL索引优化实战：慢SQL排查与高性能索引设计

誓死追随苏子敬

1. MySQL索引优化实战：从慢SQL排查到索引设计

作为一名长期与MySQL打交道的开发者，我处理过数百个性能问题案例，其中80%的慢查询都与索引使用不当有关。今天我将系统梳理索引优化的核心方法论，包含慢SQL排查、执行计划解读、索引设计原则等实战经验，这些都是面试中高频出现的问题，也是实际工作中必须掌握的技能。

提示：本文所有案例基于MySQL 8.0版本，部分特性在低版本可能表现不同

1.1 慢SQL排查三板斧

1.1.1 开启慢查询日志

慢查询日志是排查性能问题的第一道防线。我通常使用动态设置方式（无需重启服务）：

sql复制-- 开启慢日志记录（生产环境建议长期开启）
SET GLOBAL slow_query_log = ON;

-- 设置慢查询阈值（单位：秒，根据业务特点调整）
SET GLOBAL long_query_time = 1; 

-- 记录未使用索引的查询（重要！）
SET GLOBAL log_queries_not_using_indexes = ON;

-- 日志文件路径（建议单独挂载高速磁盘）
SET GLOBAL slow_query_log_file = '/var/lib/mysql/mysql-slow.log';

配置后，所有执行时间超过long_query_time的SQL都会被记录。建议配合pt-query-digest工具分析日志，它能自动统计最耗时的查询类型。

1.1.2 EXPLAIN执行计划深度解析

拿到慢SQL后，EXPLAIN是分析执行计划的核心工具。以下是需要重点关注的字段及其实际意义：

type字段（访问类型，性能从优到劣）

const：通过主键或唯一索引直接定位单行
eq_ref：多表join时，对前表每行只匹配后表的一行（主键/唯一索引关联）
ref：使用普通索引或唯一索引前缀匹配，可能返回多行
range：索引范围扫描（BETWEEN、IN、>等操作）
index：全索引扫描（比ALL快，但仍有优化空间）
ALL：全表扫描（必须优化的信号）

key_len计算原理
每个索引字段的存储长度计算公式：

INT：4字节
BIGINT：8字节
VARCHAR(n)：n * 字符集系数（utf8mb4=4） + 长度标识（1-2字节）
NULL标志位：1字节（如果字段允许NULL）

例如联合索引(a INT, b VARCHAR(20))：

a部分：4字节
b部分：20*4 + 1 = 81字节
总长度：4 + 81 = 85字节

1.1.3 实时性能诊断

除了慢日志，这些命令能实时捕捉性能问题：

sql复制-- 查看当前运行线程
SHOW PROCESSLIST;

-- 查看锁等待情况
SELECT * FROM sys.innodb_lock_waits;

-- 查看索引统计信息
SHOW INDEX FROM table_name;

2. 索引失效的七大陷阱与规避方案

2.1 类型隐式转换

经典案例：手机号字段定义为VARCHAR但用数字查询

sql复制-- 索引失效
SELECT * FROM users WHERE phone = 13800138000;

-- 正确写法（参数与字段类型一致）
SELECT * FROM users WHERE phone = '13800138000';

经验：所有字符串类型字段比较时，参数必须显式加引号

2.2 函数操作索引列

sql复制-- 索引失效
SELECT * FROM orders WHERE DATE_FORMAT(create_time,'%Y-%m') = '2023-01';

-- 优化方案（使用范围查询）
SELECT * FROM orders 
WHERE create_time >= '2023-01-01' 
AND create_time < '2023-02-01';

2.3 最左前缀原则实践

假设有联合索引(a,b,c)：

sql复制-- 有效：a、a,b、a,b,c
WHERE a=1 AND b=2 AND c=3

-- 部分有效：a,c（只用到了a）
WHERE a=1 AND c=3

-- 无效：b,c
WHERE b=2 AND c=3

2.4 范围查询后的索引失效

sql复制-- 只能用到a,b索引（c失效）
SELECT * FROM table WHERE a=1 AND b>2 AND c=3;

-- 优化方案：调整查询顺序或索引顺序
ALTER TABLE table ADD INDEX idx_a_c_b(a,c,b);

3. 高性能索引设计准则

3.1 区分度计算与索引顺序

计算字段区分度的标准方法：

sql复制SELECT 
  COUNT(DISTINCT column_name)/COUNT(*) AS selectivity
FROM table_name;

选择策略：

区分度>0.3：适合作为索引首列
0.1~0.3：视情况考虑
<0.1：通常不适合单独建索引

3.2 覆盖索引优化技巧

覆盖索引能减少90%以上的回表操作。设计原则：

包含WHERE条件中的所有字段
包含SELECT需要的所有字段
适当冗余高频查询字段

示例：

sql复制-- 原始查询
SELECT id, name, status FROM users WHERE phone='13800138000';

-- 最优索引（覆盖所有查询字段）
ALTER TABLE users ADD INDEX idx_phone_cover(phone, name, status);

3.3 索引合并与索引跳跃扫描

MySQL 8.0新特性：

索引合并：对多个单列索引做OR条件的合并
跳跃扫描：即使不满足最左前缀，也能利用索引

sql复制-- MySQL 8.0可能使用跳跃扫描
SELECT * FROM table WHERE b=2 AND c=3;

4. InnoDB索引原理深度解析

4.1 B+树 vs B树核心差异

通过一个实际案例说明：假设存储1000万条记录，每页16KB

B树存储特点：

非叶子节点存储数据：每页约存储100个键值+数据指针
树高度：约5层（100^5=1亿）
范围查询：需要在不同层级来回跳转

B+树存储特点：

非叶子节点纯索引：每页可存储500个键值+指针
树高度：约3层（500^3=1.25亿）
范围查询：叶子节点链表顺序访问

4.2 联合索引存储结构

以(a,b,c)联合索引为例：

code复制叶子节点内容：
| a值 | b值 | c值 | 主键值 |
|-----|-----|-----|-------|
| 1   | 10  | 'A' | 1001  |
| 1   | 10  | 'B' | 1002  |
| 1   | 20  | 'C' | 1003  |
...

排序规则：

首先按a值排序
a相同按b排序
b相同按c排序

5. COUNT性能优化实战

5.1 四种COUNT方式原理对比

执行过程差异：

COUNT(*)：遍历最小二级索引，不取值
COUNT(1)：与COUNT(*)完全等价
COUNT(主键)：遍历聚簇索引，取主键值但不计算
COUNT(列)：必须检查列值是否为NULL

5.2 优化方案

大表COUNT优化：

sql复制-- 使用覆盖索引（比主键索引更快）
SELECT COUNT(*) FROM table USE INDEX(idx_cover);

-- 使用汇总表（实时性要求不高时）
CREATE TABLE stats (
  table_name VARCHAR(100),
  row_count BIGINT,
  PRIMARY KEY(table_name)
);

6. 索引维护与监控

6.1 索引碎片整理

定期检查索引碎片率：

sql复制SELECT 
  table_name,
  index_name,
  ROUND(data_free/(data_length+index_length)*100,2) AS frag_ratio
FROM information_schema.tables
WHERE data_free > 0;

整理方法：

sql复制-- Online DDL方式（MySQL 5.6+）
ALTER TABLE table_name ENGINE=InnoDB;

-- pt-online-schema-change工具（不影响业务）
pt-online-schema-change --alter="ENGINE=InnoDB" D=database,t=table

6.2 索引使用情况监控

通过performance_schema查看索引命中率：

sql复制SELECT 
  object_schema,
  object_name,
  index_name,
  rows_selected,
  rows_inserted,
  rows_updated,
  rows_deleted
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL;