MyISAM要求复合主键中AUTO_INCREMENT字段必须为第一列，否则建表失败；其自增值存于.MYI文件，重启不丢失，且仅支持全局递增，不支持按主键分组重置。
MyISAM对复合主键中AUTO_INCREMENT字段的约束很死
MyISAM要求：如果表定义了复合主键，那么AUTO_INCREMENT列**必须是该复合主键的第一列**，否则建表直接失败。它不支持“第二主键字段按第一主键分组自增”这类逻辑——那是应用层或InnoDB+触发器才能模拟的行为。
常见错误现象：ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key，哪怕你写了(a, b)为主键、只给b加AUTO_INCREMENT，MyISAM也会拒掉。
- MyISAM不解析复合主键语义，只做语法校验：自增列必须出现在
PRIMARY KEY定义的最左侧 - 一旦满足该条件（如
PRIMARY KEY (id, group_id)且id是AUTO_INCREMENT），后续插入时忽略id值，由引擎填入递增值 - 若手动指定
id值（比如INSERT INTO t VALUES (100, 'g1')），MyISAM仍会更新表级AUTO_INCREMENT计数器为MAX(id) + 1，但仅当该值≥当前计数器才生效
MyISAM的AUTO_INCREMENT值保存在数据文件里，重启不丢失
和InnoDB（≤5.7）不同，MyISAM把当前AUTO_INCREMENT值直接写进.MYI索引文件，所以服务重启后，这个值不会重算。例如表当前最大id是100，AUTO_INCREMENT=101，删掉id=100行再重启，新插入仍得id=101，不会倒退到100。
使用场景：适合需要强确定性自增行为、且不依赖事务的场景（如日志归档表、统计快照表）。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 但要注意：如果用
ALTER TABLE ... AUTO_INCREMENT = N设了一个比当前最大值还小的N，MyISAM会静默忽略（5.7+版本则报错） - 删除全部数据后
TRUNCATE TABLE会重置AUTO_INCREMENT为1；而DELETE FROM不会 - 备份恢复时，
.MYI文件带走了自增值，所以物理备份天然保序
MyISAM在复合主键下无法实现“每组重置自增”
开发者常误以为“PRIMARY KEY (group_id, seq) + seq AUTO_INCREMENT”能让seq在每个group_id内从1开始递增——MyISAM做不到。它只认整个表的全局最大seq，然后+1，不管group_id是否变化。
容易踩的坑：有人用INSERT IGNORE配合唯一索引模拟“存在即跳过”，再靠应用层查MAX(seq) WHERE group_id = ?来生成下一个值，但这在并发下必然冲突，因为MyISAM的SELECT MAX() + 1不是原子操作。
- 真正要实现分组自增，必须用
SELECT ... FOR UPDATE锁整张表（性能差），或改用InnoDB+触发器+辅助计数表 - MyISAM的
AUTO_INCREMENT本质就是个单变量，没有上下文感知能力 - 别依赖
SHOW CREATE TABLE输出里的AUTO_INCREMENT=xxx来判断“下一个值一定是xxx”——它只是当前计数器，实际插入时仍可能因手动指定值而跳变
MyISAM的自增锁是表级，但并发插入不阻塞读
MyISAM对AUTO_INCREMENT的分配采用简单表级写锁：每次INSERT前锁表 → 读MAX(id) → +1 → 写入 → 解锁。这意味着高并发插入会排队，但SELECT完全不受影响（MyISAM读写锁分离）。
性能影响：在写多读少的场景下，这种串行化插入会成为瓶颈；但若写入量不大（比如每秒几十次），它的开销反而比InnoDB的auto-inc lock更可预测。
-
INSERT ... SELECT、LOAD DATA同样触发表锁，且持续到语句结束 - 没有
innodb_autoinc_lock_mode这类调优参数，行为固定，无需配置 - 如果你看到
SHOW PROCESSLIST里多个INSERT状态为Locked，基本就是自增锁在排队
