1. 从一条致命SQL到索引优化的生存指南上周五临下班前我随手提交了一段自以为简单的更新语句结果直接导致生产库CPU飙到100%。周一晨会上经理拿着服务器监控图表微笑着问我周末有空一起去爬山吗——这个惊悚的开场引出了今天要分享的SQL优化血泪史。事情源于一个没有走索引的WHERE条件。我在用户表上执行了UPDATE users SET status1 WHERE TRIM(username)admin这个TRIM函数让本该走索引的查询变成了全表扫描。2000万数据量的表被全部遍历数据库连接池瞬间撑爆。本文将用EXPLAIN工具带你深度复盘这个事故并分享如何避免成为爬山邀请函的接收者。2. SQL执行计划深度解析2.1 EXPLAIN工具全景解读EXPLAIN是MySQL提供的SQL诊断显微镜。当我给那条惹祸的SQL加上EXPLAIN前缀后看到了这样的死亡信号EXPLAIN UPDATE users SET status1 WHERE TRIM(username)admin;输出结果中typeALL和rows19876422这两个字段尤其刺眼意味着优化器选择了全表扫描需要检查1987万行记录。以下是关键字段的生存手册type列这是判断SQL生死的核心指标。从最优到最差依次是system const eq_ref ref range index ALL出现index特别是ALL时DBA的血压就会随服务器负载一起飙升。key列显示实际使用的索引。如果这里为NULL说明索引根本没被启用就像我的案例中因为TRIM函数导致索引失效。rows列估算需要检查的行数。当这个值超过1万时就该拉响警报超过百万就是灾难级别。2.2 索引失效的七宗罪在我的事故中TRIM函数是罪魁祸首但这只是索引失效的常见原因之一。以下是更多死亡陷阱隐式类型转换WHERE user_id 1001user_id是整型左模糊查询WHERE username LIKE %admin%OR条件不当WHERE age18 OR name张三单字段OR可用IN替代使用NOT条件WHERE status ! 1联合索引违反最左前缀索引是(a,b,c)但条件只有WHERE b1对索引列运算WHERE YEAR(create_time)2023优化器误判表数据分布不均导致优化器放弃索引血泪教训任何对索引列的函数处理都会使索引失效包括TRIM()、LOWER()、DATE()等常见函数。必须先将函数处理移到应用层。3. 索引优化实战手册3.1 拯救那条死亡SQL针对我的事故SQL有这些优化方案方案一改写查询条件-- 先查出无空格用户名对应的ID SELECT id FROM users WHERE usernameadmin; -- 再用ID精确更新 UPDATE users SET status1 WHERE id IN (123,456);方案二新增函数索引MySQL 8.0ALTER TABLE users ADD INDEX idx_trim_username ((TRIM(username)));方案三存储冗余字段ALTER TABLE users ADD COLUMN username_clean VARCHAR(32) GENERATED ALWAYS AS (TRIM(username)) STORED; CREATE INDEX idx_username_clean ON users(username_clean);3.2 索引设计黄金法则三星索引原则一星WHERE条件包含所有等值查询列二星ORDER BY列包含在索引中三星SELECT列被索引完全覆盖联合索引排列口诀等值查询放左边范围查询放右边 高频字段靠前放排序字段跟着来索引维护策略单表索引不超过5个单个索引字段不超过3列定期使用ANALYZE TABLE更新统计信息4. 慢查询急救工具箱4.1 实时诊断技巧当数据库突然变慢时快速执行这些命令-- 查看当前运行中的SQL SHOW PROCESSLIST; -- 查看锁等待情况 SELECT * FROM sys.innodb_lock_waits; -- 紧急终止问题会话 KILL [connection_id];4.2 长期监控方案配置MySQL慢查询日志my.cnfslow_query_log 1 slow_query_log_file /var/log/mysql/mysql-slow.log long_query_time 1 log_queries_not_using_indexes 1配合pt-query-digest工具分析pt-query-digest /var/log/mysql/mysql-slow.log slow_report.txt5. 进阶优化策略5.1 索引下推技术MySQL 5.6引入的ICP(Index Condition Pushdown)技术可以在索引遍历时就进行条件过滤。通过EXPLAIN看到Using index condition提示时说明该优化生效-- 需要联合索引(username, age) EXPLAIN SELECT * FROM users WHERE username LIKE 张% AND age 18;5.2 覆盖索引优化当查询所需列都包含在索引中时能获得10倍以上的性能提升-- 建立覆盖索引 ALTER TABLE users ADD INDEX idx_covering (username, status, create_time); -- 查询可以完全使用索引 EXPLAIN SELECT username, status FROM users WHERE username LIKE 张% ORDER BY create_time;6. 避坑指南那些年我们踩过的雷分页查询深坑-- 错误示范偏移量大时极慢 SELECT * FROM users LIMIT 1000000, 20; -- 正确姿势 SELECT * FROM users WHERE id 1000000 LIMIT 20;COUNT(*)的误解MyISAM的COUNT(*)很快是因为有表级计数InnoDB需要实时计算大数据量时应考虑缓存计数OR的替代方案-- 低效写法 SELECT * FROM products WHERE category电子 OR price1000; -- 高效改写 SELECT * FROM products WHERE category电子 UNION ALL SELECT * FROM products WHERE price1000 AND category!电子;那次事故后我养成了这些职业习惯所有UPDATE/DELETE语句先用SELECTEXPLAIN验证超过10万行的表操作必须有人复核在测试库用真实数据量进行性能测试重要操作前先备份哪怕只是WHERE条件现在当看到typeALL的执行计划时我眼前还是会浮现经理那个意味深长的微笑。记住每个DBA职业生涯中都有一条差点让他去爬山的SQL。
MySQL索引优化实战：从致命SQL到高效查询
发布时间：2026/7/22 3:06:01
1. 从一条致命SQL到索引优化的生存指南上周五临下班前我随手提交了一段自以为简单的更新语句结果直接导致生产库CPU飙到100%。周一晨会上经理拿着服务器监控图表微笑着问我周末有空一起去爬山吗——这个惊悚的开场引出了今天要分享的SQL优化血泪史。事情源于一个没有走索引的WHERE条件。我在用户表上执行了UPDATE users SET status1 WHERE TRIM(username)admin这个TRIM函数让本该走索引的查询变成了全表扫描。2000万数据量的表被全部遍历数据库连接池瞬间撑爆。本文将用EXPLAIN工具带你深度复盘这个事故并分享如何避免成为爬山邀请函的接收者。2. SQL执行计划深度解析2.1 EXPLAIN工具全景解读EXPLAIN是MySQL提供的SQL诊断显微镜。当我给那条惹祸的SQL加上EXPLAIN前缀后看到了这样的死亡信号EXPLAIN UPDATE users SET status1 WHERE TRIM(username)admin;输出结果中typeALL和rows19876422这两个字段尤其刺眼意味着优化器选择了全表扫描需要检查1987万行记录。以下是关键字段的生存手册type列这是判断SQL生死的核心指标。从最优到最差依次是system const eq_ref ref range index ALL出现index特别是ALL时DBA的血压就会随服务器负载一起飙升。key列显示实际使用的索引。如果这里为NULL说明索引根本没被启用就像我的案例中因为TRIM函数导致索引失效。rows列估算需要检查的行数。当这个值超过1万时就该拉响警报超过百万就是灾难级别。2.2 索引失效的七宗罪在我的事故中TRIM函数是罪魁祸首但这只是索引失效的常见原因之一。以下是更多死亡陷阱隐式类型转换WHERE user_id 1001user_id是整型左模糊查询WHERE username LIKE %admin%OR条件不当WHERE age18 OR name张三单字段OR可用IN替代使用NOT条件WHERE status ! 1联合索引违反最左前缀索引是(a,b,c)但条件只有WHERE b1对索引列运算WHERE YEAR(create_time)2023优化器误判表数据分布不均导致优化器放弃索引血泪教训任何对索引列的函数处理都会使索引失效包括TRIM()、LOWER()、DATE()等常见函数。必须先将函数处理移到应用层。3. 索引优化实战手册3.1 拯救那条死亡SQL针对我的事故SQL有这些优化方案方案一改写查询条件-- 先查出无空格用户名对应的ID SELECT id FROM users WHERE usernameadmin; -- 再用ID精确更新 UPDATE users SET status1 WHERE id IN (123,456);方案二新增函数索引MySQL 8.0ALTER TABLE users ADD INDEX idx_trim_username ((TRIM(username)));方案三存储冗余字段ALTER TABLE users ADD COLUMN username_clean VARCHAR(32) GENERATED ALWAYS AS (TRIM(username)) STORED; CREATE INDEX idx_username_clean ON users(username_clean);3.2 索引设计黄金法则三星索引原则一星WHERE条件包含所有等值查询列二星ORDER BY列包含在索引中三星SELECT列被索引完全覆盖联合索引排列口诀等值查询放左边范围查询放右边 高频字段靠前放排序字段跟着来索引维护策略单表索引不超过5个单个索引字段不超过3列定期使用ANALYZE TABLE更新统计信息4. 慢查询急救工具箱4.1 实时诊断技巧当数据库突然变慢时快速执行这些命令-- 查看当前运行中的SQL SHOW PROCESSLIST; -- 查看锁等待情况 SELECT * FROM sys.innodb_lock_waits; -- 紧急终止问题会话 KILL [connection_id];4.2 长期监控方案配置MySQL慢查询日志my.cnfslow_query_log 1 slow_query_log_file /var/log/mysql/mysql-slow.log long_query_time 1 log_queries_not_using_indexes 1配合pt-query-digest工具分析pt-query-digest /var/log/mysql/mysql-slow.log slow_report.txt5. 进阶优化策略5.1 索引下推技术MySQL 5.6引入的ICP(Index Condition Pushdown)技术可以在索引遍历时就进行条件过滤。通过EXPLAIN看到Using index condition提示时说明该优化生效-- 需要联合索引(username, age) EXPLAIN SELECT * FROM users WHERE username LIKE 张% AND age 18;5.2 覆盖索引优化当查询所需列都包含在索引中时能获得10倍以上的性能提升-- 建立覆盖索引 ALTER TABLE users ADD INDEX idx_covering (username, status, create_time); -- 查询可以完全使用索引 EXPLAIN SELECT username, status FROM users WHERE username LIKE 张% ORDER BY create_time;6. 避坑指南那些年我们踩过的雷分页查询深坑-- 错误示范偏移量大时极慢 SELECT * FROM users LIMIT 1000000, 20; -- 正确姿势 SELECT * FROM users WHERE id 1000000 LIMIT 20;COUNT(*)的误解MyISAM的COUNT(*)很快是因为有表级计数InnoDB需要实时计算大数据量时应考虑缓存计数OR的替代方案-- 低效写法 SELECT * FROM products WHERE category电子 OR price1000; -- 高效改写 SELECT * FROM products WHERE category电子 UNION ALL SELECT * FROM products WHERE price1000 AND category!电子;那次事故后我养成了这些职业习惯所有UPDATE/DELETE语句先用SELECTEXPLAIN验证超过10万行的表操作必须有人复核在测试库用真实数据量进行性能测试重要操作前先备份哪怕只是WHERE条件现在当看到typeALL的执行计划时我眼前还是会浮现经理那个意味深长的微笑。记住每个DBA职业生涯中都有一条差点让他去爬山的SQL。
