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

前言

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

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

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

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

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

ANALYZE 为何如此厉害（postgrel）

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

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

基本用法：

-- 分析单个表
ANALYZE users;

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

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

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

基本功能

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

• 列值的分布情况
• 数据的倾斜程度
• 不同值的数量
• 空值的比例

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

自动分析机制

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

• autovacuum_enabled：是否启用自动清理（默认开启）
• autovacuum_analyze_threshold：触发分析的最小修改行数
• autovacuum_analyze_scale_factor：触发分析的修改行数比例（默认值为 0.1，即 10%）

手动触发时机

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

1. 进行大量数据的插入、更新或删除操作之后，数据迁移时；
2. 执行 CREATE INDEX 之后
3. 在执行 VACUUM 之后

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

总结

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

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

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

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

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