技能介绍

当 TDSQL-PG 慢查询排查陷入“算子迷宫”

在 TDSQL-PG（PostgreSQL 兼容的分布式数据库）中排查慢查询时，开发者常面临三重困境：面对 EXPLAIN 输出中嵌套的算子层级，难以快速判断 Seq Scan 是全表扫描的正常选择还是缺索引的隐患；看到 Hash Join 的 batches>1 提示，不清楚是 work_mem 不足导致的磁盘溢出，还是数据量本身的限制；处理分布式查询时，容易忽略 __REMOTE_FQS_QUERY__ 算子背后的分布键问题，导致跨 DN 数据传输拖慢性能。这些问题的核心，在于缺乏对执行计划的系统性解读框架——而本技能正是为填补这一空白设计。

从解析到预测的 5 步分析路径

技能遵循固定的 SOP，确保分析过程可复现、结论可落地：

结构化解析执行计划：先明确阅读规则（深层节点优先执行、同级节点从上到下），提取 cost（估算代价）、actual time（真实耗时，仅 EXPLAIN ANALYZE 有）、rows（估算行数）等关键指标，构建带算子标注的执行树。
算子风险标注：逐一匹配算子与风险信号——如 Nested Loop 在外表 rows>1万 时可能陷入 O(n²) 复杂度，Sort 出现 Disk: 标志意味着内存不足导致磁盘溢出。
瓶颈分级输出：按 🔴高、🟡中、🟢低三级整理瓶颈，例如将“Seq Scan 对应表行数超 10 万且无索引”标记为高风险。
针对性优化建议：针对不同瓶颈给出具体方案：等值查询列建 B-tree 索引，覆盖索引改造实现 Index Only Scan，多表 JOIN 时确保连接列与分布键一致。
优化效果预测：依据官方 cost 公式（如 Nested Loop cost = 外表cost + 内表cost×外表行数），预估优化后的代价变化，避免盲目调整。

分布式场景下的分析边界

需要注意三点：一是 cost 是虚拟单位，仅在同一 SQL 的不同计划间可比，不能跨 SQL 横向比较；二是分布式查询需分层分析——先在 CN 节点查看整体计划，确认参与的 DN 后，再到对应 DN 查看详细计划，避免遗漏局部瓶颈；三是若 rows 估算与实际偏差超 10 倍，优先执行 VACUUM ANALYZE 更新统计信息，再重新分析计划，否则可能因统计偏差导致误判。