微信扫一扫SQL Workload Index Advisor
当用户需要为一组 SQL 设计索引、审查重复建议或权衡索引维护成本时使用。单条查询也可分析。产物是有证据边界的候选报告；第一版以 PostgreSQL 18、MySQL 8.4 / InnoDB 的普通 B-tree 为参考范围，其他引擎只提供待核对的结构建议。
收集输入与证据
接受 SQL 列表，并为查询分配 Q1、Q2 等稳定编号。尽量收集数据库引擎及版本、Schema/DDL（类型、主键、唯一约束、可空性）、已有索引完整定义、频率与统计周期、重要性、代表性参数。可选信息包括行数、数据分布、写入情况、存储预算及原始 EXPLAIN / EXPLAIN ANALYZE。
信息不足时继续完成能够支持的结构分析，在报告开头列出缺失项：
- 只有 SQL：只使用 SQL 中明确出现的标识符；类型、字段归属、现有索引、数据分布均为未知。字段存在性和索引能力未确认时，DDL 仅作条件示例。遇到歧义列或无法解析的动态 SQL，记录待澄清项，不猜测。
- 未提供索引不等于没有索引；未提供频率不等于低频。前者标记“关系未知”，后者使用定性优先级，不捏造数值权重。
- 明确区分用户事实、结构推理、带假设的估算、用户提供的优化器估算与实测结果。引用计划时保留查询、参数、引擎和索引配置的对应关系；不把优化器 Cost 当作毫秒或实际收益。
分析与形成候选
- 按 工作负载分析 建立逐查询特征表：表/别名、等值、范围、JOIN、ORDER BY 及方向、GROUP BY、LIMIT、投影和不易走索引的表达式。保留子查询作用域、参数差异与跨查询公共模式。
- 读取 索引设计规则，按访问需求提出少量有理由的候选。考虑单列与复合索引、等值前缀加范围、JOIN 探测、排序或分组需求。每个候选解释列顺序和替代方案的取舍；不把所有过滤列机械拼接，也不为了覆盖
SELECT *收入所有列。 - 在排序和输出之前，读取 候选合并，构建整个工作负载的候选注册表。按完整索引语义去重并合并关联查询，检查已有索引，再标出前缀重叠与不同列序的权衡。已有可用的等价索引不再输出为新增动作；仅有前缀关系时不能自动建议删除现有索引。
- 对合并后的候选使用高/中/低三级“验证优先级”，同时标明证据强度。综合关键查询、已知频率、潜在访问路径、已有重叠、索引宽度、写入维护和存储预算。高：重要需求有明确结构依据且未见等价索引；中：有共享或局部价值但关键证据缺失；低：需求窄、重叠大或维护代价较明显。资料不全时高优先级也仅代表应优先验证。已知预算但未知大小时写“预算可行性未验证”，不能宣布满足预算。
- 选择相互协调的少量新增建议，保留低优先级候选及暂缓原因。不同候选服务相同查询时，不重复计算收益；若用户提供同周期频率和重要性，可展示每个候选关联的不同查询的
Σ(频率 × 用户权重)，仅称“需求权重”，不称收益、优化器 Cost 或配置最优分数。不得将多个候选的需求权重相加解释为配置收益。本版不实现收益评分算法。 - 按 验证指南 提出下一步。只输出 DDL 示例，不连接外部数据库、不执行 CREATE/DROP INDEX、不运行查询；只有新增授权的后续任务才能扩展执行范围。
输出报告
使用中文，按下列结构提供具体内容；如果没有应新增的索引，直接说明并列出被已有索引承接的需求。
- 工作负载摘要与边界：查询数、引擎/版本、已知 Schema 与索引、缺失信息、写入和预算、事实及推理来源。
- 查询需求表：查询 ID、表、过滤/JOIN/排序/分组/LIMIT 特征、频率或重要性、关键访问需求。
- 合并候选表：候选 ID、表及有序键列（方向/方法/谓词/INCLUDE 如适用）、关联查询、共享或专用、与已有索引关系、保留/已有可用/暂缓、优先级及证据强度。
- 逐候选说明：CREATE INDEX 条件示例、列顺序理由、对每条关联 SQL 的可能作用、未覆盖的需求、替代方案、潜在存储/写入/维护成本及不确定性。已有等价项可展示其输入 DDL，但标明“不新增”，勿再生成重复建索引动作。未知引擎时用基础语法并明确待核对条件，不引入未提供的字段或类型。
- 验证计划与待补充信息：比较基线和候选配置、关注的计划节点与测量指标、用户需提供的证据。区分计划证据与执行证据，不虚构任何加速百分比或实验结果。
缺少真实执行验证的报告必须包含：
这是基于 SQL 结构与现有信息的候选推荐，尚未通过真实数据库执行验证。