数据库在高并发场景下出现慢查询，核心问题往往不是硬件不够，而是索引设计不合理加上慢日志没被有效利用。解决这个问题的关键路径是：先通过慢查询日志定位具体的瓶颈SQL，再针对执行计划分析索引覆盖情况，最后结合业务场景做索引的增删调整和查询改写。下面我把这套完整的方法论拆开来讲，每一步都给你具体的操作方法和判断标准。
一、高并发下为什么索引会失效或不够用
高并发意味着短时间内大量请求同时打到数据库，每条SQL都在争抢锁资源和I/O带宽。这时候如果索引设计有问题，问题会被成倍放大。常见的索引失效场景有这么几种：第一，联合索引的最左前缀原则没遵守，比如你建了(a,b,c)的联合索引，但查询条件只有b和c，索引直接跳过；第二，对索引列做了函数运算或者隐式类型转换，比如where DATE(create_time) = '2024-01-01'，这会导致索引失效；第三，使用了like '%xxx'这种左模糊查询，B+树根本没法走；第四，索引选择性太低，比如性别字段只有男女两个值，建索引反而增加维护开销，优化器会直接忽略它。高并发下这些问题会让全表扫描频繁发生，每一次全表扫描都意味着大量的磁盘I/O和锁等待，系统吞吐量直线下降。
二、慢查询日志的开启与关键参数配置
慢查询日志是定位问题的第一手资料，不开它等于蒙着眼睛修车。MySQL中开启慢查询日志的核心命令如下：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log'; SET GLOBAL log_queries_not_using_indexes = 'ON';
这里long_query_time设为1秒是个比较合理的起点，高并发场景下建议设为0.5秒甚至更低，因为在高并发环境中，1秒的查询已经算很慢了。log_queries_not_using_indexes这个参数一定要打开，它会把没走索引的查询单独记录下来，帮你快速发现那些"裸奔"的SQL。另外建议把min_examined_row_limit设为100，避免记录太多扫描行数少但实际影响不大的查询，减少日志噪音。
三、慢日志分析的具体方法和工具
拿到慢日志之后，不要直接用眼睛看，数据量大的时候根本看不过来。推荐用mysqldumpslow这个自带工具做初步聚合分析：
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
这条命令会按查询时间排序，取前10条最慢的SQL。参数-s t表示按总时间排序，-t 10表示取前10条。更实用的是按平均时间排序：
mysqldumpslow -s at -t 10 /var/log/mysql/slow.log
除了mysqldumpslow，还有pt-query-digest这个Percona工具，它能做更细粒度的分析，包括按指纹聚合、按用户聚合、按数据库聚合，还能生成可视化报告。对于高并发场景，我建议重点关注三类SQL：第一类是执行次数最多的慢查询，哪怕单次不算特别慢，但乘以并发量之后就是灾难；第二类是扫描行数远大于返回行数的查询，说明索引效率极低；第三类是锁等待时间长的查询，这类往往涉及表锁或行锁竞争。
四、通过EXPLAIN解读执行计划找到索引问题
定位到具体的慢SQL之后，用EXPLAIN命令看执行计划是必做的步骤。重点看这几个字段：type列如果出现ALL，说明全表扫描，必须优化；key列显示NULL说明没用到索引；rows列的值如果很大，说明扫描的行数多；Extra列如果出现Using filesort或Using temporary，说明有额外的排序或临时表操作，这在高并发下非常消耗资源。一个典型的优化前的执行计划可能是这样的：
+----+-------------+-------+------+---------------+------+---------+------+--------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+------+--------+-------+ | 1 | SIMPLE | orders| ALL | NULL | NULL | NULL | NULL | 500000 | Using where | +----+-------------+-------+------+---------------+------+---------+------+--------+-------+
type是ALL，key是NULL，rows是50万，这就是典型的全表扫描。优化后应该变成：
+----+-------------+-------+-------+---------------+----------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+----------+---------+------+------+-------+ | 1 | SIMPLE | orders| ref | idx_user_time | idx_user_time | 8 | const| 120 | NULL | +----+-------------+-------+-------+---------------+----------+---------+------+------+-------+
type变成ref，key有了具体的索引名，rows降到120，这就是有效优化的标志。
五、高并发场景下的索引优化策略
索引优化不是越多越好，高并发下索引太多会导致写性能下降，因为每次INSERT、UPDATE、DELETE都要维护索引。具体策略有这几点：第一，优先优化高频查询的索引，低频查询不要为了它单独建索引；第二，善用覆盖索引，让查询的字段都包含在索引中，避免回表操作，比如select id,name from users where age=25，如果建了(age,name,id)的联合索引，这条查询就不需要回表；第三，对于范围查询后的字段，索引可能失效，比如where age>20 and city='北京'，如果索引是(age,city)，city部分可能用不上，这时候要调整索引顺序为(city,age)；第四，考虑使用前缀索引，对于很长的varchar字段，比如url字段，可以只索引前20个字符，节省空间；第五，对于写入非常频繁的表，可以考虑延迟建索引或者在低峰期批量建索引。
六、查询改写的实用技巧
有时候索引已经建好了，但SQL写法不对照样慢。几个实用的改写技巧：把大的IN查询拆成多个小批量查询，避免一次性锁太多行；把子查询改成JOIN，MySQL对JOIN的优化通常比子查询更成熟；避免在WHERE中对字段做运算，把计算移到等号右边，比如where create_time >= '2024-01-01' and create_time < '2024-02-01'替代where MONTH(create_time)=1；分页查询时用延迟关联替代大偏移量，比如先通过索引查到ID，再JOIN回原表取数据：
SELECT o.* FROM orders o INNER JOIN (SELECT id FROM orders WHERE status=1 ORDER BY id LIMIT 100000, 20) t ON o.id = t.id;
这种写法避免了直接OFFSET 100000带来的大量无用扫描。
七、监控与持续优化机制
索引优化不是一次性的工作，业务在变、数据量在涨，索引策略必须跟着调整。建议建立一套监控机制：用Prometheus加Grafana监控数据库的慢查询数量、QPS、连接数、锁等待时间等核心指标；每周定期跑一次慢日志分析，看有没有新出现的慢SQL；每次上线新功能前，review相关SQL的执行计划；对于数据量超过千万级的表，考虑分库分表或者读写分离来从架构层面降低单库压力。同时要注意，索引优化和查询优化是互补的，不能只靠索引解决所有问题，有时候业务层面的缓存策略、异步处理、批量操作同样重要。
八、总结
数据库高并发场景下的性能问题，本质上是资源竞争和执行效率的问题。慢查询日志是你的眼睛，EXPLAIN是你的诊断工具，索引优化和查询改写是你的手术刀。不要迷信某一个技巧，要形成"监控发现问题→日志定位SQL→执行计划分析→索引和查询双管齐下优化→验证效果→持续监控"的闭环。这套方法论不管是MySQL、PostgreSQL还是其他关系型数据库，核心逻辑都是通用的。把这个闭环跑通，高并发下的数据库性能问题基本都能控制住。
