MySQL中直接执行DROP PRIMARY KEY会报错，因自增列必须为主键；需先移除AUTO_INCREMENT属性再删主键，且外键依赖、隐式主键生成及大表锁表等问题均需前置处理。
直接执行 DROP PRIMARY KEY 会报错？先看主键有没有自增
MySQL 中删除主键不是一句 ALTER TABLE t DROP PRIMARY KEY 就能搞定的——尤其当主键列还带 AUTO_INCREMENT 时，MySQL 会直接拒绝执行，并报错：ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key。这是因为自增属性和主键强绑定，不能只删主键而留着自增。
正确顺序必须是：
- 先去掉
AUTO_INCREMENT属性（注意：这步不改数据，只改表定义）ALTER TABLE t CHANGE id id INT NOT NULL; - 再删主键
ALTER TABLE t DROP PRIMARY KEY;
如果跳过第一步，第二步必然失败。别指望加 IF EXISTS 或换引擎能绕过——这是 InnoDB 的硬性校验逻辑。
有外键依赖时，DROP PRIMARY KEY 会被拦截
如果你的主键被其他表用作外键（比如 orders.user_id → users.id），MySQL 会直接报错：ERROR 1025 (HY000): Error on rename of './db/#sql-xxx' to './db/t' (errno: 150)。这不是语法问题，而是约束保护机制在起作用。
必须提前处理依赖关系：
- 查出哪些表引用了该主键：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 't' AND REFERENCED_COLUMN_NAME = 'id'; - 在从表上先删外键约束：
ALTER TABLE orders DROP FOREIGN KEY orders_ibfk_1;（约束名需按实际查出的填） - 确认无依赖后，再执行主键删除
别尝试用 SET FOREIGN_KEY_CHECKS = 0 临时关闭——它只影响 INSERT/UPDATE/DELETE，对 DDL（如 DROP PRIMARY KEY）无效。
删完主键，表就“没主键”了？InnoDB 会悄悄补一个隐藏主键
很多人以为删掉主键后，表就彻底没主键了。但 InnoDB 引擎不会允许这种情况：如果表没有显式主键，又没有非空唯一索引，InnoDB 会自动生成一个 6 字节的隐藏列（DB_ROW_ID）作为聚集索引键。这个键不可见、不可查、不可改，但会影响性能和复制。
更糟的是，这种隐式主键会导致：
- 备库同步延迟加剧（每个 binlog event 都要全表扫描匹配行）
- 无法使用
EXPLAIN准确分析查询路径 - 后续加主键时若数据已存在重复值，会直接失败
所以删主键前务必想清楚：你真的不需要主键？还是只是想换一个？如果是后者，建议一步到位：ALTER TABLE t DROP PRIMARY KEY, ADD COLUMN new_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST;（注意顺序，DROP 和 ADD 可合并为一条语句，减少锁表时间）。
大表删主键卡住？不是语法问题，是锁和校验在拖慢
在千万级表上执行 DROP PRIMARY KEY，可能卡住几十秒甚至几分钟。这不是命令写错了，而是 MySQL 在后台做两件事：
- 重建聚集索引（InnoDB 数据必须按主键物理排序，删主键=重排整张表）
- 逐行检查是否有违反新结构的潜在冲突（比如原主键列含 NULL，而新定义要求 NOT NULL）
应对策略很实际：
- 避开业务高峰，选在低负载时段操作
- 提前在从库验证流程，观察
SHOW PROCESSLIST中是否长时间卡在altering table - 生产环境强烈建议加
ALGORITHM=INPLACE, LOCK=NONE（仅限 MySQL 5.6+ & 支持的场景），但注意：删主键不支持完全无锁，至少需要LOCK=SHARED（允许读，阻塞写）
最常被忽略的一点：删主键不是“轻量 DDL”，它等价于一次全表重建。没备份就动手，等于把数据命运押在一条语句上。
