innodb表不必强制自增主键，但无自增主键易引发页分裂、索引膨胀、缓存失效等隐性开销；必须有主键（显式或隐式），否则影响复制、性能与维护。
InnoDB 表不是“必须”有自增主键，但**没有自增主键，就大概率要自己承担页分裂、索引膨胀、缓存失效、写入抖动等一系列隐性开销**。是否强制自增，取决于你愿不愿意为这些代价买单。
为什么InnoDB表必须有主键（但不一定是自增）
如果没有显式定义 PRIMARY KEY，InnoDB 会按顺序找：第一个 NOT NULL UNIQUE 索引 → 若无，则生成一个隐藏的 6 字节 ROWID 作为聚簇索引。问题在于：ROWID 虽然递增，但它只在单表内全局唯一，且无法被业务感知或控制；更糟的是，一旦你加了 NOT NULL UNIQUE 字段（比如 email），InnoDB 就会选它当主键——而字符串类字段天然无序、体积大、易变更。
- 没主键的表在
ROW格式主从复制中可能卡死备库（因为找不到唯一锚点做行定位） -
ALTER TABLE ... DROP PRIMARY KEY会强制重建整张表，不可逆 - 即使加了主键，若类型是
VARCHAR(36)或CHAR(32)，仍会触发后续所有问题
自增主键如何避免页分裂
InnoDB 的聚簇索引叶子节点是双向链表，数据按主键物理排序。插入新行时，引擎必须把数据放到逻辑位置对应的数据页里。自增主键保证每次新值都比前一个大，因此总追加到最右叶子页末尾：
- 页未满 → 直接写入，O(1) 定位
- 页已满 → 分配新页，旧页不动，B+树仅增加一个右兄弟指针
反观 UUID 或时间戳拼接 ID（如 '20261014000001'）：不同会话生成的 ID 在时间上接近但数值不严格递增，插入点随机落在中间页，极易触发页分裂——搬走约一半行、更新父节点、可能连带调整上层节点。长期运行后 Data_free 持续 > 表总大小 5%，基本可判定分裂严重。
主键长度直接影响所有二级索引体积
InnoDB 的每个二级索引（如 INDEX idx_name ON users(name)）叶子节点存的不是行地址，而是**完整的主键值**。主键越长，二级索引膨胀越狠：
-
INT主键：每条二级索引记录占 4 字节 -
VARCHAR(36)存 UUID（UTF8MB4）：实际存储可达 144 字节（含字符集开销） - 1000 万行数据，二级索引体积差可达 3–9 倍
后果是：索引变大 → Buffer Pool 缓存命中率下降 → 更多磁盘随机读 → 查询延迟肉眼可见升高。常见错误是把 CHAR(36) 当主键，却没转成 BINARY(16) 压缩存储。
自增主键不是银弹：并发与安全边界
自增主键的代价藏在细节里：
-
innodb_autoinc_lock_mode = 1（默认）下，批量INSERT SELECT会加语句级锁，高并发写入可能排队 - 自增值可能不连续：事务回滚、
REPLACE、INSERT ... ON DUPLICATE KEY UPDATE、服务器重启都会跳号 - 对外暴露
/user/12345可能泄露业务增长量，需前端脱敏或加映射层 - 分布式系统中，单机
AUTO_INCREMENT无法水平扩展，得换Twitter Snowflake或Leaf等方案
真正容易被忽略的，是「主键设计一旦上线，修改成本远高于初期决策」——重建表、停写、校验一致性、改所有关联外键和应用代码。与其后期补救，不如建表时就用 id BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT，把麻烦挡在第一道门之外。
