where id = '123' 必然导致索引失效，因字段为int却传字符串参数，触发隐式类型转换致全表扫描；explain中key=null或extra仅含using where即为典型征兆。

为什么 WHERE id = '123' 会拖慢查询

当字段 id 是 INT 类型，却用字符串参数（如 '123'）去查，MySQL/PostgreSQL 会悄悄把整列转成字符串再比对——这意味着无法走索引，全表扫描就来了。不是“可能变慢”，是“必然丢索引”。

• 常见错误现象：EXPLAIN 显示 type=ALL 或 key=NULL，哪怕 id 上明明建了索引
• 触发条件：参数类型和字段类型不一致，且数据库没做显式 cast（比如没写 CAST(? AS SIGNED)）
• 注意：PHP 的 PDO::ATTR_EMULATE_PREPARES=true 默认开启时，预处理语句也可能触发隐式转换，因为参数没真正传给服务端类型校验

怎么一眼看出是不是隐式转换在作怪

直接看执行计划里的 Extra 字段。只要出现 Using where; Using index 是健康的；一旦看到 Using where 单独出现，尤其配合 key=NULL，八成就是类型不匹配。

• MySQL 下执行：EXPLAIN FORMAT=TREE SELECT * FROM users WHERE id = '123';，重点盯 attached_condition 里有没有 cast 或 convert
• PostgreSQL 下用：EXPLAIN (ANALYZE, VERBOSE) SELECT * FROM users WHERE id = '123';，看 Filter: 行是否含 id::text = '123'::text
• 应用层日志里如果看到绑定参数是 "123"（带引号），而字段是数字型，就要警觉——ORM 如 Laravel 的 where('id', $x) 在 $x 是字符串时不会自动转 int

PreparedStatement 也不能高枕无忧

预编译语句只保“语法安全”，不保“类型安全”。JDBC、pgx、mysql2 等驱动默认按传入变量的 Go/Python/JS 类型推断参数类型，如果传的是字符串，它就真发字符串过去。

• Java JDBC 示例：用 ps.setString(1, "123") 查 INT 字段 → 隐式转换；改用 ps.setInt(1, 123) 才对
• Node.js mysql2：如果 id 来自 URL 查询参数（req.query.id），它一定是 string，必须手动 parseInt(req.query.id) 再传
• Golang pgx：pgx.Conn.QueryRow(ctx, "SELECT * FROM t WHERE id = $1", "123") → 错；应确保传 int64(123) 或显式 pgtype.Int4{Int32: 123, Status: pgtype.Present}

上线前快速检查清单

别等慢查询报警才想起这事。每次加新查询或改参数来源，花 30 秒扫一遍：

• 查字段定义：DESCRIBE table_name 或 \d table_name，确认类型是 INT/BIGINT/UUID 等，不是 VARCHAR
• 查参数来源：URL query、form body、JSON 字段、环境变量——这些几乎全是字符串，必须显式转换
• 查 ORM 调用：Laravel 的 where()、Django 的 filter(id=x)、TypeORM 的 .where({ id: x })，都依赖 x 的运行时类型，不是声明类型
• 查慢日志里的实际 SQL：如果看到 WHERE id = '123' 这种带引号的值，基本可以锁定问题

最麻烦的不是发现不了，而是它在线上跑了一年都 OK，直到某天数据量涨十倍，全表扫描才突然爆发——类型不一致的问题，往往藏得越久，爆得越痛。