MySQL慢查询引发网站宕机的排查与修复

故障现象与服务响应异常

通常慢查询只会导致应用响应变慢，但在本次案例中，一个执行时间高达70秒的SQL直接导致了整个网站瘫痪。通过观察应用服务器（goods_service）的监控指标，发现了以下严重的异常症状：

• CPU使用率长期维持在100%以上
• 进程堆栈信息无法正常Dump，必须使用强制参数 `jstack -F pid` 才能获取信息
• Dump出的内存信息显示，所有线程均处于 BLOCKED 阻塞状态
• 内存回收日志显示频繁进行Full GC（FGC），间隔仅约10秒
• JVM内存占用严重超过分配上限

初步判断，慢查询返回了海量数据（最大791万行），导致应用层在解析结果时内存瞬间暴涨，触发频繁的Full GC并最终导致OOM或假死。

SQL分析与索引统计误区

首先检查MySQL慢查询日志中的核心SQL：

SELECT ss_id, ss_sa_id... FROM js_sgoods_sku
WHERE ss_si_id = 0 AND ss_status > 0
ORDER BY ss_orderid DESC, ss_av_fid ASC;

第1步：查看执行计划

使用 EXPLAIN 分析上述SQL：

+----+-------------+---------------+------+---------------+----------+---------+-------+---------+-----------------------------+
| id | select_type | table         | type | possible_keys | key      | key_len | ref   | rows    | Extra                       |
+----+-------------+---------------+------+---------------+----------+---------+-------+---------+-----------------------------+
| 1 | SIMPLE      | js_sgoods_sku | ref  | ss_si_id      | ss_si_id | 4       | const | 9516091 | Using where; Using filesort |
+----+-------------+---------------+----------+---------+-----------------------------+

虽然使用了索引 ss_si_id，且类型为 ref，但预估扫描行数高达951万。直觉上认为索引可能不合理或未命中，因此检查表结构与索引定义：

KEY ss_si_id (ss_si_id, av_zid, av_fid) USING BTREE

字段 ss_si_id 关联的是商品信息的ID，理论上离散度应该很高。然而，查看索引统计信息后发现了问题：

执行 Show index from js_sgoods_sku 查看基数（Cardinality）：

ss_si_id 的基数量远小于主键，且尝试执行 ANALYZE TABLE 更新统计信息后，数值依然偏低甚至波动。这说明MyISAM/InnoDB的统计采样并未准确反映数据的极端分布情况，或者统计数据本身就是基于部分采样的估算，存在误导性。

第2步：验证数据分布真相

为了证实猜想，直接统计 ss_si_id = 0 的记录数：

SELECT COUNT(*) FROM js_sgoods_sku WHERE ss_si_id = 0;
-- 结果: 7994788
-- 总记录数: 19048617
-- 占比: ~41.9%

真相令人震惊：表中近42%的数据其 ss_si_id 均为0。这意味着所谓的“索引查找”实际上几乎是在扫描半个表的数据量，加上排序操作，彻底耗尽了系统资源。

内存溢出根因分析

连接数据库与应用层后发现因果链条： 1. SQL条件 ss_si_id = 0 无法有效利用索引减少I/O。 2. MySQL向应用层返回了约790万行的数据结果集。 3. Java应用（goods_service）在反序列化并加载这数百万条记录进入内存时，Heap Space迅速耗尽。 4. JVM尝试垃圾回收（FGC）但无效，最终导致All Threads Blocked和CPU飙升，服务完全不可用。

解决方案与实施步骤

第1步：紧急止血（DBA层面）

由于DB端负载已飙升至50+，且连接数激增，首要任务是停止该慢查询的持续消耗。使用 pt-kill 工具主动Kill掉正在执行的该慢查询进程，防止DB本身先一步崩溃。

第2步：代码层修复（研发层面）

既然根因是查询了无意义的默认值 0，应在应用逻辑或SQL层面进行拦截。修改后的SQL增加了过滤条件，直接从根源屏蔽此类低效请求：

-- 修改后的SQL逻辑
SELECT ... 
FROM js_sgoods_sku
WHERE ss_si_id <> 0 AND ss_status > 0
-- 注意：此处应根据实际业务逻辑调整，确保不再传递或查询 ss_si_id=0 的情况

在应用层增加前置校验：若入参为 0 或无效ID，直接返回空集合，不再发起数据库查询。

第3步：限制结果集大小

即便修复了逻辑，也应养成给查询加上 LIMIT 的习惯，防止因前端展示需求误取全表数据导致内存溢出。

总结

本次故障的核心教训在于：不要在SQL中查询Default值或缺乏区分度的字段。当某个字段的某个值占据极大比例（如本案中的41%）时，即使创建了索引，优化器也可能选择全表扫描范围过大的路径，或在应用层处理海量返回结果时发生内存溢出。开发人员在编写涉及关联ID的查询时，务必排除业务上的非法默认值，并在DBA的配合下进行定期的慢查询审计。

以上就是MySQL的一条慢SQL查询导致整个网站宕机的详细解决过程与分析，更多关于SQL性能优化与数据库故障排查的资料请关注本站其它相关文章！