主键查询慢通常因类型不匹配引发隐式转换致索引失效；如URL传字符串id导致WHERE id='123'全表扫描，或软删除字段delete_time类型不符使联合索引失效，需强制类型转换、用whereNull()及模型类型声明对齐数据库实际类型。
主键查询慢，大概率不是主键本身的问题，而是类型不匹配导致的隐式转换，让 MySQL 放弃使用主键索引。
WHERE 中的主键值类型和字段类型不一致
ThinkPHP 默认主键是 id，通常是 INT 或 BIGINT。但如果你传入的是字符串（比如前端 URL 里带 ?id=123，没做类型转换），PHP 接收后是 string，而 ThinkPHP 构建 SQL 时若未强转，MySQL 就会把整型主键字段隐式转成字符串比对——触发全表扫描。
- 典型现象：
EXPLAIN显示type=ALL或key=NULL，哪怕id是主键 - 常见来源：URL 参数、JSON 请求体、表单提交未校验类型；
$_GET['id']直接喂给where('id', $id) - 验证方式：用
Db::getLastSql()看生成的 SQL，如果写成WHERE id = '123'（带引号），基本就是它了 - 修复动作：在查询前强制转整型，例如
$id = (int) input('id');或intval(input('id'))，再传入where('id', $id)
软删除字段 delete_time 参与主键类查询时失效
ThinkPHP 默认开启软删除，delete_time 字段常被设为 INT 或 DATETIME。当查询条件同时含 id 和 delete_time=null，但 delete_time 字段类型是 DATETIME，而你传的是 0 或空字符串，MySQL 同样会做隐式转换，导致联合索引或主键索引部分失效。
- 错误写法：
where('id', 100)->where('delete_time', null)（null在某些驱动下会被转成'NULL'字符串） - 正确写法：
where('id', 100)->whereNull('delete_time')，或显式用where('delete_time', 'exp', 'IS NULL') - 更稳妥：确保
delete_time字段允许为NULL，且业务层统一用whereNull()/whereNotNull()，避免值类型歧义
模型定义中主键类型声明与数据库不一致
ThinkPHP 模型支持手动声明主键类型，如 protected $pk = 'id'; protected $type = ['id' => 'integer'];。但如果数据库里 id 是 BIGINT UNSIGNED，而模型只写 'integer'，某些版本的 PDO 或 MySQL 驱动在绑定参数时可能降级处理，导致索引无法命中。
- 检查点：用
SHOW CREATE TABLE users;确认主键真实类型（尤其注意UNSIGNED和长度） - 模型适配：
protected $type = ['id' => 'bigint'];（ThinkPHP 6.1+ 支持）或'id' => 'integer|big（视版本而定） - 绕过风险：不用模型的自动类型转换，改用原生查询
Db::table('users')->where('id', (int)$id)->find()，可控性更高
最易被忽略的是：你以为在查主键，其实 MySQL 正在全表扫描——因为那一行 WHERE id = '123' 里的单引号，已经悄悄关掉了索引。类型对齐不是细节，是查询是否走索引的开关。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
