必须先移除 AUTO_INCREMENT 再删除主键；直接删主键或单独去自增均报错；去掉自增需 MODIFY COLUMN 显式重申所有属性；删主键后 InnoDB 可能启用隐式主键或 row_id，影响性能与兼容性。
ALTER TABLE 先删 AUTO_INCREMENT 还是先删主键
必须先移除 auto_increment，再删除主键约束。反过来操作会报错——mysql 不允许在主键列上直接去掉 auto_increment 属性，但更关键的是：**你根本不能在保留主键的前提下单独删掉 auto_increment**。
常见错误现象：ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key，或者执行 MODIFY COLUMN 时提示列已为键但缺少索引定义。
- 主键列若带
AUTO_INCREMENT，MySQL 强制要求它必须是（前缀）索引的一部分，且不能有其他列在它前面参与联合主键 - 想改主键列的属性，本质得重建该列定义；而
CHANGE/MODIFY COLUMN要求新定义与旧定义在键约束上兼容，否则直接拒绝 - 所以标准路径是：先用
ALTER TABLE ... MODIFY COLUMN去掉AUTO_INCREMENT（此时仍为主键），再用ALTER TABLE ... DROP PRIMARY KEY删主键
去掉 AUTO_INCREMENT 的正确写法（含类型重申）
不能只写 MODIFY COLUMN id INT —— 这会丢掉列的非空和默认行为，还可能意外触发类型隐式转换。必须显式补全原有属性，否则容易导致数据截断或默认值异常。
使用场景：原列是 id INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY，现在要保留 NOT NULL、去掉自增、后续再删主键。
- 正确写法：
ALTER TABLE users MODIFY COLUMN id INT NOT NULL; - 如果原列有
DEFAULT或注释，也得一并带上，比如：MODIFY COLUMN id INT NOT NULL DEFAULT 0 COMMENT 'user id' - 注意：
INT(11)中的(11)是显示宽度，不影响存储，可省略；但UNSIGNED不能漏，否则可能引发插入负数或溢出 - 执行后查
SHOW CREATE TABLE users，确认AUTO_INCREMENT已消失，且PRIMARY KEY仍在
删除主键后可能触发的隐性问题
主键删掉不等于“恢复成普通表”，MySQL 会自动把第一个 NOT NULL 的唯一索引升为隐式主键（仅 InnoDB）。这会影响后续加主键、外键或某些 ORM 的映射逻辑。
性能影响：没有主键的 InnoDB 表会生成隐藏的 6 字节 row_id 作为聚簇索引，写入时可能产生页分裂，且无法用主键做高效范围扫描。
- 删完主键后务必检查：
SHOW INDEX FROM users，看是否残留唯一索引被自动选中 - 如果真要彻底无主键，得连带删掉所有唯一索引，否则
row_id不会启用 - 有些迁移工具（如 pt-online-schema-change）会拒绝操作无主键表，部署前得确认下游兼容性
替代方案：其实多数时候不该删主键
业务上想“不让主键被修改”，通常不是真要删主键，而是防止误更新。这时候加个 BEFORE UPDATE 触发器比动结构安全得多。
容易踩的坑：为了“释放主键控制权”而去掉主键，结果导致 SELECT ... FOR UPDATE 锁全表、JSON 函数解析失败、甚至备份工具报错跳过该表。
- 如果只是禁止更新主键值，用触发器拦截更轻量：
IF OLD.id != NEW.id THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Primary key cannot be updated'; END IF; - 如果主键字段要改成可空或变类型，优先考虑新增一列做业务主键，原主键留着维持物理结构稳定
- 真正需要删主键的场景极少，常见于历史遗留宽表清洗、ETL 中转临时表等一次性任务
最麻烦的不是语法顺序，而是删完之后没人记得这张表已经没主键了——下次加索引、设外键、导数据，问题才集中爆发。
