AI 改写 SQL 后怎么验收优化？比较查询计划，并确认结果等价

AI 提议加索引后，先检查查询结果有没有变化，再查看数据库是否实际选择了索引。查询计划显示搜索路径，不等同于测出了运行时间提升。

希望让AI辅助优化SQLite查询的开发者。本文使用 Python 3.11 或以上版本的标准库，先验证一组人工构造的小样本。AI 负责提出实现或解释差异，结果由本地检查决定；这里没有把模型回答当成真实运行结果。

核对SQL优化前后的计划与结果前，先定规则

示例按客户与状态查询订单，并使用ORDER BY固定输出顺序。没有排序条件时，两份结果列表顺序不同不一定代表业务结果不等价。

给AI表结构、筛选条件、已有索引与当前计划，不发送真实客户明细。本例只研究过滤索引，不把订单金额或业务指标交给模型定义。

建索引会增加存储和写入维护成本。小表的计划不能推导大表耗时，因此示例不输出“提升几倍”。

给 AI 的输入要包含什么

把下面这份输入说明和你的实际样本一起交给可用的 AI 编程助手。示例只含虚构数据；对真实材料先去除账号凭据和个人信息。

SQLite orders(id INTEGER, customer TEXT, status TEXT)。查询customer=?且status=?，按id排序。请建议索引并解释前缀顺序；保持查询语义，不增加LIMIT，不改变过滤条件。比较创建索引前后EXPLAIN QUERY PLAN并核对结果相等。

要求模型保留检查条件，并把它认为缺少的业务定义列出来。若回答改变了输入字段、忽略异常分支或直接删除原材料，先要求修正，再运行。提示词的作用是缩小任务范围，验收仍以代码和数据为准。

保存并运行最小验证程序

下方程序把关键规则和验证用例放在同一个可复跑示例中，便于先理解输入如何变成输出，再用它检查 AI 给出的实现。

新建一个空目录，把下面代码保存为 check.py，在该目录打开终端，运行 python -X utf8 check.py。代码自带示例输入，不需要安装第三方库。

import sqlite3
db=sqlite3.connect(':memory:')
db.execute('create table orders(id integer, customer text, status text)')
db.executemany('insert into orders values(?,?,?)',[(1,'A','paid'),(2,'A','new'),(3,'B','paid'),(4,'A','paid')])
sql='select id from orders where customer=? and status=? order by id'
args=('A','paid')
before=db.execute(sql,args).fetchall()
plan1=db.execute('explain query plan '+sql,args).fetchall()
db.execute('create index idx_orders_customer_status on orders(customer,status)')
after=db.execute(sql,args).fetchall()
plan2=db.execute('explain query plan '+sql,args).fetchall()
assert before==after==[(1,),(4,)]
print('rows',after)
print('before',[p[3] for p in plan1])
print('after',[p[3] for p in plan2])
assert any('SEARCH' in p[3] for p in plan2)

怎样判断结果符合要求

两次结果都应为订单1和4。建索引后的计划应显示索引搜索路径；排序仍可能显示临时B树，这是ORDER BY的额外工作，不是索引完全失效。

下方是这份最小示例在本地执行得到的输出。它验证示例程序与断言的关系，不代表任何 AI 模型一次就能生成同样代码，也不构成性能或生产可靠性结论。

rows [(1,), (4,)]
before ['SCAN orders', 'USE TEMP B-TREE FOR ORDER BY']
after ['SEARCH orders USING INDEX idx_orders_customer_status (customer=? AND status=?)', 'USE TEMP B-TREE FOR ORDER BY']

计划字符串取决于SQLite版本，示例只粗略确认SEARCH。正式自动检查不要依赖完整文本相等。

如果AI去掉ORDER BY或把AND改成OR，即使计划更短，也不能通过结果契约。先检查语义，再讨论耗时。

哪些失败必须停下来处理

索引不一定被使用：列函数、隐式转换、低选择性、统计信息与查询条件不同都可能影响选择。

生产测量要使用真实分布的脱敏副本、重复执行、固定缓存口径，并同时评估写入成本。本文没有做生产压测。

不同数据库的计划工具与索引策略不同，不能直接把SQLite输出解释套到PostgreSQL或MySQL。

接入自己的任务前再核对一次

对每次AI改写保存原SQL、参数、结果核对和计划。样本包含无匹配、多匹配、空值等语义边界。

涉及UPDATE或DELETE的“优化”先在事务和副本验证，不在生产库试跑模型建议。

资料与适用范围

SQLite EXPLAIN QUERY PLAN 用于展示扫描与索引访问策略，输出格式不适合作为稳定应用接口。以下链接核对于 2026-10-03；运行环境及额外依赖按本文前述说明。

• https://www.sqlite.org/eqp.html

相关基础可阅读 AI 生成 SQL 怎么用？从表结构写出查询，再在 SQLite 中验证。本文的重点是核对SQL优化前后的计划与结果，可以把两项检查作为不同步骤保留。