优化SQL有什么方法

SQL优化，关键在语句。
早期靠经验，费时费力。
现用AI工具，效率翻倍。
LECCOSQLExpert，AI帮手，优化一绝。
学写好SQL，用它就对了。

QPS提升10倍的sql优化

说白了，索引字段类型不一致是导致CPU1 00%的罪魁祸首，修好这个问题就能让QPS从4 3 7 飙升到4 6 1 0这事复杂在很多人会忽略SQL传参类型和表定义的不匹配，以为只是小延迟问题。

先说最重要的，去年我们跑的那个项目，4 c1 6 G的MySQL实例在0点和1 2 点流量高峰期CPU直接干烧。
当时以为是连接池不够，加到5 0个空闲连接、2 00个总数还是没辙。
后来发现不对劲，用EXPLAIN一查，原来查询参数site_id是整型传进去，表里却是VARCHAR(2 4 0)，导致idx_road_site这个组合索引完全失效。
当你看到EXPLAIN显示Using where而不是Using index的时候，其实问题就出在这——索引根本没被用到，CPU全靠算力硬抗。
这个点很多人没注意，说实话挺坑的。

另外一点，修复方案特别简单，就是把SQL传参site_id的类型改成String。
我们直接改了MyBatis的@Param注解，用String类型替代原来的默认值。
修完之后CPU利用率立马从1 00%掉到2 0%以下，图上能看出优化后4 6 1 0QPS都跑得稳稳当当。
而且省了钱，本来准备买8 核CPU的，最后直接取消订单，硬件成本降下来了。

我一开始也以为CPU爆是因为缓存问题，调了半天本地缓存大小和有效期都没用，后来才定位到索引失效这个细节。
等等，还有个事，表设计上site_id用VARCHAR(2 4 0)可能不太合理，现在虽然能用了，但长期看还是建议改成整型，这样能减少类型不匹配的潜在风险。

我觉得值得试试的优化方向是，代码审查的时候特别关注SQL传参类型和表结构的匹配度，别让这种低级错误混进去。
还有，监控告警要设置到位，CPU利用率突增和慢SQL必须实时告警，不然问题发现时CPU可能已经烧焦了。
压测验证也别省，模拟真实流量跑一遍，确保优化方案靠谱。

可以使用limit 1进行SQL优化的两个场景

结论：用limit 1 优化查询。

查存在：用limit 1 代替count()，效率高。

查唯一：用limit 1 避免全表扫描。

时间：2 02 3 -1 0-2 7
地点：不确定
数字：1
吐槽：count()太坑了，效率低。