应根据数据规模、分库分表需求、分布式场景及是否暴露业务规律选择：单库用自增主键；分库分表或分布式优先Snowflake（注意PHP 64位整数兼容、workerId动态分配、时钟回拨处理）；需客户端生成且无序用UUID（推荐ramsey/uuid配合MySQL 8.0+ UUID_TO_BIN/BIN_TO_UUID）；兼顾时间序与可读性可用ULID；禁用uniqid()。
PHP中自增主键 vs UUID vs Snowflake 怎么选
没有统一答案，得看你的数据规模、分库分表需求、是否需要分布式ID，以及是否允许数据库暴露增长规律。自增主键在单库场景下最简单高效；但一旦要水平拆分或做读写分离，auto_increment 就容易冲突或暴露业务量——这时候就得换策略。
- 小项目、单MySQL实例：直接用
INT UNSIGNED AUTO_INCREMENT，别折腾 - 多机房/分库分表：避免
auto_increment，优先考虑Snowflake或带时间戳的ULID - 需要客户端生成、不依赖DB、且对排序无要求：用
uuid_create(UUID_TYPE_DEFAULT)（ext-uuid）或bin2hex(random_bytes(16)) - 想兼顾可读性、时间顺序和去中心化：
ULID（如ulid/ulid包）比纯UUID更友好
用 PHP 生成 Snowflake ID 的实际坑点
Snowflake 本身是 Twitter 提出的 64 位整数结构，但 PHP 默认 int 在 Windows 上是 32 位，在 32 位系统或某些 SAPI（如 PHP-FPM 配置不当）下会溢出或截断，导致 ID 错乱甚至负数。直接用 time() + mt_rand() 拼凑不是真 Snowflake，也没时钟回拨容错。
- 必须用支持 64 位整数运算的扩展或库，推荐
moontoast/math或原生gmp处理大数 - 机器 ID（workerId）不能硬编码，需从配置或 Consul/ZooKeeper 动态获取，否则多实例部署会重复
- 务必处理时钟回拨：要么拒绝生成，要么降级为等待或使用
lastTimestamp缓存+序列号补偿 - 生成后建议转成字符串存储（
(string)$id），避免 MySQL 的BIGINT UNSIGNED和 PHP 的 int 类型隐式转换出问题
MySQL 8.0+ 的 UUID_TO_BIN() 和 BIN_TO_UUID() 怎么配合 PHP 用
直接存 CHAR(36) 是浪费空间且索引效率低；而 BINARY(16) 存二进制 UUID 更紧凑，但 PHP 侧必须严格对齐字节序——MySQL 默认用 UUID_TO_BIN($uuid, true) 做「优化排序」（把时间高位移到前面），PHP 生成时也得按同样逻辑重排。
- PHP 生成 UUID 后，先用
hex2bin(str_replace('-', '', $uuid))得到原始 16 字节 - 再手动交换字节：把第0–3字节（时间低）和第4–5字节（时间中）与第6–7字节（时间高+版本）调换位置，才能匹配
UUID_TO_BIN($uuid, true) - 或者偷懒：用
ramsey/uuid库的Uuid::fromString($s)->getBytes()，它默认输出就是优化序，可直传UUID_TO_BIN() - 查询时用
BIN_TO_UUID(col, true)转回可读格式，但注意这个函数只在 MySQL 8.0.1+ 支持
为什么不要在 PHP 层用 uniqid() 做主键
uniqid() 本质是微秒时间戳+可选前缀，没随机性、无机器标识、不防并发，同一微秒内多个请求必然重复。哪怕加 more_entropy=true，底层也只是拼了 microtime() . getmypid()，PID 可复用、微秒精度也不够高。
立即学习“PHP免费学习笔记（深入）”；
- 压测下
uniqid('', true)在 1000 QPS 以上就大概率撞车 - 它返回字符串，长度不固定（通常13–23字符），无法作为高效索引
- 没有全局唯一保障，跨服务器、跨进程、跨重启都不可靠
- 真要轻量方案，用
random_bytes(10)+ base32 编码，至少保证随机熵足够
id_v2 字段双写，再逐步切流量，而不是改个生成函数就上线。 
