自增主键插入快但高并发易锁表，uuid主键导致索引膨胀和随机写入抖动；mysql 8.0+可启用交错模式优化自增锁，uuid应存为binary(16)并避免用于业务序号。
自增主键插入快，但并发写入时容易锁表
MySQL 的 AUTO_INCREMENT 主键在单线程或低并发下插入极快，因为新值只是递增一个整数，B+ 树索引页分裂少、定位简单。但高并发插入时，InnoDB 会为 auto_inc_lock 加表级锁（直到 5.6 才优化为轻量互斥锁），多个事务抢同一个“下一个值”，实际变成串行化写入。常见现象是监控看到 innodb_row_lock_waits 上升，或应用日志里大量 Lock wait timeout exceeded。
实操建议：
- 如果业务有明显写入峰值（比如秒杀、日志上报），别只看平均 QPS，压测时用 10–20 个并发线程持续插入，观察
SHOW ENGINE INNODB STATUS中的SEMAPHORES和锁等待段 - MySQL 8.0+ 可开启
innodb_autoinc_lock_mode = 2（交错模式），但要求 binlog_format = ROW，否则主从不一致 - 不要把
AUTO_INCREMENT当业务序号用——比如“订单号第10001单”，一旦回滚或批量插入失败，序号就跳变，前端对不上
UUID 主键导致二级索引膨胀和随机写入抖动
用 UUID() 或 uuid_generate_v4() 生成的主键是 128 位无序字符串，InnoDB 主键即聚簇索引，数据物理存储顺序完全打乱。每次插入都可能触发页分裂、旧页合并、缓冲池频繁换入换出。更糟的是，所有二级索引的叶子节点都存主键值，UUID 比 BIGINT 大 16 字节 → 每条二级索引记录多占 16 字节，索引体积直接涨 30%–50%，内存命中率下降。
实操建议：
- postgresql 若必须用 UUID，优先用
gen_random_uuid()（需pgcrypto），而非uuid_generate_v4()，前者更均匀，减少局部冲突 - MySQL 不要直接用
UUID()函数——它返回带横杠的 36 字符字符串，应转成UNHEX(REPLACE(UUID(), '-', ''))存为BINARY(16)，节省空间且比较更快 - 如果已有 UUID 主键且查询慢，检查
SHOW INDEX FROM table_name的Cardinality是否严重偏低，这往往是索引碎片+统计信息不准共同导致
插入性能差距在 3 倍以上，但只在数据量超千万后才明显
小表（
实操建议：
- 压测别只跑 1 分钟——至少持续 10 分钟，观察
Innodb_buffer_pool_reads是否持续上升，这是磁盘 IO 被迫介入的信号 - 用
pt-index-usage或sys.schema_index_statistics查看真实索引访问频次，避免“以为加了索引就快”，其实大部分查询走的是全表扫描 - 如果业务允许，可折中：用
ULID或KSUID替代 UUID——它们时间有序，聚簇性比 UUID 好得多，插入性能接近自增，又保留全局唯一性
索引碎片不是“跑个 OPTIMIZE 就完事”
OPTIMIZE TABLE 对自增主键表基本没用（碎片率通常 DATA_FREE 字段只反映空闲页数，不反映页内碎片。
实操建议：
- 别依赖
SHOW TABLE STATUS的Data_free判断是否需要优化，改用SELECT page_count, page_used_ratio FROM sys.innodb_buffer_stats_by_table WHERE table_name = 'your_table' - 真正有效的做法是控制写入节奏：比如用队列削峰，或按时间分表（
orders_202406），让每个物理表保持在 200–500 万行以内 - PostgreSQL 用户注意：
VACUUM FULL类似OPTIMIZE，但会锁表且不可中断；日常用VACUUM即可，重点调好autovacuum_vacuum_scale_factor
UUID 和自增不是非此即彼的选择，关键看写入模式是否真随机、二级索引有多少、以及能不能接受主键暴露业务增长节奏。最容易被忽略的，其实是开发阶段没模拟真实数据分布——用 100 条 UUID 插入看不出问题，等上线三个月数据长到两亿，再改主键就是大手术。