SQL性能优化

一、为什么压测问题经常落到 SQL

在很多 Java 后端系统里，真正拖慢接口的不是业务代码，而是数据库。

典型表现：

QPS 提不上去
RT 很高
CPU 不一定高

继续分析后发现：

某条 SQL 很慢
数据库连接池被占满
锁等待严重

所以：

SQL 优化，是后端性能优化里非常核心的一环。

二、什么是慢 SQL

慢 SQL 并不是固定“几秒以上才算慢”，而是：

在当前业务场景下，显著拖慢接口响应的 SQL。

例如：

列表接口要求 100ms 内返回
但 SQL 就占了 80ms

这种 SQL 即使没到 1 秒，也已经值得关注。

三、常见 SQL 性能问题

后端项目里最常见的问题包括：

没有合适索引
走错索引
全表扫描
返回数据太多
复杂 join 过多
排序和分页不合理

这些问题在数据量上来后会被迅速放大。

四、先学会看执行计划

SQL 优化最基本的动作是看执行计划。

常用工具：

EXPLAIN

你要重点关注：

是否命中索引
是否全表扫描
扫描行数是否过大
是否有临时表
是否有文件排序

这一步比“凭感觉优化”更可靠。

五、索引为什么重要

索引的本质，是减少扫描成本。

没有索引时：

数据库可能要扫很多行

有合适索引时：

数据库可以快速定位目标数据

但要注意：

有索引不代表一定快
索引建错也没用
索引太多会影响写入

六、Java 后端常见错误写法

1. 查询条件没走索引

例如：

对索引字段做函数处理
隐式类型转换

2. 一次查太多列

例如：

select *

很多时候并不需要所有字段。

3. 分页过深

例如：

limit 100000, 20

这类深分页在大表上成本很高。

七、锁和事务也会拖慢 SQL

有些慢并不是查询本身复杂，而是被锁住了。

例如：

长事务不提交
更新热点行
大量并发修改同一记录

表现为：

SQL 等待时间长
RT 偶发飙高
压测越高并发越明显

八、一个简单优化案例

假设你有一条订单查询：

select * from orders where user_id = ? and status = ?

压测时发现耗时很高。

查看执行计划后发现：

没有命中合适索引

优化方向通常是：

建联合索引
只查必要字段
控制返回记录数

然后再压测对比结果。

九、SQL 优化不是只看单条语句

真实系统里，还要考虑：

SQL 调用频率
并发访问模式
是否命中缓存
是否和写操作竞争

有些 SQL 单次不算慢，但因为调用量巨大，也会成为瓶颈。

十、后端工程师的实用建议

如果你是 Java 后端开发，做 SQL 优化时建议：

先抓最慢、最频繁的 SQL
先看执行计划，再改索引
先减少扫描量，再谈复杂优化
优化后一定重新压测验证

十一、总结

SQL 性能优化最核心的原则是：

先定位
再解释
最后验证

对压测来说，一条慢 SQL 经常足以拖垮整条链路。
所以只要你能把 SQL 问题分析清楚，很多接口性能问题就已经解决了一半。