某条 SQL 在小数据下很快，生产却经常超时，可能与数据分布、扫描范围或连接方式有关。执行计划提供判断路径，但必须结合实际参数与运行条件理解，不能只看到全表扫描就认定错误。
先保留可复现的请求条件
记录语句、参数特征、数据范围和耗时发生的时段，注意敏感信息处理。相同 SQL 模板面对不同参数，可能产生不同成本。不要拿一个很小的测试租户替代实际问题场景。
区分估算计划与实际执行
EXPLAIN 展示规划信息，带 ANALYZE 的执行会实际运行语句并收集数据。对写入或昂贵查询，应在合适环境评估影响，不能把分析命令当成无副作用的查看操作。
沿行数与等待定位问题
比较估算与实际处理规模，检查过滤、连接、排序和索引是否符合查询需求。还要区分执行慢与锁、连接等待，避免用新增索引处理完全不同的问题。
验收收益与写入成本
在相同条件下比较查询与资源变化，并检查新增索引对写入和存储的影响。保留优化依据和回归样本，不仅记录“加索引后快了”。
常见问题：全表扫描一定需要改吗？
不一定。数据规模、返回比例和其他成本都会影响合理计划，判断需要结合实际查询与证据。
技术参考：PostgreSQL：理解执行计划。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。