🚀不改SQL，也能让SQL的执行效率提升100倍

前言

😁没错，昨天5点下班了，看见同事还在焦头烂额！有个连表查询现在卡死了，执行了好几分钟都没出结果。

🤪这个简单，应该是执行计划出了问题，正常三个不到百万级别的数据链表查询，不会造成卡死的，执行一下ANALYZE 就好了，果然执行之后，接口的响应时间直接来到了2s。

因为连表查询导致SQL卡死的问题已经不止一次了，之前我也解决过，还写了一篇博客，也把解决方案发到技术群里过。再次遇到这个问题还是立马解决的事儿.

完了！一条SQL把数据库服务器干爆了这篇文章分记录了因为连表查询执行计划出了问题导致CPU爆炸问题的解决全过程。

🎈今天就主要给大家分析一下ANALYZE命令的作用，以及什么时候要去执行这个命令，为什么ANALYZE能让让原本卡死的SQL性能提升好几个数量积

ANALYZE 收集有关数据库中表内容的统计信息，查询规划器使用这些统计信息来帮助确定查询的最高效执行计划。

✔查询优化器会依据这些统计信息来估算查询成本，进而选择最优的执行计划，像是否使用索引、使用哪种连接算法等。如果统计信息过时或者不准确，优化器可能会选择次优的执行计划，最终导致查询性能下降。

基本用法：

diff 复制代码

-- 分析单个表
ANALYZE users;

-- 分析单个表并显示进度信息
ANALYZE VERBOSE users;

-- 分析表的特定列
ANALYZE users (username, created_at);

-- 分析数据库中的所有表
ANALYZE VERBOSE;

ANALYZE 命令的核心功能是收集表中列的统计信息，具体涵盖：

这些统计信息存储在系统表 pg_statistic 中。查看命令 SELECT * FROM pg_stats

PostgreSQL 具备自动分析机制，通过 autovacuum 守护进程来实现。当表的修改达到一定阈值时，autovacuum 会自动执行 ANALYZE。相关的重要参数如下：

在以下情况下，建议手动执行 ANALYZE：

简单的理解就是，数据在短时间内存在大量的修改。

可以看到数据库的统计信息的维护，对于执行计划计算成本来说非常的重要。数据库也会自动取维护统计信息，但是在某些情况下可能存在丢失的情况。

❗特别是在连表查询中，如果统计信息和实际信息相差特别大，在SQL分析执行阶段，如果把预测成了小表，就会走Nested Loop 循环，这是时候SQL性能可能比Hash join 的方式高100倍不止！

我们的kingbase 迁移之后，就经常出现数据库卡死CPU飚高的问题。当然信创环境肯定是功不可没！

报一个小料：一个专家说信创环境服务器性能只有互联网服务器性能的30%

推荐阅读：完了！一条SQL把数据库服务器干爆了这篇文章分记录了因为连表查询执行计划出了问题导致CPU爆炸问题的解决全过程。