应监控 auto_increment 值并与字段理论上限比对，优先用 show create table 或 information_schema.tables 获取真实下一次分配值，动态计算 80%~90% 阈值告警，避免使用 max(id) 或 alter table 临时重置，长期需升级主键类型或改用分布式 id。
直接查 AUTO_INCREMENT 值并对比字段上限
MySQL本身不提供“自增上限告警”功能，必须靠外部监控。核心逻辑是：获取当前表的 AUTO_INCREMENT 值，再与该主键字段的数据类型理论最大值比对。例如 INT UNSIGNED 最大为 4294967295，BIGINT UNSIGNED 是 18446744073709551615。不要依赖 MAX(id) —— 因为事务回滚、唯一键冲突都会导致 id 不连续，而 AUTO_INCREMENT 才是真实下一次要分配的值。
用 SHOW CREATE TABLE 或 information_schema 读取当前自增值
两种可靠方式获取当前 AUTO_INCREMENT 值：
-
SHOW CREATE TABLE users→ 输出里找AUTO_INCREMENT=xxx，这是最直观的方式 -
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='users'→ 适合脚本批量扫描
注意：information_schema.TABLES 中的值可能有几秒延迟（尤其在高并发写入时），但用于告警已足够。别用 SELECT MAX(id)，它会漏掉已被分配但未成功插入的 ID（比如事务回滚后留下的空档）。
设置阈值告警（建议 80%~90% 上限）
硬编码阈值容易出错，应动态计算：
- 先查字段类型：
SELECT COLUMN_TYPE FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='users' AND COLUMN_NAME='id' - 根据返回值（如
int(10) unsigned或bigint(20) unsigned）映射到对应上限 - 告警触发条件示例：
current_autoinc > 0.85 * max_value
80% 是较稳妥的起点；设太高（如 95%）留给运维响应的时间太短；设太低（如 50%）会产生大量无效告警。线上建议搭配定时任务（如每小时跑一次）+ 邮件/钉钉通知。
ALTER TABLE ... AUTO_INCREMENT 不能解决溢出，只是临时缓解
有人误以为执行 ALTER TABLE users AUTO_INCREMENT=3000000000 就能“重置风险”，其实只是把撞墙时间推迟——一旦达到新值，照样报 Duplicate entry 'X' for key 'PRIMARY'。真正有效的长期方案只有：
- 升级主键类型：
MODIFY COLUMN id BIGINT UNSIGNED（需锁表，建议在低峰执行） - 改用业务侧生成 ID（如 Snowflake、UUID）
- 分库分表 + 每个分片独立自增
监控只是哨兵，不是解药。最容易被忽略的是：即使你用了 BIGINT，也要定期检查 AUTO_INCREMENT 值——因为某些旧迁移脚本或手动插入可能跳过自增逻辑，悄悄逼近上限而不触发告警。
