工具笔记
让 AI 给慢查询提索引，先交两份执行计划
把过滤条件、排序与实际执行计划放一起看。
资料核验2026.11.12 · PostgreSQL · 以部署版本文档为准
项目列表慢，助手给状态列加了单列索引。真正的查询先按项目过滤，再取最近的二十条。单看某列出现频率，无法判断哪个索引更合适。
给 AI 的上下文与边界
提供实际查询形状、参数、样本数据规模和基线计划。要求助手为按项目过滤并取最新记录的查询提出一个候选，解释列顺序与排序的关系，然后在测试库用同条件比较。
用代表性数据做两份计划
拿实际查询形状和接近生产的数据分布做基线。对 WHERE project_id = ... ORDER BY created_at DESC LIMIT 20，可以把项目和创建时间作为组合索引候选。然后用 EXPLAIN ANALYZE 对比扫描、排序和行数。
同时观察写入成本。每增加一个索引，写入路径就多一份维护工作。数据很少时，顺序扫描也可能是合理选择。
把查询、数据量和前后计划一起保存。以后项目规模变化，可以按同样条件复查。
可以直接照着做的演练
用同一项目 ID、同一批记录和 LIMIT 20 做前后对照。保存执行计划中的扫描、排序和结果顺序。再换一个记录数明显不同的项目看看计划会不会变，把两份样本条件写在结果旁边。
检查生成结果
- 基线和修改后计划能复查。
- 扫描行数与排序变化能解释。
- 额外索引给写入带来的影响有记录。
- 输出数据顺序一致。
复查时追问一层
如果助手只贴一条 CREATE INDEX，要求给出它期待改变的节点。小表选择顺序扫描可能合理。把参数分布和数据量写下来，不要把某一个测试参数的计划泛化到所有项目。
测试库的数据分布会改变估算和索引选择。让助手用冷热项目各一组参数，重复检查排序与扫描，而不是把一条示例计划当结论。若新增索引已有近似覆盖的旧索引，再判断是否值得维护两份。
