seekdb SQL 诊断

把慢查询的猜测变成可核对的证据和小范围修改。不要把其他数据库的执行计划字段、索引语法或 Hint 当作 seekdb 已支持的功能。

收集最小证据

先记录 seekdb/OceanBase 版本、完整 SQL 与参数、相关表结构和索引、数据量级、当前耗时及期望目标。尽量获取同一参数下的 EXPLAIN 和实际行数/耗时；如果只有 SQL 文本，明确标记后续判断为静态推断。对可能包含凭据、个人信息的字面量先脱敏。

缺少其中某项时继续分析已有证据，只询问会改变结论的关键缺口。不要编造执行计划、基数或收益百分比。

对照 SQL 的过滤、连接、分组、排序、LIMIT 与计划中的访问路径、估计行数及代价；有运行时统计时，再比对实际行数和时间。
检查高代价扫描、过滤后剩余行数、连接顺序、排序或临时结果，以及索引是否覆盖常用谓词。把估计误差与确实测到的慢节点分开。
全文/向量/混合检索时，分别检查候选集来源、结构化过滤发生的位置、召回数和最终排序；先确认当前版本实际支持的索引和语法。召回率、过滤语义与相关性也是正确性的一部分。
对每个瓶颈写出“证据 → 机制 → 可检验的假设”。无法从现有材料定位时给出下一条最有用的观测命令或数据请求。

按证据强度和实施成本排序，通常先考虑谓词及类型匹配、合适的已有索引、过早扩大候选集或排序等问题，再考虑新增索引、重写查询或调整检索流程。每条建议说明为什么可能减少读取、排序或候选数，以及写入成本、索引空间、召回质量或维护成本。不要在缺少计划依据时先加 Hint。

改写必须保持业务结果：空值、重复行、排序稳定性、分页、全文匹配与向量距离方向都要核对。数据变更、建索引和生产执行需经用户授权；提供方案不等于直接执行。

用相同参数、相近数据状态和相同环境比较修改前后计划与代表性耗时；至少检查结果集是否等价。对检索查询同时比较召回/相关性。若实测无改善或正确性退化，撤回该建议并检查假设。

回答按下面顺序写，省略没有证据的指标：

例如，看到大表扫描且过滤谓词选择性高时，可以提出“核对该列是否有可用索引，并用同一参数对比计划”，但不能在未测量前写“创建索引可提速 10 倍”。