SQL数据库自适应限流通过多维实时指标动态识别风险，按核心、可降级、高危三级分类SQL，分层实施接入层、代理层与内核级限流，并配套可观测与自动回滚机制。
SQL数据库自适应限流，核心是让系统在流量突增或慢查询频发时，自动识别风险并动态限制非关键请求，从而保障核心业务的响应速度与可用性。它不是简单地设个QPS阈值，而是结合实时负载、SQL类型、执行耗时、资源消耗等多维度做决策。
识别哪些SQL该优先保护
并非所有SQL都需要同等保护。应按业务重要性分级：
- 核心SQL：如用户登录、下单、支付相关的SELECT/UPDATE语句，需保障低延迟与高成功率
- 可降级SQL：后台报表、数据导出、历史订单批量查询等，允许延迟、失败或返回简化结果
- 高危SQL：全表扫描、未走索引的JOIN、超长执行（如>5s）、大量排序/临时表操作，应被快速拦截或降权
基于实时指标做动态限流决策
静态阈值容易误伤或失效，推荐用以下指标组合判断是否触发限流：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- CPU使用率持续 >80% 或 IOPS接近磁盘上限
- 平均查询延迟上升超过基线200%，且P95延迟 >1s
- 慢查询数量在1分钟内激增3倍以上
- 连接数接近max_connections，且空闲连接占比低于10%
满足任一条件即启动探测模式；多个条件同时满足则立即限流，并自动标记问题SQL指纹（如MD5(sql_text)）用于后续熔断。
分层限流策略更实用
单一限流方式效果有限，建议组合使用：
- 接入层限流：在应用网关或DAO层识别SQL特征（如含“/report/”路径、“EXPORT”关键词），直接拒绝或排队
- 数据库代理层限流：通过Proxy（如MySQL Router、Vitess、ShardingSphere-Proxy）解析SQL，对非核心库表加权重配额
- 内核级干预（高级）：在MySQL中启用query_response_time插件 + 自定义UDF，或利用Percona Toolkit的pt-kill自动kill慢查询
让限流行为可观察、可回滚
限流不是黑盒操作，必须配套可观测能力：
- 记录每次限流触发原因、影响SQL模板、拦截数量、持续时间
- 暴露Prometheus指标，如sql_throttled_total{type="report",db="user_db"}
- 提供实时控制台，支持手动关闭某类SQL限流（例如大促期间临时放开导出功能）
- 限流策略变更后10分钟内无异常，则固化；否则自动回退至上一版本
