企业官网建设流程全解析

同一条订单查询，小参数时几十毫秒，大参数时却长时间占用数据库；EXPLAIN显示优化器预计返回 12 行，实际执行产生了十几万行，随后 Nested Loop 的内表被反复扫描。问题不在于 PostgreSQL “不认识索引”，而在于它基于错误的行数估计选错了连接路径。

本文用一个country与currency强相关的例子说明如何找到第一次估算分叉。文中的 SQL 是可执行的诊断样例，但这里没有连接你的数据库，因此不会把示例结果写成实测结论。

先复现：两个相关条件被当成彼此独立

假设订单表中，中国区订单几乎都以 CNY 结算：

CREATETABLEorders(idbigintGENERATED ALWAYSASIDENTITYPRIMARYKEY,customer_idbigintNOTNULL,countrytextNOTNULL,currencytextNOTNULL,created_at timestamptzNOTNULL);CREATEINDEXidx_orders_customer_createdONorders(customer_id,created_atDESC);

只收集单列统计信息时，规划器可能分别估计country = 'CN'与currency = 'CNY'的选择率，再把两者相乘。真实数据中的相关性没有进入模型，中间结果便会被严重低估。

在测试库中用下面的命令保留执行证据：

EXPLAIN(ANALYZE,BUFFERS,SETTINGS,FORMATTEXT)SELECTc.id,o.id,o.created_atFROMcustomersAScJOINordersASoONo.customer_id=c.idWHEREo.country='CN'ANDo.currency='CNY'ANDo.created_at>=now()-interval'30 days';

ANALYZE会真的执行查询，不要把修改型 SQL 原样放到生产环境。排查时从计划树内层向外找第一个rows与actual rows明显分叉的节点，并把loops一起看；最外层耗时只是结果，第一次误判才是线索。

不要先禁用连接算法，先检查规划器掌握了什么

先查看自动分析时间和列分布：

SELECTrelname,last_analyze,last_autoanalyze,n_live_tupFROMpg_stat_user_tablesWHERErelnameIN('orders','customers');SELECTattname,n_distinct,most_common_vals,most_common_freqsFROMpg_statsWHEREschemaname='public'ANDtablename='orders'ANDattnameIN('country','currency','customer_id');

成功的诊断不是“强制走了 Hash Join”，而是能回答三个问题：统计信息是否过期、目标值是否在高频值列表中、多个过滤列是否存在业务相关性。若只是批量导入后统计信息陈旧，先执行ANALYZE orders；若误差稳定来自相关列，再考虑扩展统计：

CREATESTATISTICSst_orders_country_currency(dependencies,mcv)ONcountry,currencyFROMorders;ANALYZEorders;

dependencies描述列依赖，mcv保存常见组合。它们帮助过滤条件估算，但不会自动替代缺失的连接索引，也不能修复写错的 Join 条件。

做一个反事实实验，而不是永久关闭 Nested Loop

在事务内临时改变规划器开关，可以验证“另一类计划是否值得继续调查”：

BEGIN;SETLOCALenable_nestloop=off;EXPLAIN(ANALYZE,BUFFERS)SELECT/* 同一条查询，参数保持一致 */;ROLLBACK;

这只是反事实实验。若另一计划更合适，应继续修正统计信息、SQL 或索引，而不是在全局配置中禁用 Nested Loop。小结果集驱动索引查找时，Nested Loop 往往正是正确选择。

还要防止只验证一组参数。把典型小客户、普通客户和头部客户的参数各选一组，分别保存计划。预备语句使用通用计划时，参数分布差异尤其容易被平均值掩盖。

验收修复：关注估算误差，而非计划节点名称

可以把计划保存为 JSON，再检查目标节点的估算倍率：

psql"$DATABASE_URL"-X-vON_ERROR_STOP=1-Atc\"EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) SELECT c.id, o.id FROM customers c JOIN orders o ON o.customer_id=c.id WHERE o.country='CN' AND o.currency='CNY';"\>plan.json python-mjson.tool plan.json>/dev/nulltest-splan.json

上述命令的可验证成功条件是：psql退出码为 0、plan.json非空且能被 JSON 解析。性能层面的验收还需比较修改前后相同数据快照、相同参数和相同缓存条件下的计划；重点记录首次分叉节点的估算/实际行数倍率、缓冲区读取和总执行时间。失败条件包括估算误差没有缩小、只对单一参数改善，或其他高频查询出现回退。

优化器调优的目标不是让 SQL 永远使用某个索引，而是让成本模型获得足够准确的输入。先定位第一次估错，再决定更新统计、添加扩展统计、调整索引还是改写查询，通常比直接改全局成本参数更可控。