mysql限流与降级的核心是保护数据库、保障核心业务、牺牲非关键体验；需监控瓶颈指标、压测摸底、区分读写；采用连接数限制、用户级限流、SQL拦截；应用层配合读/写/功能降级；预案须一键触发并定期演练。
面对突发流量，MySQL 限流与降级不是“要不要做”的问题，而是“怎么做才有效”的问题。核心思路是：保护数据库不被压垮、保障核心业务可用、牺牲非关键路径的体验。
一、识别瓶颈，先知道哪里会崩
限流和降级的前提是清楚数据库的承载边界。不能等 CPU 100%、连接数打满、慢查询堆积如山才反应过来。
- 监控关键指标：活跃连接数（Threads_running）、每秒查询数（QPS）、慢查询数量、InnoDB 行锁等待时间、主从延迟
- 压测摸底：用 sysbench 或真实业务流量模拟，明确单实例在稳定状态下的安全 QPS 和连接上限（例如：连接数 ≤ 300，QPS ≤ 1200）
- 区分读写：写操作通常更重，主库比从库更脆弱；读多写少场景下，优先保写、限读
二、MySQL 层面的轻量限流手段
- 连接数限制：通过 max_connections 控制总连接上限，并配合应用端连接池配置（如 HikariCP 的 maximumPoolSize），避免连接雪崩
- 用户级限流：用 CREATE USER … WITH MAX_CONNECTIONS_PER_HOUR 或 MAX_QUERIES_PER_HOUR 限制特定账号（如报表账号、第三方同步账号）的资源消耗
- SQL 级拦截（需 proxy 或审计插件）：例如使用 MySQL router + 自定义规则，或 Percona Toolkit 的 pt-kill 杀掉运行超时/扫描行数过多的查询
三、应用层配合降级策略
数据库只是链路一环，真正的弹性来自应用主动让步。
- 读降级：缓存失效时，不穿透查库，返回旧缓存（stale-while-revalidate）或兜底静态页；非实时数据（如“历史订单总数”）直接返回缓存值或默认值
- 写降级：日志类、统计类、通知类写入可异步化（进消息队列），失败时暂存本地磁盘或内存，待流量回落再补偿
- 功能降级：关闭“猜你喜欢”“实时排行榜”等强依赖复杂 SQL 的模块，前端灰度隐藏入口，后端直接返回空数组或 mock 数据
四、预案要能一键触发，不能靠人肉操作
突发流量来临时，没人有时间登录服务器改配置或手动 kill 进程。