MAX_QUERIES_PER_HOUR 无效是因为 BI 工具复用连接池，使限速无法覆盖并发查询；应改用 MAX_USER_CONNECTIONS 限制单账号并发连接数，并结合慢查询日志与 pt-query-digest 识别高频高成本 SQL。
为什么直接用 MAX_QUERIES_PER_HOUR 不起作用
MySQL 的 GRANT ... WITH MAX_QUERIES_PER_HOUR 限制只对「单个用户连接」生效，而 BI 工具（比如 Tableau、Power BI）通常复用连接池、长连接或并发拉取多个查询，导致限速被绕过——每个新查询可能落在不同连接上，总频次不受控。
用 max_connections + max_user_connections 组合控制并发量
真正能压住 BI 系统资源水位的是连接数限制，不是每小时查询数。关键在两个参数协同：
-
max_user_connections：限制该账号**同时最多能建几个连接**，必须设为小值（如5），否则 BI 一开多张仪表板就打满 -
max_connections是全局配置，但对账号无效；必须靠max_user_connections配合账号级GRANT - 执行前确认 MySQL 版本 ≥ 5.7（
max_user_connections在 5.6 中仅对 SUPER 用户有效）
实操命令：
CREATE USER 'bi_reader'@'%' IDENTIFIED BY 'strong_pass'; GRANT SELECT ON mydb.* TO 'bi_reader'@'%' WITH MAX_USER_CONNECTIONS 5;
配合 long_query_time + 慢查日志定位高成本查询
BI 报表常带未加索引的 GROUP BY 或全表扫描，单纯限连接数只能防雪崩，不能治根。需要主动识别问题 SQL：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 临时开启慢查：
SET GLOBAL slow_query_log = ON;，并设long_query_time = 1（秒） - BI 查询一般不走缓存，且常含
ORDER BY RAND()、SELECT *、无 WHERE 的聚合，这些要重点盯 - 查日志：
mysqldumpslow -s t /var/lib/mysql/slow.log找出耗时 TOP5 的 BI 查询
用 pt-query-digest 做查询指纹归类和频率统计
BI 系统发的 SQL 往往参数不同但结构一致（如 WHERE date = '2024-01-01' → WHERE date = '2024-01-02'），人工看慢日志很难发现规律。用 Percona Toolkit 归一化：
pt-query-digest --filter '$event->{fingerprint} =~ m/^SELECT.*FROM reports/' /var/lib/mysql/slow.log
输出里重点关注：Count（调用频次）、Query_time_sum（总耗时）、Rows_examined_avg（扫描行数）。高频+高扫描的查询，就是该让 BI 团队加索引或改写的地方。
真正的难点不在设限速账号，而在区分「合理报表查询」和「开发测试误跑的全表扫描」——后者往往用同一个账号，却把连接池和慢查指标全拖垮。
