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，直到某天数据量涨十倍，全表扫描才突然爆发——类型不一致的问题，往往藏得越久，爆得越痛。
