使用TableStudio加速查询
TableStudio能够测量，而不仅仅是猜测。切勿仅凭直觉推荐索引或重写，使用以下工具进行验证。大多数工具仅适用于PostgreSQL；其他数据库引擎请使用explain_query并根据执行计划进行分析。
首先按照数据库工作流技能中的描述选择连接。建议在包含真实数据的数据库上运行分析。接近空的开发环境数据库会产生误导性的执行计划。
定位慢查询
- 用户提及特定查询或端点： 找到其运行的SQL（从代码或ORM日志中），然后转到“诊断单条语句”。
- “为什么数据库变慢了？” 调用
slow_queries。它根据pg_stat_statements的总执行时间对语句进行排序。保留每行的query_id；其他工具可以接收该ID。如果该扩展未安装，工具会解释启用步骤，请将信息转述给用户，而非未经请求安装。 - 全面调优：
workload_index_advisor找出覆盖最多数据库时间的少量索引，并列出从未使用过的现有索引。
健康检查
当用户询问数据库出了什么问题或希望进行总体审查时，不修改任何内容，直接报告：
database_health。在总结之前先阅读其unavailable列表：如果unavailable列表中有条目但findings为空，表示某些检查被跳过，而非一切正常。database_overview，了解数据库大小、最大和最繁忙的表以及连接数。schema_issues（不带table参数），获取数据库级别的设计问题。
用通俗语言优先列出最关键的发现：问题是什么、忽略的代价以及修复方法。包含每个发现的verify_sql，让用户可以检查具体数值；同时包含任何修复方案的lock_impact。提供选项，将用户选择的修复方案通过下方的“实施部署”来处理。
诊断单条语句
optimize_query，传入SQL（如果来自slow_queries则同时传入query_id）。对于只读语句，设置analyze: true以执行实测检查。它会在回滚的事务中执行一次。当没有值得优化的地方时会报告already_fast；此时直接告知用户，而不是凭空编造改进建议。- 如需更多细节，使用
explain_query（仅对读操作设置analyze: true）。比较每个节点上的actual_rows与estimated_rows。两者差距大意味着统计信息过时（需要对表执行ANALYZE），这往往是真正的错误来源，而非缺失索引。 - 包含
$1, $2占位符的语句需要真实值才能生成可靠的执行计划。suggest_parameter_values可以从历史记录、活跃会话和统计信息中找出这些值。
验证修复方案
在推荐任何方案之前，使用benchmark_query_variants（查询实验室）：
- 提供基线SQL以及作为候选方案的
variants：可以是重写的sql、hypothetical_indexes（使用hypopg规划但实际不创建）、hide_indexes或规划器settings。或者省略variants，让find_faster自行提出方案。 - 它会报告每组参数多次运行后的中位数结果，并验证每个重写版本是否返回与基线相同的行数。
- 仅推荐那些
same_rows为yes的变体。优先选择recommendation中的变体。引用测量到的前后数值，而非凭直觉估算的百分比。
在删除索引（未使用或重复）之前，请使用index_what_if，将要删除的索引放入hide中。任何变慢的语句或当前正在使用该索引的语句都会受到影响。
实施部署
索引和重写操作遵循数据库工作流技能中的正常变更流程：
- 索引变更是schema变更。如果代码仓库使用迁移工具，请在那里添加索引。否则使用
stage_migration提出变更，并将测量数据放在rationale中。 - 在PostgreSQL上，对于有流量的表，使用
CREATE INDEX CONCURRENTLY，并且不要将其包裹在事务中。 - 查询重写是代码变更：编辑发出该查询的代码，并在总结中提及基准测试结果。