当INT主键接近上限时，需先检查Auto_increment值、MAX(id)、删除插入影响、引擎类型；再安全升级为BIGINT，同步更新外键、应用层变量、ORM及缓存日志链路，并评估分库分表必要性。

MySQL自增主键溢出前必须做的检查

当 INT UNSIGNED 主键接近 4294967295、或 INT SIGNED 接近 2147483647 时，插入会直接报错 ERROR 1062 (23000): Duplicate entry '2147483647' for key 'PRIMARY'——这不是重复值，是自增器卡在最大值后反复回绕。别急着改类型，先确认真实瓶颈：是否真由主键耗尽导致？

• 查当前自增值：SHOW TABLE STATUS LIKE 'your_table'; 看 Auto_increment 字段
• 查最大已有 ID：SELECT MAX(id) FROM your_table; 对比是否接近上限
• 检查是否有大量删除+插入导致 Auto_increment 虚高（例如批量导入后删了 90% 数据，但自增未重置）
• 确认表引擎是 InnoDB（MyISAM 的自增行为不同，且不支持事务级安全）

ALTER COLUMN 到 BIGINT 的实操要点

把 INT 改成 BIGINT 是最直接的解法，但线上表不能只执行一条 ALTER TABLE t MODIFY id BIGINT UNSIGNED AUTO_INCREMENT; 就完事。

• DDL 会锁表（尤其大表），建议用 pt-online-schema-change 或 MySQL 8.0+ 的 ALGORITHM=INSTANT（仅限某些修改，类型变更通常不支持 INSTANT）
• BIGINT UNSIGNED 最大值是 18446744073709551615，够用几十年，但会多占 4 字节/行——对亿级宽表，总存储和内存开销需重新评估
• 外键约束必须同步更新：关联该主键的所有子表字段也要改成 BIGINT，否则 ALTER 会失败
• 应用层检查所有 int 类型变量（如 Java 的 Integer、Go 的 int）、ORM 映射（如 MyBatis 的 resultType）、JSON 序列化逻辑，避免截断或解析异常

分库分表不是“主键不够”的万能解药

如果单表已超 5000 万行、QPS 持续 >2000，或业务上天然存在多租户隔离需求（如 SaaS），才值得引入分库分表。只为解决主键耗尽而分片，反而增加复杂度和故障面。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 分片键选错会导致热点：比如用 user_id 分片，但某大客户订单量占全量 40%，所有写请求都打到同一分片
• 全局唯一 ID 不能依赖自增：得换方案，如 TinyID、Leaf、Snowflake 或数据库号段模式，这些服务本身也有容量上限，要提前压测
• 跨分片 JOIN、ORDER BY、GROUP BY 无法下推，应用层要聚合，延迟和内存消耗陡增
• 备份、DDL、数据迁移难度指数上升——一个 ALTER 变成 N 个库各执行一次，还要保证顺序和一致性

真正容易被忽略的细节

主键类型变更后，最容易翻车的地方不在数据库，而在缓存和日志链路。

• Redis 缓存 key 若拼接了 id（如 order:123），没问题；但若用了 order:000000123 这类固定长度格式，BIGINT 后位数变长，旧 key 失效且无法自动迁移
• Elasticsearch 或 ClickHouse 同步任务，若用 id > last_sync_id 增量拉取，last_sync_id 存储字段类型没升级，会溢出变负数，同步直接中断
• Binlog 解析服务（如 Canal）消费时，若用整型反序列化 id 字段，而下游仍是 int32，同样会截断——这问题上线后才暴露，排查极难
• 监控告警规则里硬编码的 MAX(id) 条件，需要同步更新阈值