面对MySQL流量突发，需构建多层防护体系：首先通过连接层限流控制入口流量，合理设置max_connections并利用ProxySQL等中间件；其次在SQL层开启慢查询日志、使用Performance Schema分析热点SQL，并对高负载语句实施熔断；再通过读写分离、业务拆分和cgroups实现资源隔离；最后在应用层结合Sentinel限流、Redis缓存前置及Kafka队列削峰，形成“应用→中间件→数据库”协同防御。
一、连接层限流：控制入口流量
当大量请求涌入数据库时，首先应从连接层面进行限制，防止数据库被压垮。
- 设置最大连接数（max_connections）：合理配置 MySQL 的最大连接数，避免过多连接耗尽系统资源。可通过以下命令查看和调整：
SHOW VARIABLES LIKE 'max_connections';
SET GLOBAL max_connections = 500;
- 生产环境建议结合业务峰值设定，并配合连接池使用。
- 使用中间件限流：如引入 ProxySQL 或阿里云 RDS 代理层，在应用和数据库之间做连接控制与请求拦截，实现更细粒度的限流。
二、SQL 层限流：识别并拦截高负载语句
某些低效 SQL 是流量冲击的直接原因，需通过监控与规则限制其执行。
- 开启慢查询日志：定位执行时间长的 SQL，提前优化。
- 设置 long_query_time，例如记录超过1秒的查询：
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log = ON;
- 利用性能模式（Performance Schema） 分析热点 SQL，找出执行频率高或消耗资源多的语句。
- 通过工具或中间件实现 SQL 熔断：如某类 UPDATE 或全表扫描语句在单位时间内超过阈值，自动拦截后续同类请求。
三、资源隔离：按业务维度划分优先级
不同业务共用同一数据库实例时，一个模块的异常可能拖垮整体服务，必须做资源隔离。
- 读写分离 + 多实例部署：将读请求分流到只读副本，主库专注处理写操作，降低单点压力。
- 按业务拆分数据库或表：核心业务与非核心业务使用独立实例，确保关键链路不受影响。
- 使用 cgroups 或容器限制资源：在物理机或 Docker 环境中，为 MySQL 进程分配 CPU 和内存上限，防止单实例占用全部系统资源。
四、应用层协同：前置防御更有效
数据库不是唯一防线，应用层也应承担部分限流责任。
- 接入限流组件：如使用 Sentinel、Hystrix 在服务层对调用方进行 QPS 控制。
- 缓存前置：高频读请求走 Redis 等缓存，减少对 MySQL 的直接访问。
- 队列削峰：突发写请求先入 Kafka 或消息队列，后端消费程序匀速写入数据库。
