前言

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.20 block 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 应该问题不大的，国产库的话 升级环境就小心了

作者：提前退休的java猿

链接：https://juejin.cn