应用连接MySQL时收到ERROR 1203，提示用户已经拥有超过max_user_connections允许的活跃连接。此时数据库未必达到全服务器的max_connections，受限的可能只是某个应用账户。
先确认报错账户和限制来源，再决定是否加大连接数。
区分账户上限与服务器总量
MySQL官方错误参考将1203归为ER_TOO_MANY_USER_CONNECTIONS。max_connections是服务器整体连接上限，max_user_connections限制每个账户并发连接；账户本身还可以设置MAX_USER_CONNECTIONS。
在有权限的管理会话中查看SHOW VARIABLES LIKE 'max_user_connections';，同时核对账户定义和SHOW GLOBAL STATUS LIKE 'Threads_connected';。不要把1203直接归咎于全局连接数不足。
找到连接从哪里累积
检查应用实例数、每实例连接池最大值、定时任务和部署期间的新旧进程是否同时占用连接。可用SHOW PROCESSLIST;观察当前连接和状态；若权限不足，需要管理员协助查看。连接短时间频繁建立还可能在服务器尚未处理断开时触发边界错误。
持续增加的Sleep连接或未释放的事务，应优先从应用生命周期和连接池处理。单纯放大限额可能扩大内存占用。
安全调整限额
MySQL官方账户资源限制文档说明，账户的非零MAX_USER_CONNECTIONS会使用账户级数值；为零时由全局max_user_connections决定。修改前确认真实账户名及主机部分、现有配置和权限，评估应用实例峰值与服务器内存，再在维护窗口调整。
不要用无限制账户替换应用账号，也不要为了报错而开放更多权限。账号级限额与连接池应共同规划。
验证恢复和容量
在萤光云或LightNode的独立VPS复现相同的连接池配置，再按预估峰值逐步压测。生产环境观察错误1203是否消失、Threads_connected趋势和应用延迟，同时确认没有触及整体连接上限。
验收是峰值时连接稳定、连接数可回落，且数据库仍有容量余量。
制定回退与监控
记录修改前后的账户限制、应用连接池参数和实例数。变更后观察连接峰值与拒绝次数；若连接持续增加，优先回退过大的池设置并修复连接泄漏，而不是继续上调数据库阈值。
限额只是保护边界，不能代替连接回收。
FAQ
问：max_user_connections设为0一定是不限制吗？答：要区分账户资源选项与全局变量；账户值为0时仍可能受全局非零值约束。
问：为什么某次断开后立刻重连仍报1203？答：官方文档指出服务器尚未完全处理断开时可能短暂出现该错误，应检查重连风暴及连接池行为。
温馨提示
温馨提示：保存修改前的账户资源限制和全局参数，按应用实例规模设告警阈值，不要把连接数调到超过VPS可承受容量。
