数据库资源限流需分级防控：基于会话设硬上限（如MySQL RESOURCE GROUP、PG参数限制），按SQL指纹动态熔断（归一化+阈值触发），联动实例水位主动降级，并依托可观测性实现精准打标与TOPN分析。

单条SQL语句消耗过多CPU、内存或I/O，可能拖垮整个数据库实例。资源限流不是“事后止损”，而是提前设防——核心思路是：按会话/用户/SQL模板分级控制，结合实时监控动态干预。

基于会话（Session）的硬性资源约束

在连接建立时就绑定资源上限，避免失控SQL从源头抢占资源。例如MySQL 8.0+支持RESOURCE GROUP，可限制CPU时间片和并发线程数；PostgreSQL可通过pg_limits扩展或修改postgresql.conf中的statement_timeout、work_mem等参数，并配合pg_stat_activity定期kill超限会话。

• 对报表类应用分配独立账号，创建专属resource group，限制其最大并发为2、CPU使用率≤30%
• 应用连接池配置中显式指定resource_group（MySQL）或application_name（PG），便于后续识别与拦截
• 禁止应用使用root或superuser账号直连，所有连接必须归属受限角色

基于SQL指纹的动态熔断

识别高危SQL模式（如未加LIMIT的全表JOIN、缺失索引的WHERE条件），在执行前或运行中触发限流。依赖SQL解析+规则引擎，常见做法是接入代理层（如ProxySQL、ShardingSphere-Proxy）或数据库插件（如MySQL的query_rewrite + 自定义UDF）。

• 提取SQL指纹：将SELECT * FROM users WHERE id = 123归一化为SELECT * FROM users WHERE id = ?，再哈希入库比对
• 设定阈值：同一指纹每分钟执行超50次，或平均响应时间＞5s持续3分钟，自动切换至只读模式或返回错误码
• 支持人工白名单：运维通过命令行快速放行已知安全的大查询，避免误杀

实例级资源水位联动保护

当数据库整体负载超标（如CPU > 90%、连接数 > max_connections × 0.8），主动降级非核心SQL。这需要数据库暴露指标（如Prometheus Exporter），并由外部控制器（如自研Operator或K8s CronJob）触发策略。

• 监听pg_stat_database中blks_read突增、或mysql.global_status中Threads_running持续高位
• 触发动作包括：临时禁用低优先级用户、设置max_execution_time=1000（MySQL）、或向慢查询日志注入/*+ MAX_EXECUTION_TIME(1000) */提示

• 保护窗口期建议设为5~15分钟，避免频繁抖动；恢复条件需满足连续2次采样均低于阈值

可观测性必须前置建设

限流若缺乏精准度量，容易误伤或漏防。关键不是“有没有限流”，而是“能不能看清谁在耗资源、为什么耗、限得是否合理”。

• 每个SQL执行必须打标：透传app_id、trace_id、business_type到performance_schema.events_statements_history_long或pg_stat_statements
• 构建资源消耗TOPN看板：按用户、schema、SQL指纹三个维度聚合CPU时间、逻辑读、临时磁盘使用量
• 慢日志中增加资源上下文字段，例如记录该SQL执行时实例内存使用率、当前活跃会话数，辅助根因分析