前言
2025年4月16日，天气阴，8点30刚出健身房，心里默念又是充满希望的一天✨
打开钉钉，一条@消息映入眼帘😱，感谢领导昨天晚上没有call🗽
昨天晚上 8点半，生产环境SQL占用cpu过高 🧨
问题分析
看到这个问题，我基本上已经定位到问题了。估计是 人大金仓 的 执行计划 和 服务器的 CPU 以及磁盘的性能存在问题！因为这个SQL 迁移之前也没问题的。
前两天也出现过
SQL超时的问题，还写了一篇文章: 小小的改动，竟然效率提高了1000倍这次的问题 按照道理 应该也是一样，因为join了多张表，同时SQL的执行计划走的是Loop join导致消耗了很多
cpu资源 。💀联系了研发经理之后，用工具测试了一下性能，新环境的 性能 粗略计算的性能只有原来环境的三分之一（但是配置比以前环境的都高）
连表查询kingbase 可能走 Nested Loop 进行连表，有时候不会走 hash join. 走 Nested Loop 加上join的表有好几个，因此导致导致消耗掉了大量的cup性能. 本篇文章就不带大家看执行计划了
今天早上同事把id的Integer改成bigint 居然就好了,而且这个 id没有做关联，只是在条件中用了where id is null,就没办法去看执行计划了
有兴趣的可以看之前的文章里面有执行计划分析
为什么Nested Loop如此消耗性能
-
什么是
Nested loop？翻译过来就是嵌套循环，如下MySql官网的距离说明
-
Nested loop时间复杂度知道嵌套循环之后，我们就可以大概估算出，在最极端的情况3表join的时间复杂度 为
O(r1 * r2 * r3),假设数量级在w的级别，10 * 1000 * 10000 = 1亿，可以看到数量不多的情况 使用Nested Loop也会出现上亿次的计算。
所以Nested loop 比较消耗cpu 资源的。mysql 官网nested-loop
虽然我用的是
kingbase，但是我有时候看一些文档，还是会去mysql、pg-sql看的，底层的这些核心算法逻辑，还是相通的。
如何解决Nested loop循环问题
数据库本身层面是如何优化的
- hash join 算法 （mysql）
✔MySQL（8.0.18 及更高版本）会尽可能的去使用hash 算法进行join。
✔MySQL 8.0.20block nested loop已经被移除，所以mysql 高版本使用loop循环的方式就更少。
所以 mysql 的高版本对于 多表join，性能还是比较好的。但是数据量大的话，join表多话，就需要关注性能问题了。文章推荐：在sql 中谨慎使用多表join
- merge join 、hash join （pgsql）
pgsql 对于join 来说，就有三种选择nested loop join、merge join、hash join，当连表如果查询使用的关系少于 geqo_threshold，会寻找最优的方式执行。
写法层面
- 连表键：能否优化连表键，连表的键尽量走索引的吧
- 分解查询：在内存中自己做关联，即先从数据库中把数据查出来之后，再次查询，然后再进行数据封装。
- 考虑数据冗余 ：在某些情况下，可以考虑数据冗余来减少
JOIN的需要。 - 宽表：就是基于一定的join关系，把数据库中多张表的数据打平做一张大宽表，可以同步到ES或者干脆直接在数据库中直接查都可以
总结
所以啊各位，连表查询的时候小心咯！可能换了一个数据版本环境就GG了💥
当然mysql 和 pgsql 应该问题不大的，国产库的话 升级环境就小心了💥