AI助手不会自动生成正确SQL，需人工干预：确保元数据最新、明确约束条件、提供原始SQL作为起点，并严格校验方言兼容性、执行计划和业务逻辑。
AI助手 不会自动完成复杂 SQL 的生成，它只响应你明确控制的输入、上下文和干预节奏。
直接粘贴自然语言描述就出可用SQL？别信
AI助手 不是 SQL 编译器，它不理解业务逻辑，也不校验语义正确性。
你输入“查每个部门薪资 Top 3 的员工”，它可能生成：
- 忘记
PARTITION BY dept_id，导致全局排序而非分组排序 - 在 MySQL 5.7 下用
ROW_NUMBER()（该版本不支持窗口函数） - 字段名硬凑成
dept_id，但实际表中是department_id或需关联departments.id
常见错误现象包括：
- 生成
ILIKE却丢进 MySQL 执行报错 - 用
GENERATE_SERIES()构造日期序列，目标库却是 Oracle - CTE 中引用未定义别名，或嵌套过深触发 MySQL 递归限制
生成前必须手动做三件事
- 确保当前连接已加载最新元数据：右键对应表 → “分析表”（尤其对新导入、长期未更新的表）
- 明确指定约束条件，例如：“改写为不使用子查询的方式，且保持 MySQL 5.7 兼容” —— 不写“兼容”，
AI助手默认按当前连接最高版本生成 - 把原始 SQL 粘贴进编辑器再提问，而不是只给自然语言；它需要可执行语句作为重写起点
生成后不能直接运行
- 点击编辑器右上角「解释执行计划」按钮，重点看是否出现
Using filesort或Using temporary - 检查 WHERE 条件中是否混用
NULL = NULL，或漏写IS NULL - 多 CTE / 窗口函数场景下，人工核对
ORDER BY是否缺失（如LAG(salary) OVER (PARTITION BY dept_id)缺少ORDER BY hire_date就丢失业务意图）
真正容易被忽略的是：AI 对方言差异的敏感度远低于人，它不会主动标注某函数在另一库中不可用，也不会提醒你字段注释里写的“逻辑删除”实际要加 WHERE deleted_at IS NULL。每次生成，都得当成初稿来审，不是终稿来执行。
