直接查auto_increment值并比对字段理论上限是唯一可靠的预防手段，因max(id)不连续、事务回滚等会导致其失真，须通过show create table或information_schema动态获取真实下一次分配值及类型上限。
直接查 AUTO_INCREMENT 值并比对字段理论上限，是唯一可靠的预防手段。依赖 MAX(id)、监控插入失败日志或等报错再响应，都属于事后补救，此时业务已中断。
怎么查当前自增值和字段上限
必须用数据库元数据接口获取真实下一次分配值，不能靠 SELECT MAX(id)——事务回滚、唯一键冲突都会让 id 不连续，而 AUTO_INCREMENT 才是引擎下一步要写的值。
-
SHOW CREATE TABLE users：直接在输出里找AUTO_INCREMENT=1234567890，最直观，适合人工快速确认 -
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='users'：适合脚本批量扫描多张表，注意该值可能有秒级延迟，但告警足够用 - 查字段类型：
DESCRIBE users或SHOW COLUMNS FROM users LIKE 'id'，确认是int(10) unsigned还是bigint(20) unsigned，再映射到理论最大值（INT UNSIGNED是 4294967295，BIGINT UNSIGNED是 18446744073709551615）
设多少阈值触发告警才合理
建议按 80%～90% 上限设置告警，不是越早越好，也不是越晚越准。
- 低于 70%：基本不用干预，也无需告警，纯属干扰
- 达到 80%：启动评估，检查表大小、外键依赖、归档可行性，准备扩容方案
- 超过 85%：必须进入紧急响应流程，安排低峰期操作窗口
- 超过 90%：风险极高，
AUTO_INCREMENT可能因并发写入跳变加速逼近上限，不能再拖
别用固定数字（比如“超 40 亿就告警”），因为不同表主键类型可能不同；也别用百分比硬编码进 SQL 脚本——应动态计算：current_autoinc > 0.85 * max_value。
ALTER TABLE AUTO_INCREMENT = N 是临时缓解还是饮鸩止渴
它只是把撞墙时间往后推，不是解决方案。而且极易误用导致插入失败。
- 不能设得比当前
MAX(id)小，否则下次插入直接报Duplicate entry 'X' for key 'PRIMARY' - 不能替代类型升级，
INT设成3000000000后，最多再撑几千万条，很快又回到原点 - 仅适用于删过大量冷数据后重置空洞场景，且需配合
OPTIMIZE TABLE（会锁表） - 线上严禁用它来“假装还有空间”，这是掩盖问题，不是管理风险
最容易被忽略的长期隐患
即使你用了 BIGINT UNSIGNED，也要定期检查 AUTO_INCREMENT 值——某些迁移脚本、DBA 手动 INSERT ... VALUES (N, ...)、或跨库同步工具可能绕过自增逻辑，悄悄把 id 写到接近上限的位置，而监控脚本却只盯着“是否为 INT 类型”这一层，完全漏掉风险。
