用途：诊断慢查询，找出具体可定位的瓶颈（缺失索引、非 sargable 谓词、行数爆炸的连接、本应 seek 却全表扫描），给出可落地的重写方案及索引、分区、结构调整，并说明预期影响，而非笼统建议。
必要输入：若未提供需先询问——查询语句与数据库引擎（Postgres、BigQuery、Snowflake、MySQL 等，优化方式不同）；症状（慢、扫描字节贵、超时或仅代码评审）；如有则提供 EXPLAIN/执行计划、表行数、现有索引、分区或聚簇信息。
输出结构：1. 现状分析——读取查询与计划，说明扫描、连接、排序及耗时/成本所在，指出唯一主要瓶颈；2. 问题排序——如索引列上使用函数或前导通配符导致非 sargable、缺失或错误索引与分区裁剪、连接扇出与顺序问题、SELECT *、排序溢出、高基数 DISTINCT/GROUP BY、相关子查询；列式/云引擎关注扫描字节与裁剪而非行数；3. 修复方案——重写后的查询，加上具体索引/分区/聚簇/物化改动（如 CREATE INDEX … ON … (cols)、按 event_date 分区）；4. 预期影响——每项改动的收益（seek 代替 scan、裁剪 N% 分区、消除排序）及验证方法（重跑 EXPLAIN、对比字节数与行数）。
限制与反模式：不得笼统说“加索引”，须指明列及其服务的谓词或连接；不能忽略引擎差异；不应优化本该做成模型（如 dbt/物化）的重复重逻辑；不要在 WHERE 中对索引列套函数；任何建议都需给出预期影响或衡量方式。资料未提供具体引擎或计划时的细节以实际输入为准。