UUID主键查询变慢主因是字符串存储、索引不当及隐式转换；应改用BINARY(16)（MySQL）或原生UUID类型（PostgreSQL），并规范PHP传参与批量查询方式。
为什么 uuid 主键查询会突然变慢
不是 uuid 本身慢，是默认用字符串存、没建对索引、又常被隐式转换。mysql/postgresql 看到 where id = 'a1b2c3...'，如果字段是 char(36) 或 varchar(36)，索引效率直接打五折——尤其数据量过 10 万后，explain 显示 type: all 就说明全表扫了。
uuid 字段该用什么类型 + 怎么建索引
必须把存储类型从字符串换成二进制，再配合适当索引。Laravel 默认用 string 迁移生成 VARCHAR(36)，这是性能杀手。
- MySQL：用
BINARY(16)存，靠hex2bin(str_replace('-', '', $uuid))转；索引直接建在该字段上，不用前缀 - PostgreSQL：用
UUID原生类型（不是TEXT），它自带高效排序和索引支持 - Laravel 迁移里别写
$table->string('id')->primary()，改用：php artisan make:migration create_users_table --create=users
然后在迁移中写：$table->uuid('id')->primary(); // Laravel 9+ 自动映射为原生 UUID 类型（PG）或 BINARY(16)（MySQL，需配合 doctrine/dbal）
查询时 where 条件写错导致索引失效
哪怕字段类型对了，PHP 层传参稍不注意，就会触发隐式类型转换，让索引彻底失效。
- 错误写法：
Model::where('id', $request->id)->first(); // $request->id 是字符串，带短横线，如 'a1b2-c3d4-e5f6'，MySQL 会尝试转成数字 0，跳过索引 - 正确写法：
use Ramsey\Uuid\Uuid;<br>$uuid = Uuid::fromString($request->id)->getBytes(); // 得到 16 字节二进制<br>Model::where('id', $uuid)->first(); - 更稳妥的 Laravel 写法（推荐）：
Model::whereKey($request->id)->first(); // Laravel 自动识别并做标准化，兼容带/不带短横线、大小写
批量查询 whereIn 性能崩盘怎么办
whereIn 在 UUID 字段上极易出问题：参数一多，数据库就放弃走索引，尤其 MySQL 8.0 之前。不是代码写得不对，是优化器扛不住。
- 别直接传 500 个原始字符串 UUID 进
whereIn，先统一转成二进制或标准格式 - MySQL 下，用
UNHEX(REPLACE(...))包一层（但别在 PHP 拼 SQL，用 Query Builder 的绑定） - 更稳方案：拆成每次 100 个以内，用
collect($uuids)->chunk(100)分批查，再merge() - 如果真要高频批量查，考虑加一个
hash_prefix字段（如取前 4 字符），建联合索引(hash_prefix, id)，先过滤再精查
最常被跳过的点：开发环境用 SQLite 测试没问题，一上生产 MySQL 就慢——因为 SQLite 对 UUID 字符串容忍度高，而 MySQL 的索引规则严得多。上线前务必在同版本生产数据库上跑 EXPLAIN SELECT ... 看执行计划。
