直接修改业务表主键极危险，易破坏一致性、引发外键断裂等；ALTER TABLE DROP PRIMARY KEY 常因隐式主键、约束冲突或数据问题失败；改主键类型须按删主键→改列→重建主键顺序执行；更新主键值高危，应避免；优先优化设计而非修改主键。
直接修改业务表的主键（尤其是已有数据的表）不是“改个字段”那么简单，它极大概率会破坏数据一致性、引发外键断裂、触发复制延迟，甚至导致应用报错。除非你明确知道为什么必须改，且已评估所有依赖关系，否则应优先考虑替代方案。
ALTER TABLE DROP PRIMARY KEY 会失败的常见原因
执行 ALTER TABLE t1 DROP PRIMARY KEY 报错，通常不是语法问题，而是因为：
- 表使用的是
InnoDB引擎，而该表没有显式定义主键——MySQL 会隐式创建一个不可见的聚簇索引，此时DROP PRIMARY KEY会报错ERROR 1075: Incorrect table definition； - 主键列上同时存在其他约束（如
UNIQUE或FOREIGN KEY），需先删约束或级联处理； - 表中存在重复值或
NULL值，但你试图在删主键后立刻加新主键，MySQL 会在添加时校验失败。
修改主键列数据类型（如 INT → BIGINT）的实操要点
这是相对高频且风险可控的操作，但必须按顺序执行，不能跳步：
- 先用
ALTER TABLE t1 DROP PRIMARY KEY删除原主键（确保无外键引用）； - 再用
ALTER TABLE t1 MODIFY id BIGINT UNSIGNED NOT NULL修改列类型（注意：MODIFY会重写整列，大表要预估锁表时间）； - 最后用
ALTER TABLE t1 ADD PRIMARY KEY (id)重建主键； - 如果原主键是自增的，别忘了补上
AUTO_INCREMENT属性，否则插入时不会自动赋值。
漏掉 NOT NULL 或忘记加 AUTO_INCREMENT 是新手最常踩的坑——加完主键后插入新行会报 Field 'id' doesn't have a default value。
UPDATE 已有记录的主键值（高危！慎用）
直接 UPDATE t1 SET id = 100 WHERE id = 1 在绝大多数情况下会失败，错误是 ERROR 1062: Duplicate entry '100' for key 'PRIMARY'。这是因为 MySQL 在每条 UPDATE 执行过程中实时校验唯一性，而不是等整批更新完再检查。
安全做法只有两种：
- 临时禁用唯一性检查（不推荐）：
SET UNIQUE_CHECKS=0;→UPDATE→SET UNIQUE_CHECKS=1;，但此操作绕过约束，可能埋下数据隐患； - 用变量+排序分步覆盖（仅适用于无外键、无并发写入的离线场景）：
SET @rownum := 0;<br>UPDATE t1 SET id = (@rownum := @rownum + 1) ORDER BY id;
注意：必须带ORDER BY，否则行为不可预测；执行后还需手动调整AUTO_INCREMENT值，否则下次插入会冲突。
真正该优先做的：别改主键，改设计
生产环境中，90% 的“需要改主键”诉求，其实源于早期设计缺失：
- 没预留扩展空间（如用
INT存订单号，快溢出了）→ 应提前用BIGINT； - 主键暴露给前端或用于业务逻辑（如 URL 中的
/user/123）→ 应加一层业务 ID 字段（business_id），主键保持内部自增； - 想让 ID 连续 → 不要强求，
AUTO_INCREMENT本就不保证连续，强行重排代价远大于收益。
外键关联、binlog 解析、ORM 映射、缓存 key 构造……所有这些都默认信任主键稳定不变。一旦你动了它，影响面远超 SQL 语句本身。
