Codeium写SQL需三步：一要提供schema.sql让AI识别表结构；二用注释或三段式提示明确表角色、过滤条件和输出要求；三生成后检查GROUP BY完整性、JOIN字段类型匹配、WHERE是否作用于驱动表。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用Codeium写SQL查询时反复改字段名、漏加WHERE条件、JOIN表顺序错，导致执行报错或结果不对，返工三次以上很常见。它不是不能写SQL，而是你没让AI看清上下文、没给它结构化提示、也没校验它生成的语句是否贴合你的真实表结构。
让Codeium看懂你的数据库结构
打开VS Code，确保项目根目录下存在 【schema.sql 或 migrations/ 目录】，里面包含建表语句（如 CREATE TABLE restaurant_logs (...)）。Codeium会自动索引这些文件，后续写SQL时才能准确识别字段类型、主外键关系、索引字段。
如果只有 .env 或 config/database.php 里配了数据库连接，但没放建表SQL——Codeium大概率把 nmodule_id 当成字符串处理，生成的 JOIN 条件会丢掉类型隐式转换细节，查出来全是 NULL。
这一步操作起来很简单，直接把最近一次上线的建表脚本复制进项目根目录就行。
用自然语言+结构化关键词描述查询意图
别只写“查用户订单”，要带约束、字段、关联逻辑：
方法一：在注释里写清楚
在SQL文件顶部加多行注释：
// 查询 branch_id=123 的所有模块名称，及其对应日志中 ntype=1/2/5/6 的最小 nmark_completed 值，按模块ID升序
方法二：用三段式提示法
① 表角色：custome_module 是主表，restaurant_logs 是日志附表，通过 nmodule_id 关联
② 过滤条件：cm.nbranch_id = 123，rl.ntype ∈ (1,2,5,6)
③ 输出要求：每行一个模块，四列别名分别是 call_waiter/bill/ordera/tray
【不写清楚表角色，Codeium可能把 restaurant_logs 当主表，生成反向 LEFT JOIN，结果集膨胀10倍】
生成后立刻验证三处关键点
第一步：检查 SELECT 字段是否全在 GROUP BY 里
如果用了 MIN(CASE WHEN ...) 聚合，但 SELECT cm.id, cm.name 后没写 GROUP BY cm.id, cm.name —— MySQL 8.0+ 会直接报错 ONLY_FULL_GROUP_BY。
第二步：核对 JOIN 条件字段类型是否匹配
Codeium有时会把 int 类型的 nmodule_id 和 varchar 类型的 id 拼一起，生成 cm.id = rl.nmodule_id，而实际是 cm.id = CAST(rl.nmodule_id AS SIGNED)。这种错不会语法报错，但结果为空。
第三步：确认 WHERE 是否落在驱动表上
错误写法：WHERE rl.ntype IN (1,2,5,6) → 这会让 optimizer 先扫 restaurant_logs，再回表找 cm；
正确写法：WHERE cm.nbranch_id = 123 → 先定位 custome_module 少量记录，再对每条去查 rl。
这三处任一出错，都会导致查询变慢或结果为空，必须手动过一遍。
