UUID主键查询变慢主因是字符串存储、索引不当及隐式转换；应改用BINARY(16)（MySQL）或原生UUID类型（PostgreSQL），并规范PHP传参与批量查询方式。
为什么
主键查询会突然变慢
不是 uuid 本身慢，是默认用字符串存、没建对索引、又常被隐式转换。mysql/postgresql 看到
，如果字段是
或
，索引效率直接打五折——尤其数据量过 10 万后，
显示
就说明全表扫了。
字段该用什么类型 + 怎么建索引
必须把存储类型从字符串换成二进制，再配合适当索引。Laravel 默认用
迁移生成
，这是性能杀手。
MySQL：用
存，靠
转；索引直接建在该字段上，不用前缀
PostgreSQL：用
原生类型（不是
），它自带高效排序和索引支持
Laravel 迁移里别写
，改用：
然后在迁移中写：
查询时
条件写错导致索引失效
哪怕字段类型对了，PHP 层传参稍不注意，就会触发隐式类型转换，让索引彻底失效。
错误写法：
正确写法：
更稳妥的 Laravel 写法（推荐）：
批量查询
性能崩盘怎么办
在 UUID 字段上极易出问题：参数一多，数据库就放弃走索引，尤其 MySQL 8.0 之前。不是代码写得不对，是优化器扛不住。
Laravel 13.2.0
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
下载
别直接传 500 个原始字符串 UUID 进
，先统一转成二进制或标准格式
MySQL 下，用
包一层（但别在 PHP 拼 SQL，用 Query Builder 的绑定）
更稳方案：拆成每次 100 个以内，用
分批查，再
如果真要高频批量查，考虑加一个
字段（如取前 4 字符），建联合索引
，先过滤再精查
最常被跳过的点：开发环境用 SQLite 测试没问题，一上生产 MySQL 就慢——因为 SQLite 对 UUID 字符串容忍度高，而 MySQL 的索引规则严得多。上线前务必在同版本生产数据库上跑
看执行计划。
uuidwhere id = 'a1b2c3...'char(36)varchar(36)explaintype: alluuidstringVARCHAR(36)BINARY(16)hex2bin(str_replace('-', '', $uuid))UUIDTEXT$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）whereModel::where('id', $request->id)->first(); // $request->id 是字符串，带短横线，如 'a1b2-c3d4-e5f6'，MySQL 会尝试转成数字 0，跳过索引use Ramsey\Uuid\Uuid;
$uuid = Uuid::fromString($request->id)->getBytes(); // 得到 16 字节二进制
Model::where('id', $uuid)->first();Model::whereKey($request->id)->first(); // Laravel 自动识别并做标准化，兼容带/不带短横线、大小写whereInwhereInwhereInUNHEX(REPLACE(...))collect($uuids)->chunk(100)merge()hash_prefix(hash_prefix, id)EXPLAIN SELECT ...