MySQL 预编译参数为什么会换查询计划：prepared statement 与类型转换边界

线上订单列表接口平时跑几十毫秒，突然卡到几百毫秒，排查发现SQL逻辑完全没变，唯一改动就是把之前直接拼接字符串的写法换成了预编译语句。这事儿根本不是很多人以为的「预编译语句反而更慢」，最常见的根因是绑定值的类型、表字段类型、索引规则没对上，优化器眼里拿到的比较表达式早就不是之前那套了。

先把一条订单查询拆成四段

假设订单表有以下字段和索引：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  status VARCHAR(16) NOT NULL,
  created_at DATETIME NOT NULL,
  KEY idx_customer_time (customer_id, created_at)
);

页面请求的是「某个客户在一段时间内的已支付订单」这类场景。从数据处理流程来看，请求会依次经过参数绑定、表达式比较、索引访问、行回表四个环节。只要 customer_id 的绑定类型和字段定义的 BIGINT 不一致，问题很可能在第二步就埋下，最后表现出来的现象却是第三步索引扫描范围大幅变宽。

PREPARE q FROM
  'SELECT id, created_at FROM orders
   WHERE customer_id = ? AND status = ?
     AND created_at >= ? AND created_at 

预编译只负责把SQL文本和参数分开处理，根本不会保证不同类型的参数绑定都能生成同一条执行路径。参数值进入比较表达式之后，MySQL 还是会结合类型规则、索引情况和统计信息重新做优化判断。

为什么换成参数后，索引路径会变

字符列和数字参数不是同一种比较

如果列是 VARCHAR 类型，应用却把数字类型的参数绑定进去，MySQL 要处理字符和数字的比较语义规则；如果列是 BIGINT 类型，驱动层反而把参数绑定成字符串，同样可能触发隐式类型转换。真正要关注的从来不是SQL长什么样，而是比较操作两边的类型能不能对齐。

比如业务编号存成字符列时，下面两种写法看起来只差一对引号，优化器面对的表达式逻辑完全不一样：

-- customer_code 是 VARCHAR(32)
SELECT * FROM orders WHERE customer_code = '00128';
SELECT * FROM orders WHERE customer_code = 128;

第一种写法保留了前导零的字符语义；第二种先走数值比较逻辑，很可能让索引筛选范围和查询结果边界变得完全不符合预期。订单表的 customer_id 如果定义成 BIGINT 类型，就应该让驱动用整数类型绑定参数，不要图省事把所有参数都当成字符串传递。

参数值不同不代表一定换计划

优化器会综合索引基数、扫描范围宽度、统计信息和排序需求做判断。有的参数值只命中几十行数据，有的参数值能命中几十万行数据，就算两边类型完全一致，也有可能生成不同的访问路径。把这类计划变化全部甩锅给预编译语句，排查方向肯定会走偏。

先用字面量写死值的方式和预编译参数绑定的方式分别生成执行计划，再比对 key、rows、filtered 和 Extra 字段的差异：

EXPLAIN FORMAT=TREE
SELECT id, created_at FROM orders
WHERE customer_id = 128
  AND status = 'paid'
  AND created_at >= '2026-08-01 00:00:00'
  AND created_at 

如果只改参数值就出现计划变化，大概率是数据分布倾斜导致的；如果只改参数的绑定类型就出现计划变化，才更符合类型转换边界的问题。两组对比实验一定要保证一次只改变一个变量。

从绑定值到索引命中的核对顺序

顺着数据流动的链路一步步排查，很容易找到第一个出现偏差的位置。

1. 看表结构：确认 customer_id、status、created_at 的实际字段类型、字符集和索引的先后顺序。
2. 看驱动绑定：记录每个参数的编号、业务含义和实际绑定类型，不要只打印最终拼接出来的SQL文本。
3. 看比较表达式：检查有没有给索引列包函数，或者让字符列直接和数字表达式做比较。
4. 看访问计划：重点关注 possible_keys、key、key_len、rows 和 Extra 字段，不要只盯着 type=range 判断好坏。
5. 看实际运行：在低风险环境下用 EXPLAIN ANALYZE 对照真实扫描行数和实际耗时。

这部分逻辑的核心是：参数在进入查询之前就先对应好业务本身的类型，要是转换逻辑落到索引列这一侧，扫描范围基本就很难控制住了。

把修复落到应用和 SQL 两侧

应用侧按字段语义绑定

customer_id 用整数类型绑定，created_at 用驱动支持的原生时间类型绑定，status 状态字段保持字符串类型绑定就好。不要写那种「所有参数统一按字符串绑定」的数据库工具层，看起来省了不少适配的事，反而会把字段的类型语义全部丢给数据库的比较阶段处理。

customer_id: integer
status: string
created_at_from: datetime
created_at_to: datetime

如果用的语言驱动实在没法区分某类参数的类型，至少在参数传入数据库之前就把类型明确转换好，测试环节也要覆盖前导零、空值、超大整数和时区边界这些容易出问题的场景。

SQL 侧让索引列保持可搜索

不要为了「统一格式」这类没必要的要求，给 customer_id 或者 created_at 字段包上函数处理。范围条件的边界值完全可以先在应用侧整理好，保证索引的裸列放在比较操作的左边：

SELECT id, created_at
FROM orders
WHERE customer_id = ?
  AND status = ?
  AND created_at >= ?
  AND created_at 

如果执行计划还是不稳定，再去检查表的统计信息和数据倾斜的情况。不要一看到执行计划的 key 变了就随便加索引提示；提示会把当时的判断硬编码固化，后续数据分布发生变化之后反而很难调整回来。

常见问题与回归边界

预编译语句是不是一定比拼接 SQL 慢？

不是。预编译的核心作用是减少重复解析开销，还能避免直接把用户输入拼接进SQL带来的注入风险。碰到慢查询的时候，应该先去比对参数类型、执行计划和实际扫描数据量的差异。

EXPLAIN 的 rows 就是实际读了多少行吗？

不是。rows 只是优化器给出的估算值，实际情况要结合 EXPLAIN ANALYZE 或者数据库监控里的真实扫描指标做核对。

给字段加 CAST 就能修复类型问题吗？

不一定。如果 CAST 函数作用在索引列上，很可能导致索引没法直接被使用。更稳妥的处理顺序是把绑定参数先转换成字段本身定义的类型，再做比较。

为什么同一条语句不同客户速度差很多？

不一定。不同客户的数据量、状态分布和查询的时间范围都可能不一样。先把参数类型固定对齐，再分别比对执行计划和实际扫描行数，才能区分出是数据倾斜导致的问题，还是类型转换导致的问题。

把一次偶发变慢变成可回归检查

发布之前准备两组数据分布差异比较大的客户测试数据，分别用字面量写死值的方式和参数绑定的方式执行查询，保存 EXPLAIN 的输出结果和实际运行耗时。回归校验的项至少要覆盖：参数绑定类型、用到的索引名、预估行数、实际扫描行数、排序逻辑有没有落到额外的文件排序步骤、以及时间范围的边界值是否完全匹配。

做完这些适配之后，预编译语句就不再是一个「开或者关」的性能开关，而是应用侧数据进入 MySQL 的一条完整链路：先把类型对齐，保证查询条件可以走索引，最后再用真实运行的结果复核执行计划是否符合预期。