点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
部分页面加载时间显著延长，订单查询模块会出现请求超时，严重影响用户体验。登录数据库实例（端口3306），检查CPU使用率高达95%，磁盘I/O持续处于高负载状态，而内存使用率正常。数据库服务状态无异常，但活跃连接数从日常平均30激增至1200，大量会话处于“Sending data”状态。通过SHOW FULL PROCESSLIST发现多个会话在执行以下SQL时耗时超过60秒：SELECT order_id, user_id, product_info, total_amount
FROM orders
WHERE create_time BETWEEN'2023-08-01'AND'2023-08-31'
ANDstatus = 'PAID'
ORDERBY create_time DESC
LIMIT1000;
进一步使用EXPLAIN分析该查询，发现orders表的create_time和status字段均无索引，导致执行计划为全表扫描（type=ALL）。检查orders表结构，确认create_time和status字段未建立联合索引。表数据量已达21万条，全表扫描引发大量磁盘I/O与CPU计算资源争用。由于orders表缺失关键查询字段的索引，高并发场景下全表扫描操作堆积，导致CPU与I/O资源耗尽，进而引发连接数激增与查询阻塞。1）终止部分长时间运行的慢查询会话，临时缓解资源压力2）为orders表的create_time和status字段添加联合索引ALTERTABLE orders ADDINDEX idx_createtime_status (create_time, status);
1）增大innodb_buffer_pool_size至物理内存的70%，提升缓存命中率2）设置max_connections=2000，避免连接数突增导致服务不可用1）建立周期性索引审查机制，针对高频查询字段及时补全索引2）使用工具（如Percona Toolkit）定期分析慢查询日志并自动化推荐索引1）加强CPU、I/O及活跃连接数的实时监控，设置阈值告警（如CPU>80%触发告警）2）启用performance_schema跟踪全表扫描操作，提前发现潜在风险要求所有新增SQL需通过EXPLAIN验证执行计划，禁止无索引的大表查询上线。
