数据库访问频率限制的核心不是简单地把请求挡在门外，而是要在系统过载之前，用最小的代价识别出异常流量和恶意行为。很多人一上来就想着加Redis计数器、上令牌桶算法，但真正有效的防护往往从数据库连接层和SQL执行层就开始布局了。比如MySQL自带的max_connections和max_user_connections参数，就是第一道物理闸门。默认情况下max_user_connections为0表示不限制，如果某个业务账号被程序Bug拖垮，它能瞬间占满所有连接，导致整个库不可用。给每个业务账号单独设置合理的连接上限，比任何外部限流都直接。
连接层限流：先把入口管住
数据库连接池本身就是天然的限流器。无论你用的是HikariCP、Druid还是C3P0，maximumPoolSize这个参数决定了应用能同时向数据库发起的最大连接数。很多团队把这个值设得很大，以为越大性能越好，实际上当数据库处理能力饱和后，排队等待的连接只会增加锁竞争和上下文切换开销。一个比较实用的做法是：先通过压测确定数据库在业务高峰期的稳定吞吐量，比如每秒能处理2000个查询，那么连接池大小就控制在能支撑这个吞吐量的1.2到1.5倍左右，而不是盲目设置成几百。连接等待超时也要配置，让拿不到连接的线程快速失败，避免请求堆积在应用层。
在数据库账号层面，建议按业务模块拆分账号，而不是所有服务共用一个高权限账号。比如订单服务用order_user，报表服务用report_user，然后分别设置max_user_connections。这样即使报表服务的一个慢查询拖住了大量连接，也不会影响订单服务的正常写入。这个配置可以在线修改，不需要重启数据库：
-- 查看当前用户的连接数限制 SHOW VARIABLES LIKE 'max_user_connections'; -- 为特定账号设置最大连接数 ALTER USER 'report_user'@'%' WITH MAX_USER_CONNECTIONS 20; -- 设置全局默认值 SET GLOBAL max_user_connections = 100;
PostgreSQL也有类似的机制，可以通过角色级别的CONNECTION LIMIT来控制。在创建或修改角色时指定：
ALTER ROLE report_user CONNECTION LIMIT 20;
SQL执行层的频率控制
连接数限制只能防止连接被占满，但一个连接可以连续不断地执行SQL。如果某个接口突然被刷，或者某个定时任务逻辑错误导致死循环查询，连接数没超但数据库CPU会瞬间飙到100%。这时候需要在SQL执行频率上做文章。MySQL 8.0引入了资源组和语句级超时，但更直接的方式是使用ProxySQL或MaxScale这类数据库中间件。ProxySQL的查询规则引擎可以基于用户名、schema、SQL文本匹配等条件，对特定类型的查询进行限速或排队。
比如你发现某个报表接口的SQL每次执行要扫描几百万行数据，可以在ProxySQL中创建一个规则，对这个SQL模板设置max_connections限制，让它最多只能同时跑2个查询，其余的在队列里等待。配置思路大致如下：
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply, max_connections) VALUES (100, 1, 'SELECT.*FROM large_report_table', 0, 1, 2);
如果没有中间件，也可以在应用层用信号量来控制。比如Java里用Semaphore限制某个DAO方法的并发执行数，超过限制的直接抛异常或降级返回缓存数据。这种方式侵入性较强，但对于关键路径的保护非常有效。
应用层限流：识别异常来源
数据库访问频率异常通常来自两类：一是正常业务流量突增，比如秒杀、热点事件；二是恶意爬虫、扫描器或攻击行为。对于第一类，单纯限流会误伤真实用户，更好的办法是结合业务做排队和降级。比如秒杀场景下，先在Redis里用原子操作扣减库存，只有扣减成功的请求才允许写数据库，这样数据库的写入频率就被库存总量天然限制住了。对于第二类，需要根据请求特征做识别。常见的做法是在应用层记录每个用户、IP或设备ID在时间窗口内的数据库操作次数，超过阈值就触发熔断。
实现上可以用Redis的INCR和EXPIRE命令做一个简单的滑动窗口计数器：
-- 伪代码：对用户ID进行限流
local key = "db_rate:" .. userId
local current = redis.call("INCR", key)
if current == 1 then
redis.call("EXPIRE", key, 60)
end
if current > 100 then
return false -- 超过限制
end
return true
这个逻辑在Lua脚本里执行可以保证原子性。阈值要根据业务实际来定，比如普通用户每分钟最多触发50次数据库写操作，超过就返回“操作过于频繁”的提示。对于未登录用户，用IP加设备指纹组合作为限流键，避免单纯用IP误伤整个公司或学校出口的用户。
数据库内置的审计与防护
很多人不知道MySQL从5.7开始就提供了性能模式下的语句统计表，可以实时看到哪些SQL执行频率最高、消耗资源最多。比如events_statements_summary_by_digest这张表，记录了每个SQL模板的执行次数、总耗时、锁等待时间等。定期查询这张表，能快速定位到频率异常增长的SQL：
SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT, SUM_LOCK_TIME FROM performance_schema.events_statements_summary_by_digest ORDER BY COUNT_STAR DESC LIMIT 20;
如果发现某个SQL的执行频率远高于正常水平，可以进一步分析是哪个业务逻辑触发的，然后针对性地做缓存或限流。PostgreSQL的pg_stat_statements扩展也提供类似功能，而且可以直接看到每个SQL的平均执行时间。
另一个容易被忽视的防护点是慢查询。慢查询不仅消耗数据库资源，还会占用连接，间接降低其他请求的可用频率。开启慢查询日志并设置合理的阈值，比如超过1秒的查询都记录下来，然后定期优化。很多数据库被拖垮的起因就是几个慢查询在高频执行下把资源耗尽。
缓存前置：从根源上降低访问频率
最有效的频率限制是让请求根本到不了数据库。在应用和数据库之间加一层Redis或Memcached，把热点数据缓存起来，能直接减少80%以上的数据库读取压力。缓存的设计要讲究策略，不能简单地把所有数据都塞进去。对于读多写少的数据，比如商品详情、用户基础信息，可以设置较长的过期时间，比如10分钟甚至1小时。对于实时性要求高的数据，比如库存、余额，可以用短过期加主动失效的方式。
缓存穿透是另一个需要防范的问题。如果大量请求查询一个不存在的ID，缓存里没有，数据库里也没有，每次请求都会打到数据库。解决办法是用布隆过滤器把不存在的ID提前拦截，或者把空结果也缓存起来，设置一个较短的过期时间。缓存击穿则是指某个热点key在过期瞬间被大量请求同时打到数据库，可以用互斥锁或提前异步刷新来解决。
熔断与降级：保护数据库的最后防线
即使前面所有限流措施都做了，仍然可能出现意外情况，比如突然的流量洪峰、某个隐藏Bug触发了大量无效查询。这时候熔断机制就派上用场了。熔断的核心思想是：当数据库的错误率或响应时间超过阈值时，自动切断部分非核心功能的数据库访问，让系统降级运行。比如用户下单时，如果数据库响应超过2秒，就暂时跳过推荐商品的查询，只返回核心订单信息。等数据库恢复后再自动恢复。
实现熔断可以用Hystrix、Resilience4j这类框架，也可以自己写一个简单的状态机。关键是要设置合理的阈值和恢复策略，避免熔断后无法自动恢复导致功能长期不可用。降级策略要提前设计好，哪些功能可以降级、降级后返回什么默认值、如何通知用户，这些都要在代码里明确。
监控与告警：让频率异常无处遁形
所有限流措施都需要监控数据来验证效果和发现问题。至少要监控这几个指标：数据库连接数、活跃事务数、每秒查询数、慢查询数量、缓存命中率、限流触发次数。当限流触发次数突然增加时，可能意味着有攻击行为或者业务逻辑出了问题。当缓存命中率持续下降时，说明缓存策略需要调整。监控数据要能实时展示，并设置告警阈值，比如连接数超过80%持续5分钟就通知运维人员。
数据库访问频率限制不是单点防护，而是一个多层体系。从连接层的物理限制，到SQL执行层的并发控制，再到应用层的业务限流和缓存前置，最后到熔断降级和监控告警，每一层都有其不可替代的作用。真正有效的防护是让每一层都发挥应有的作用，而不是寄希望于某一个完美的限流算法。根据业务特点选择合适的工具和策略，比盲目追求技术复杂度更重要。
