从测试环境中的慢查询开始，收集可比较的执行计划与缓冲区数据，让 Gemini 辅助定位问题，再用前后计划验证索引是否真正有效。
目标是诊断一条具体慢查询，而不是让 AI 泛泛推荐索引。你需要在测试环境收集脱敏 SQL、相关表结构、现有索引和 EXPLAIN ANALYZE 输出，让 Gemini Code Assist 协助找出顺序扫描、连接放大或行数估算偏差，随后只验证一项索引改动。
版本、权限与安全前提
本文面向 Gemini Code Assist 当前稳定版和 PostgreSQL 当前受支持稳定版，日期为 2026 年 8 月 30 日。IDE 扩展入口、企业数据策略、模型和上下文限制可能变化，请核对 Gemini Code Assist 官方概览及组织管理策略。本文不假定固定套餐、按钮或模型名称。
| 前提 | 要求 |
|---|---|
| 执行环境 | 仅在可控测试环境运行 EXPLAIN ANALYZE |
| 输入资料 | 脱敏 SQL、相关列定义、索引和统计信息背景 |
| 比较指标 | 执行时间、实际行数、循环次数及缓冲区数据 |
| 变更权限 | 可创建测试索引，但生产变更另行评审 |
EXPLAIN ANALYZE 会实际执行语句。对写入、删除、锁表、长事务或资源密集型查询，必须先评估副作用，不能直接在生产环境复制命令。必要时使用回滚事务或只读副本，但具体方案由数据库管理员确认。
准备一份可解释的诊断包
仅提供 SQL 往往不够。至少收集查询参数的代表性范围、涉及表的相关列、已有索引、近似数据分布和完整计划文本。删除真实客户值、租户标识、主机名、连接串、业务密钥与不必要的表名；可以一致替换名称，但要保留连接关系和数据类型。
任务：分析以下 PostgreSQL 查询计划，不直接给生产变更命令。
材料：脱敏 SQL、相关表结构、现有索引、EXPLAIN ANALYZE 输出。
请按节点说明：估算行数、实际行数、循环次数、主要成本和可能原因。
优先识别：顺序扫描、估算偏差、连接放大、排序或磁盘读取。
最后只提出一项可验证的候选优化，并列出风险与验证方法。让 Gemini 明确引用计划中的节点名称和数值位置，不接受只有“考虑添加索引”的结论。PostgreSQL 官方对计划树、成本、实际时间和扫描方式的解释可查阅 PostgreSQL Using EXPLAIN 文档。
先自己读懂四类信号
- 估算行数与实际行数。差距明显时，后续连接策略可能建立在错误估算上，应检查统计信息和数据相关性。
- loops。节点单次看似便宜，但被上层循环大量调用时，总成本可能被放大。
- 扫描方式。顺序扫描并不天然错误；返回表中较大比例的数据时，它可能比索引扫描合理。
- 缓冲区。若收集了 BUFFERS，可比较命中与读取情况，但不要把单次缓存状态当成稳定结论。
计划中的 cost 是规划器估算，不等同于毫秒；actual time 才来自本次执行，但也会受缓存、并发和机器状态影响。要求 Gemini 分开解释二者，避免把高 cost 直接翻译成确定的耗时。
选择一项索引候选
假设慢点集中在高选择性的过滤条件，并且查询随后按另一列连接或排序，可以让 Gemini 比较单列索引与复合索引的候选顺序。列顺序、等值条件、范围条件、排序方向和写入成本都需要考虑，不能根据 WHERE 中字段出现顺序机械创建。
| 索引前要问 | 原因 |
|---|---|
| 过滤能排除多少行 | 低选择性字段可能仍适合顺序扫描 |
| 是否已有相近索引 | 避免重复索引增加存储和维护成本 |
| 查询是否稳定高频 | 偶发查询未必值得长期写入开销 |
| 参数分布是否偏斜 | 一个样本值不能代表所有执行情况 |
| 是否影响写操作 | 新增索引会增加插入、更新和维护负担 |
本轮只建立一个测试索引，不同时改写 SQL、调整服务器参数和刷新多项统计信息。否则即使计划改善，也无法判断是哪项变化起作用。
用前后计划验证，而不是看 AI 结论
- 在相同测试数据和尽量一致的环境下保存优化前计划。
- 创建候选索引并确认创建成功，不把该操作直接复制到生产。
- 用相同 SQL 和代表性参数重新收集计划，避免只挑对索引有利的值。
- 比较节点类型、估算与实际行数、循环、总时间和缓冲区数据。
- 重复数次观察稳定范围，再评估写入、磁盘空间和维护影响。
若规划器仍选择顺序扫描，不代表索引无效或数据库出错。可能是返回比例过高、表较小、统计信息不合适、参数不同，或规划器估算顺序扫描成本更低。不要为了证明建议正确而关闭扫描方式；这类设置最多用于诊断对比，不应替代根因分析。
失败诊断与人工复核
- 计划文本被截断：缩小查询范围或分段提供，但保留完整父子节点关系。
- Gemini 误读时间：检查 actual time 是否为每次循环读数，并结合 loops 理解。
- 索引未被采用：检查选择性、统计信息、类型转换、表达式和参数分布。
- 时间改善但读取增加：重复测试缓存冷热状态，比较缓冲区而非只看一次耗时。
- 建议修改很多参数：要求按证据排序，并坚持每轮只验证一个变量。
人工复核必须由了解数据规模和业务峰值的人完成。重点检查索引是否重复、是否会放大写入成本、是否覆盖真正高频参数，以及测试数据能否代表生产分布。最终生产变更还应走数据库变更、回滚和监控流程。
隐私、安全与成本边界
SQL、表结构和计划可能泄露业务模型、租户关系与安全控制。应用安全风险分类可参考 OWASP Top 10作为边界检查入口，但它不能替代数据库权限和组织数据政策。不要向模型发送连接凭据、真实个人数据或未批准的内部结构。
Gemini Code Assist 的可用额度和数据治理取决于当前账户与组织配置。新增索引本身也有存储、写入放大、备份和维护成本；查询更快不等于总体成本更低。AI 给出的 SQL 和索引语句必须经过数据库管理员审查。
结论
Gemini PostgreSQL EXPLAIN 分析的价值在于帮助整理计划证据和提出可验证假设，而不是代替数据库测量。用脱敏诊断包定位具体节点，每轮只改变一个变量，再比较优化前后的计划、时间和缓冲区，才能判断索引是否真正值得保留。
常见问题
可以直接在生产库运行 EXPLAIN ANALYZE 吗？
不应默认这样做，因为它会实际执行查询。应先在测试环境评估副作用，生产使用需由数据库管理员按查询类型和风险批准。
看到顺序扫描就一定要加索引吗？
不一定。表较小或查询需要读取大量行时，顺序扫描可能更合理；要结合选择性、实际行数、循环和缓冲区判断。
索引让一次查询变快后就可以上线吗？
还不够。需要使用多组代表性参数重复比较，并评估写入开销、存储、重复索引、发布方式和回滚方案。