innodb要求auto_increment列必须是索引最左列（通常为主键首列），否则建表或alter table报错；myisam无此限制，可置于联合索引任意位置。
MyISAM 允许 AUTO_INCREMENT 列不在索引最左位，InnoDB 不允许——这是建表或改表时最容易报错的地方。
ALTER TABLE 时 AUTO_INCREMENT 列必须是索引最左列
InnoDB 要求：如果字段设为 AUTO_INCREMENT，它所在的索引必须是以该字段为最左前缀的索引（通常是主键或唯一索引的首列）。否则执行 ALTER TABLE ... MODIFY COLUMN id INT AUTO_INCREMENT 会直接报错 ERROR 1075: Incorrect table definition; there can be only one auto column and it must be defined as a key。
MyISAM 没这个限制：它可以和其它字段一起组成联合索引，比如 KEY idx_status_created (status, created_at, id)，其中 id 是 AUTO_INCREMENT，也能正常工作。
实操建议：
- 迁移到 InnoDB 前，用
SHOW CREATE TABLE t检查所有AUTO_INCREMENT字段是否已单独建主键，或至少是某个索引的最左列 - 若原 MyISAM 表有
(a, b, id AUTO_INCREMENT)联合索引，InnoDB 下需先加主键ADD PRIMARY KEY (id)，再删掉旧索引 - 不要依赖
ALTER TABLE t CHANGE id id BIGINT AUTO_INCREMENT直接修改类型——即使字段已是主键，也得确保索引定义没被隐式破坏
INSERT 并发下自增值行为差异
MyISAM 使用表级锁，INSERT 时顺序分配 AUTO_INCREMENT 值，不会跳号；InnoDB 在可重复读隔离级别下，为提升并发性能，会预分配一批值（由 innodb_autoinc_lock_mode 控制），导致在事务回滚或批量插入中途失败时出现“空洞”。
常见现象：
- 执行
INSERT INTO t VALUES (),(),()后事务回滚，下次插入可能从 4 开始，而非 1 -
INSERT ... SELECT或LOAD DATA这类批量操作，在innodb_autoinc_lock_mode=1（默认）下会锁住整个自增序列，阻塞其它 INSERT，但能保证连续；设为 2 则不锁，性能高但更易跳号 - MyISAM 没这个问题，它的自增是纯单线程递增的
自增值持久化与崩溃恢复
MyISAM 把当前最大 AUTO_INCREMENT 值存在内存里，只在表关闭时写入 .MYI 文件头；MySQL 异常重启后，会重新扫描数据文件找最大值，可能导致重复或跳号（尤其在并发写未刷盘时）。
InnoDB 将自增值作为元数据写入系统表空间（ibdata1）或独立表空间（.ibd）中，每次 INSERT 后立即持久化。即使崩溃重启，也能准确恢复上一个已分配值，不丢失、不重复。
关键点：
- 别指望 MyISAM 的自增值绝对可靠——它不是 crash-safe 的
- InnoDB 的可靠性代价是写额外元数据，但对绝大多数业务来说值得
- 如果业务逻辑依赖“严格连续无跳号”的 ID（比如对外暴露的订单号），两者都不该直接用
AUTO_INCREMENT，应改用 UUID、雪花算法或业务层生成
真正要命的不是“能不能用”，而是“什么时候会突然失效”——比如你把老 MyISAM 表 ALTER TABLE ... ENGINE=InnoDB 后发现插入报错，或者上线后某天发现 ID 突然跳了 1000，往往就卡在这几个细节上。
