不能直接用MODIFY或CHANGE安全改主键字段类型，必须拆解为“删约束→改字段→重建约束”三步，因主键与约束强绑定，类型变更需先解除约束，否则报错ERROR 1075或1068；且大表操作必触发全表拷贝、锁表严重。
不能直接用 MODIFY 或 CHANGE 安全改主键字段类型——必须拆解为“删约束→改字段→重建约束”三步，且每步都可能触发全表拷贝或隐式数据转换。
为什么 ALTER TABLE MODIFY COLUMN id BIGINT 不行？
MySQL 不允许在保留主键约束的前提下直接修改主键字段类型。执行时会报错：ERROR 1075: Incorrect table definition; there can be only one auto column and it must be defined as a key（尤其当主键含 AUTO_INCREMENT 时），或更常见的 ERROR 1068: Multiple primary key defined。本质是：主键约束与字段定义强绑定，类型变更必须先解除约束。
即使绕过语法检查（比如先删主键再改），仍面临两个底层风险：
- 字段改类型时若涉及字符集变更（如
utf8→utf8mb4）或长度缩窄（VARCHAR(255)→VARCHAR(50)），MySQL 会静默截断超长值，不报错也不警告（除非 sql_mode 启用了STRICT_TRANS_TABLES） - 主键字段若被其他表作为外键引用，直接删主键会失败：
ERROR 1553: Cannot drop index 'PRIMARY': needed in a foreign key constraint
改主键字段类型必须显式处理外键和索引
如果主键字段（如 id）被其他表的外键引用，不能跳过外键清理步骤。否则 DROP PRIMARY KEY 会直接报错。
操作顺序必须是：
- 查出所有依赖该主键的外键：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table' AND REFERENCED_COLUMN_NAME = 'id'; - 对每个外键表，先
ALTER TABLE child_table DROP FOREIGN KEY fk_name; - 改完主键字段后，再对每个子表执行
ALTER TABLE child_table ADD CONSTRAINT fk_name FOREIGN KEY (user_id) REFERENCES your_table(id); - 原主键字段上的二级索引（如
INDEX idx_status）不会自动重建，需手动确认是否要重建或调整字段顺序
大表改主键类型时锁表现象比普通字段更严重
主键字段修改几乎必然触发 ALGORITHM=COPY，哪怕 MySQL 版本 ≥ 8.0。因为主键决定了聚簇索引物理布局，类型变更常导致页分裂、B+树重构甚至行迁移。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
验证方式：SHOW PROCESSLIST 中看到状态为 copy to tmp table，且持续时间与表大小正相关。
缓解策略：
- 强制声明
ALGORITHM=INPLACE, LOCK=NONE，但失败时会立刻报错，不硬扛 —— 这比默认行为更可控：ALTER TABLE users DROP PRIMARY KEY, ALGORITHM=INPLACE, LOCK=NONE; - 对千万级以上表，放弃原生
ALTER，改用pt-online-schema-change工具，它通过影子表 + 触发器同步数据，业务写入不受影响 - 务必在低峰期执行；提前调大
innodb_online_alter_log_max_size（默认 128MB），避免因日志空间不足退化为 COPY
数值型主键扩宽（INT → BIGINT）相对安全，但仍有坑
表面看只是“加宽”，没数据丢失风险，但实际要注意：
-
AUTO_INCREMENT值不会自动迁移：原INT UNSIGNED最大值是 4294967295，改成BIGINT UNSIGNED后，自增起点仍是当前最大值，但下次插入会从该值+1开始 —— 若已有数据接近上限，新值可能溢出（虽然概率极低） - 所有关联子表的外键字段也必须同步改为
BIGINT，否则ADD FOREIGN KEY会失败：ERROR 1832: Cannot change column 'user_id': used in a foreign key constraint - 应用层代码、ORM 映射、缓存 key 拼接逻辑若硬编码了
int类型，改库不改代码会导致取值截断（如 Java 的Integer转Long失败）
真正容易被忽略的是：改完主键后，DESCRIBE table_name 看不到 AUTO_INCREMENT 属性了，必须显式加上 MODIFY COLUMN id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT，否则后续插入会报错。
