GRANT权限控制对BI工具基本无效，因其仅限制语句类型（如SELECT），无法约束单次查询资源消耗；BI工具用固定账号高频发起复杂SQL，而MAX_*_PER_HOUR等频次限制易被绕过，真正有效的是ALTER USER配置MAX_USER_CONNECTIONS等硬限并配合应用层管控。
MySQL 原生权限系统无法限制 BI 工具的 CPU、内存或单次查询耗时，只能靠 MAX_*_PER_HOUR 类频次限制 + 连接数硬控 + 应用层配合来软性压制——真想防住拖垮服务器的大查询，得绕开权限系统本身。
为什么 GRANT 权限控制对 BI 工具基本无效
BI 工具（如 Tableau、Power BI、Metabase）通常用一个固定账号连接数据库，走的是标准 JDBC/ODBC 协议，权限粒度只到 SELECT / SHOW VIEW 等语句级。但问题在于：
- 只要给了
SELECT权限，它就能执行SELECT COUNT(*) FROM huge_table JOIN ... GROUP BY ...这类高消耗查询，权限系统完全不拦 -
MAX_QUERIES_PER_HOUR限制的是“语句条数”，而 BI 常把几十个指标合成一条带多个子查询的 SQL，1 次请求就只算 1 次，根本卡不住 - BI 工具默认开启连接池，
MAX_CONNECTIONS_PER_HOUR只管mysql_real_connect()调用次数，不是活跃连接数，连池化后的长连接都管不了
真正能起效的三道防线
必须组合使用，单靠任何一项都会漏防：
-
MAX_USER_CONNECTIONS设为低值（如 3–5），强制 BI 工具无法并发拉取多个看板——这是唯一能立刻压住连接爆炸的硬开关 -
MAX_QUERIES_PER_HOUR+MAX_UPDATES_PER_HOUR配合设为非零值（如 300 / 0），主要防自动轮询或前端反复点刷新导致的“小查询海啸” - 在 BI 工具侧配置
max_execution_time（如果支持）或统一加/*+ MAX_EXECUTION_TIME(30000) */提示，否则靠 MySQL 全局max_execution_time不可靠：它只对未显式指定该 hint 的会话生效，且 BI 驱动常覆盖会话变量
ALTER USER WITH 是唯一可用的配置方式
MySQL 8.0+ 已废弃 GRANT 末尾写 WITH MAX_... 的旧语法，它和权限绑定、多 GRANT 记录取最大值等行为极易误判。必须用独立语句：
ALTER USER 'bi_user'@'%'
WITH MAX_USER_CONNECTIONS 4
MAX_QUERIES_PER_HOUR 240
MAX_UPDATES_PER_HOUR 0;
注意：
- 设为 0 表示不限制（默认值），生产环境务必显式设非零
-
MAX_USER_CONNECTIONS是并发连接上限，超限后新连接直接报ERROR 1203 (42000): User xxx has already more than 'max_user_connections' active connections，应用需捕获并重试 - 改完必须
FLUSH PRIVILEGES？不需要——ALTER USER是即时生效的 DDL，无需刷新
容易被忽略的兼容性坑
BI 工具往往用较老驱动（如 MySQL Connector/J 5.1.x 或 8.0.23 以前），它们可能：
- 忽略
MAX_EXECUTION_TIMEhint，或解析失败后静默丢弃 - 在连接字符串里传
sessionVariables=max_execution_time=30000，但 MySQL 8.0.23+ 才支持该参数名，旧版要用sessionVariables=wait_timeout=30类变通方式 - 把
MAX_USER_CONNECTIONS超限错误识别成网络中断，触发无意义重连风暴——建议在 BI 日志里搜1203错误码确认是否真被限流
最麻烦的是：所有这些限制都不管子查询、CTE 或临时表创建过程中的内存分配，sort_buffer_size 和 tmp_table_size 仍是会话级可 SET 的，BI 用户只要能执行 SET SESSION sort_buffer_size = 268435456，就能单条查询吃掉 256MB 内存——除非你禁掉 SET 权限，但这会让多数 BI 工具启动失败。
