Symfony3项目主键应据架构选型：单库高性能用自增ID，分布式场景用UUID（存为BINARY(16)），中大型项目可折中采用Snowflake ID；需兼顾开发体验与组件兼容性。
对 Symfony3 项目来说，主键选 UUID 还是自增 ID，不能一概而论，得看你的部署架构、数据规模和安全要求。
单库单应用、读写频繁、强调性能
用自增主键（BIGINT AUTO_INCREMENT）更合适。Symfony3 默认 Doctrine 支持良好，迁移、关联、查询都简洁高效。InnoDB 聚簇索引能充分利用顺序插入优势，百万级以下数据基本无压力。
- 插入快，索引紧凑，范围查询（如分页、时间范围筛选）响应快
- Doctrine 的
@ORM\GeneratedValue(strategy="AUTO")开箱即用，不用额外集成 ID 生成器 - 避免 UUID 带来的字符串比较开销和 B+ 树分裂问题
微服务/多数据库/需数据合并或迁移
优先考虑 UUID（推荐存为 BINARY(16)，不是 CHAR(36)）。Symfony3 中可通过 Doctrine 的 uuid 类型配合 ramsey/uuid-doctrine 扩展轻松支持。
- 各服务独立生成 ID，不依赖中心发号器，天然适配分布式场景
- 历史数据导入、多源表合并、跨库同步时不会主键冲突
- 对外暴露的 API 路径（如
/api/users/9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d）更安全，无法推测总量或遍历资源
折中方案：Snowflake ID（适合中大型 Symfony3 项目）
如果既想要自增的性能，又需要分布式唯一性，可引入雪花算法 ID（64 位整数）。虽然 Symfony3 原生不内置，但通过自定义 ID 生成器 + @ORM\GeneratedValue(strategy="CUSTOM") 完全可行。
- 8 字节存储，和自增一样节省空间，B+ 树高度低
- ID 按时间大致有序，写入仍接近顺序追加，减少页分裂
- 需自行管理机器 ID 分配和时钟回拨容错，适合有运维能力的团队
别忽略实际开发体验
Symfony3 的表单、API Platform、EasyAdmin 等组件对整数主键支持最成熟。若用 UUID，要注意：
- 路由参数需显式声明类型（如
{id}→{id}并在 controller 中校验格式） - 日志、调试、SQL 直查时 UUID 可读性差，建议搭配业务字段（如 slug、code）辅助定位
- 外键字段也必须用 UUID 类型，关联表设计和迁移脚本要同步调整
