在使用 Codeium 优化 SQL 查询时，一个常见误区是仅提供模糊指令。直接说“这个查询慢，帮我优化”，往往无法获得精准建议。因为 Codeium 不了解您的数据特征，容易基于错误假设给出不切实际的方案。因此，关键在于明确两点：说清楚表的数据量级，说清楚现有索引结构。缺少任何一项，优化效果可能天差地别。

具体描述时，建议在开头直接注明主表的行数，使用数字加单位，避免含糊。例如“users 表有 850 万行数据”，这样 Codeium 能识别表规模，从而应用索引下推等策略。如果涉及多表关联，需按 FROM→JOIN 顺序逐一列出：“orders 表约 1200 万行，order_items 表约 4300 万行，product 表仅 2.3 万行”。注意：不足 1 万行可写“约 X 行”，超过 10 万需用“万”或“百万”；超过 1 亿建议用“亿”或科学计数法（如 1.2e8）。单位缺失是个大忌——Codeium 会默认为几千行的小表，跳过索引下推、哈希关联等优化策略。

说明表量的写法

提问时，开头直接明确主表行数，使用数字加单位，避免“大量”“很多”等模糊词汇。示例：“users 表有 850 万行数据”。

若涉及多表关联，每张表都需单独说明，顺序按 FROM→JOIN 顺序排列。例如：“orders 表约 1200 万行，order_items 表约 4300 万行，product 表仅 2.3 万行”。

小于 1 万行可写“约 X 行”，超过 10 万必须带“万”或“百万”单位；超过 1 亿必须用“亿”或科学计数法（如 1.2e8），单位缺失会导致 Codeium 误判为小表而忽略索引下推。

描述索引的写法

方法一：采用 CREATE INDEX 语句格式列出关键索引。例如：“users 表上有 idx_users_status_created (status, created_at)、uk_users_email (email)；orders 表上有 pk_orders (id)、idx_orders_user_id (user_id)、idx_orders_status_time (status, order_time)”。

方法二：用自然语言精炼描述，但必须包含字段顺序和类型。例如：“orders 表已建复合索引：先 status 再 order_time，且 status 是前导列；user_id 字段有单独 B-tree 索引”。

注意：避免只说“有索引”，需写明字段名、顺序、是否唯一、是否覆盖查询所需列。如果遗漏 order_time 在复合索引中的位置，Codeium 可能建议重复创建字段顺序完全相同的索引——徒劳无功。

完整提问模板组合

第一步：明确查询目标。示例：“想加速查询：SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' AND o.order_time > '2024-01-01' ORDER BY o.total DESC LIMIT 50”。

第二步：说明表量。例如：“users 表 850 万行，orders 表 4300 万行”。

第三步：列出相关索引。例如：“users 表有 idx_users_status (status) 和 uk_users_email (email)；orders 表有 idx_orders_time (order_time) 和 idx_orders_user_status (user_id, status)”。

操作起来很简单，直接将这三段内容粘贴进 Codeium 对话框即可。试试看，效果立竿见影。