大促期间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拖垮连接池。
