不会。ALTER TABLE DROP PRIMARY KEY 仅删除主键约束，不重置 AUTO_INCREMENT；若主键列含 AUTO_INCREMENT，该语句会因 MySQL 强制要求自增列必须属于主键或唯一索引而报错 ERROR 1075，需先移除 AUTO_INCREMENT 属性再执行。
ALTER TABLE DROP PRIMARY KEY 会清空 AUTO_INCREMENT 值吗
不会。执行 ALTER TABLE table_name DROP PRIMARY KEY 本身不会重置 AUTO_INCREMENT 计数器，但会移除主键约束——而 MySQL 要求自增列必须是（或属于）主键或唯一索引。所以一旦你删掉主键，该列若仍是 AUTO_INCREMENT，语句会报错：ERROR 1075: Incorrect table definition; there can be only one auto column and it must be defined as a key。这意味着你必须在 DROP PRIMARY KEY 后立刻处理该列的自增属性。
常见做法是：先去掉 AUTO_INCREMENT 属性（用 MODIFY 或 CHANGE 重新声明列，不带 AUTO_INCREMENT），再删主键；或者一步到位，在修改列类型时顺手去掉它：
ALTER TABLE users MODIFY id BIGINT NOT NULL;
这条语句隐式移除了 AUTO_INCREMENT（因为没写），比先 DROP PRIMARY KEY 再 MODIFY 更稳妥，避免中间状态出错。
修改主键列类型时为什么必须分三步走
MySQL 不允许在保留主键约束的同时直接修改主键列的数据类型。这是硬性限制，不是语法糖缺失。背后原因是：主键约束与索引强绑定，而类型变更可能影响索引结构、排序规则甚至页分裂，MySQL 要求你显式释放约束、变更结构、再重建约束，确保每一步可验证、可回滚。
典型三步顺序不可颠倒：
-
ALTER TABLE users DROP PRIMARY KEY—— 先解除约束，否则后续MODIFY直接失败 -
ALTER TABLE users MODIFY id BIGINT NOT NULL—— 修改列定义（注意补上NOT NULL，因为主键列默认非空，删掉约束后需显式声明） -
ALTER TABLE users ADD PRIMARY KEY (id)—— 重建主键，此时才能加回AUTO_INCREMENT（如需要）
如果漏掉 NOT NULL，第三步会报错：ERROR 1171: All parts of a PRIMARY KEY must be NOT NULL。
批量修改主键ID值时触发 duplicate entry 错误怎么办
直接 UPDATE SET id = new_id WHERE id = old_id 在多行场景下必然失败，因为 MySQL 每执行一行就校验主键唯一性，中间态会出现重复值（例如把 id=1 改成 5 的瞬间，若已有 id=5 的记录，立刻报 duplicate entry '5' for key 'PRIMARY'）。
安全做法只有两种：
- 用临时列中转：新增一个
new_id列 → 批量写入新值 → 交换列名 → 删除旧列（适合大表、不能锁太久） - 反向更新顺序：按 ID 降序更新（如先改 4→8，再 3→7…），确保新值始终大于当前最大 ID，避开冲突（适合小表、ID 连续且目标值递增）
别信“关掉唯一检查”这种方案——SET UNIQUE_CHECKS = 0 不影响主键约束校验，它只跳过唯一索引，对 PRIMARY KEY 无效。
外键关联表存在时修改主键类型有多危险
危险程度：高。不只是“要改其他表”，而是“必须同步协调所有依赖方”。比如 orders.user_id 是外键引用 users.id，那么你改 users.id 类型前，必须：
- 先删掉
orders表上的外键约束（ALTER TABLE orders DROP FOREIGN KEY fk_user_id） - 再改
orders.user_id类型（必须和users.id新类型完全一致，包括 signed/unsigned） - 最后重建外键（
ADD CONSTRAINT ... FOREIGN KEY(user_id) REFERENCES users(id)）
漏掉任意一步，要么改不成功，要么导致外键失效、数据一致性崩坏。更麻烦的是，如果有视图、存储过程、应用层 ORM 映射也依赖该字段类型，它们全得跟着改——这类改动基本无法在线平滑完成，务必安排停机窗口。
