直接执行 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”，它等价于一次全表重建。没备份就动手，等于把数据命运押在一条语句上。
