大促期间 SQL 扛压核心是“控”和“让”：通过限流控制非关键流量，降级让出资源给核心链路；限流分关键字、精准、模板三类，降级涵盖读、写及功能层面，并需压测定阈值、双开关机制与慢 SQL 熔断兜底。
大促期间 SQL 层面的扛压，核心不是“扛”，而是“控”和“让”——控制非关键流量，让出资源给核心链路。限流管的是“进来的量”，降级管的是“要做的事儿”，两者配合才能稳住数据库不崩。
SQL 限流：给数据库装上智能闸门
限流是在请求到达数据库前或执行中，按规则拦截、排队或拒绝部分 SQL，防止过载。重点不是一刀切封禁，而是精准干预：
- 关键字限流：紧急止血用。比如直接拦截
DROP TABLE、TRUNCATE、SELECT * FROM big_table这类高危或全表扫描语句，5 分钟内就能生效，适合凌晨被报警叫醒时快速响应。 - 精准 SQL 限流：保护核心业务。例如限制商品详情页的关联查询
SELECT p.*, i.url FROM products p JOIN images i ON p.id = i.product_id WHERE p.id = ?，只允许每秒最多 200 次，避免缓存击穿直打 DB。 - 模板 SQL 限流：微服务友好型。对参数化 SQL 统一管控，如所有用户订单查询
SELECT * FROM orders WHERE user_id = ?，按用户 ID 哈希分桶限流，防止单一恶意用户拖垮整库。
SQL 降级：主动收缩能力，保主干不断
降级不是故障后的补救，而是有预案的主动让步。目标是：宁可查得“糙一点”，也不能卡死或超时。
- 读降级：余额、订单状态等强一致性数据，在大促峰值期可临时降级为从从库或缓存读取，接受秒级延迟；历史订单列表则直接返回缓存快照，不查实时库。
- 写降级：库存扣减这类高并发写操作，可先在本地内存或 Redis 原子计数器中完成，标记为“预占”，高峰过后再异步落库并校验最终一致性。
- 页面 / 功能降级 ：商品页的“相似推荐”“用户评论热榜”等 异步加载 模块，响应超时 300ms 即自动返回空或默认文案，不阻塞主内容渲染。
怎么配？两个关键动作
限流与降级不能靠拍脑袋，得有依据、可开关、能回滚：
- 基于压测定阈值：大促前对核心 SQL 做全链路压测，明确数据库在 CPU≤70%、平均 RT≤50ms 下的 QPS 上限，以此设定限流阈值（如单 SQL 每秒 300 次），而非凭经验设 1000 或 5000。
- 配置双开关机制：所有降级策略必须配套人工开关（如配置中心里的
order_detail_read_degrade=true）+ 自动触发条件（如 DB 主从延迟>5s 或 查询超时率连续 2 分钟>15%），避免误触发也防失联失控。
别忘了兜底：慢 SQL 熔断
限流和降级之外，还要加一层“熔断保险”。对已知的慢查询（如报表类、后台导出），一旦单次执行超 10 秒，立即中断并记录，同时触发告警。这不是限流，而是“拒绝执行”，防止一个慢 SQL 拖垮连接池。
