高危SQL有哪些危害，如何防止高危SQL载入？

高危SQL往往是数据库性能灾难的根源，解决它的核心是学会识别慢查询、理解其执行计划，并掌握重写SQL与索引优化的实战方法。

到底是什么让SQL变成了高危SQL？

一个SQL语句从“能用”变成“高危”，通常不是语法错误，而是它在数据库内部引发的连锁反应，业内专家普遍认为，高并发场景下,一个糟糕的SQL足以拖垮整个数据库实例。

核心特征：不走索引与全表扫描

高危SQL的第一大特征就是不走索引，当执行计划中出现type: ALL或者Extra: Using where时，意味着数据库正在逐行扫描全表数据，如果表数据量达到百万级，哪怕只是查询几行数据,也可能消耗数秒甚至更久。

• 全表扫描：没有索引可用,只能暴力遍历。
• 索引失效：有索引，但查询条件写法导致优化器放弃使用，比如在索引列上使用函数、隐式类型转换。
• 回表过多：即使走了索引，但需要回表获取大量数据,依然可能成为慢查询。

实际场景：一个UPDATE引发的连锁阻塞

最常见的高危操作是大表上的UPDATE/DELETE，比如执行UPDATE orders SET status = 1 WHERE status = 0，如果这个表数据量很大，且status字段没有索引，这个语句会锁住大量行，导致后续的读写请求全部排队等待，数据库连接池迅速耗尽,最终业务系统崩溃。

如何精准定位高危SQL，避免被埋坑？

定位高危SQL不能靠猜，需要借助数据库自带的监控工具和日志系统。慢查询日志是第一个突破口。

慢查询日志的配置与读取

MySQL场景下,可以这样开启慢查询日志：

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; -超过1秒的SQL即为慢查询

打开日志后,查看记录：

mysqldumpslow -s t -t 10 /var/lib/mysql/hostname-slow.log

这条命令会按查询时间排序，列出最慢的10条SQL，核心要关注的是查询次数和平均耗时，那些出现频率高、单次执行慢的SQL,就是高危种子选手。

使用EXPLAIN命令分析执行计划

拿到可疑SQL后，立即执行EXPLAIN加EXTENDED分析：

EXPLAIN SELECT FROM orders WHERE order_no = '20250301001';

重点关注几个字段：

• type：从system到all，性能依次下降，出现ALL或index（全索引扫描）时,必须优化。
• rows：预计扫描的行数，这个数字越大,说明越需要优化。
• Extra：出现Using filesort或Using temporary，说明需要额外的排序或临时表,性能很差。

数据库性能监控的黄金指标

除了慢查询，还需要关注数据库的实时会话，使用SHOW FULL PROCESSLIST可以查看当前正在执行的SQL，重点关注Time列，如果某个SQL长时间处于Sending data或Creating sort index状态,它就是当前的高危嫌疑。

SQL重写与索引优化，实战解决高危SQL

发现问题只是第一步，修改SQL或添加索引才是解决问题的关键，对于大多数高危SQL，并不需要复杂的架构改造,而是通过调整写法或增加索引来解决。

索引添加的通用原则

• 高选择性列：过滤性好的列（如唯一ID、订单号）优先建索引。
• 复合索引：最左前缀原则，查询条件涉及多个列时,按区分度从高到低排列。
• 覆盖索引：查询的列全部在索引中，避免回表查询,这是最高效的优化手段。

常见的高危SQL实例与优化对比

以一个电商查询为例,原始SQL可能这样写：

SELECT FROM order_detail WHERE DATE(create_time) = '2025-03-01';

这条SQL的问题在于DATE(create_time)函数导致索引失效,优化后：

SELECT FROM order_detail WHERE create_time >= '2025-03-01 00:00:00' AND create_time < '2025-03-02 00:00:00';

这样可以直接利用create_time上的索引,性能提升显著。

分页查询优化

分页越往后越慢,典型高危SQL如：

SELECT FROM orders ORDER BY id LIMIT 100000, 20;

优化方案是使用延迟关联或子查询：

SELECT FROM orders INNER JOIN (SELECT id FROM orders ORDER BY id LIMIT 100000, 20) AS tmp ON orders.id = tmp.id;

这样内层子查询覆盖索引，只扫描索引,避免大量回表。

如何在不同场景下预防高危SQL

预防比事后处理更关键，在北京地区的大型互联网公司，通常会在代码审查环节加入SQL Reviewer，自动检测高危SQL模式。SQL优化服务费用看似不菲，但相比系统宕机造成的损失,这笔投入非常值得。

开发阶段的预防措施

• SQL审查：每一条要上线的SQL,必须经过DBA或自动化工具审核。
• 避免查询号：只查询需要的字段,减少回表压力。
• 控制JOIN表数量：超过3张表的JOIN，大概率需要优化,可以拆分查询或使用冗余字段。

运行时监控告警

建立一套监控体系，当日志中出现超过阈值的慢查询时，自动触发告警，可以结合ARMS或Prometheus等工具，监控数据库的慢查询数量和平均耗时，关注连接数和活跃会话数，一旦出现异常高峰,立即排查。

大表DDL操作的注意事项

在高并发业务中，直接在表上添加索引或修改表结构，可能会锁表造成长时间阻塞。

MySQL 5.6及以上版本提供了ALGORITHM和LOCK选项,可以控制锁表级别：

ALTER TABLE orders ADD INDEX idx_order_no (order_no), ALGORITHM=INPLACE, LOCK=NONE;

这可以在不阻塞读写的情况下完成索引添加，但要求主库压力不大,且磁盘空间足够。

高危SQL问题解答

问：一个SQL执行很慢，但EXPLAIN显示走了索引，为什么？

答：走了索引不代表性能一定好，如果索引区分度低，比如查询了表中大部分数据，数据库优化器可能认为走索引还不如全表扫描快，索引回表次数过多也会导致性能下降，此时应该检查Extra字段的Using index condition，如果出现Using where且回表次数多，考虑使用覆盖索引,即把查询字段和条件字段都包含在同一个索引中。

问：如何判断一个SQL语句是否需要优化？

答：核心标准是看它的执行频率和单次执行时间，如果一个SQL单次执行超过1秒，且每秒执行次数超过100次，那它就是一个高危SQL，必须立即优化，从数据库角度看，EXPLAIN中的rows字段扫描行数如果超过10万行，也属于高危，如果在大促场景下，这个阈值需要更严格,比如超过1万行就需要优化。

问：线上数据库出现大量慢查询，但业务不能停，怎么快速处理？

答：最快的应急方案是临时加索引，查看慢查询中涉及的表和条件列，如果条件列是status且没有索引，可以通过ALTER TABLE ... ADD INDEX ... ALGORITHM=INPLACE, LOCK=NONE在线添加索引，通常几分钟内可以生效，如果索引已经存在但失效，考虑修改SQL写法，避免函数或隐式转换，如果无法快速修改SQL，可以临时从主库切换到只读库分流，但这种方式治标不治本,事后必须找到根本原因。