GRANT SELECT无法阻止BI全表扫描，因权限系统只控“能否查”不控“怎么查”；MAX_QUERIES_PER_HOUR对BI无效，因其按连接计数且不限单查询扫描行数；需组合连接限制、元数据隔离与查询治理。
单纯靠 GRANT SELECT 无法阻止 BI 工具发起全表扫描——它连得上、查得到、扫得完，权限系统根本不管“怎么查”，只管“能不能查”。真正有效的限制必须组合连接控制、元数据隔离和查询治理。
为什么 MAX_QUERIES_PER_HOUR 对 BI 全表扫描完全无效
MySQL 的 MAX_QUERIES_PER_HOUR 是按「单个连接」计数的，而 BI 工具（如 Tableau、Power BI）普遍使用连接池，一次仪表板加载可能复用多个连接、并发发 5–20 个查询。每个连接各自计数，总频次轻松绕过限制。
更关键的是：这个参数不限制单条 SQL 扫描多少行，SELECT * FROM huge_table 只算 1 次查询，哪怕它扫描 5000 万行、耗时 47 秒，也完全合法。
所以：
- 不要指望它防全表扫描
- 不要把它当资源防火墙用
- 它只适合防低频脚本误跑，不适合控 BI 流量
用 max_user_connections + 连接池超时双杀并发扫描
BI 工具真正造成压力的不是单条慢查询，而是多张看板同时拉取、每张背后是 3–8 个并发查询，瞬间打满连接数、拖垮整个库。
实操要点：
CREATE USER 'bi_reader'@'192.168.10.%' IDENTIFIED BY 'strong_pass';-
GRANT SELECT ON analytics.* TO 'bi_reader'@'192.168.10.%' WITH MAX_USER_CONNECTIONS 3;（设为 3–5，够撑 1–2 张常规看板） - 在 BI 工具端同步配置连接池最大连接数 ≤ 3，空闲超时 ≤ 30s（避免连接长期占着不放）
- 确认 MySQL 版本 ≥ 5.7（
MAX_USER_CONNECTIONS在 5.6 中仅对 SUPER 用户生效）
效果：一旦并发查询超过上限，新请求直接报错 Too many connections for user，而不是排队等待或扫表卡死。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
禁用 INFORMATION_SCHEMA + 视图封装，切断“自动扫表”路径
很多 BI 工具默认行为就是先 SELECT * FROM huge_table LIMIT 100 来猜字段类型、再决定怎么渲染——这本质就是隐式全表扫描触发器。
阻断方法：
- 显式回收元数据访问：
REVOKE SELECT ON information_schema.* FROM 'bi_reader'@'192.168.10.%';（MySQL 8.0+ 默认已禁，但 5.7 需手动） - 不给
SHOW CREATE TABLE权限（加REVOKE SHOW VIEW ON *.* FROM 'bi_reader'@'192.168.10.%';） - 所有对外暴露的表，必须走
SQL SECURITY DEFINER视图，并内置过滤条件：CREATE DEFINER='dba'@'localhost' VIEW vw_orders_2024 AS SELECT id, order_no, amount FROM orders WHERE created_at >= '2024-01-01'; - BI 账号只授视图
SELECT权限，不授底层表权限
这样工具连 DESCRIBE orders 都失败，只能老老实实查你给的视图——而视图里早把时间范围、租户 ID 等过滤条件写死了。
靠慢日志 + pt-query-digest 主动揪出高频扫表 SQL
防御性配置只是底线，真正要治根，得定位哪些报表在反复触发全表扫描。
操作步骤：
- 临时开慢查：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; - 等 1–2 小时 BI 高峰期后，用：
pt-query-digest --filter '$event->{fingerprint} =~ m/^SELECT\s+\*\s+FROM/' /var/lib/mysql/slow.log - 重点关注输出里的：
Count（调用次数）Rows_examined_avg（平均扫描行数）Query_time_sum（总耗时） - 把
Count > 5 AND Rows_examined_avg > 100000的查询拎出来，直接找 BI 团队改写：加 WHERE、建索引、换 LIMIT、拆大宽表
最常被忽略的一点：BI 工具发的 SQL 经常带动态日期参数（WHERE dt = '2024-11-01'），但指纹归类后你会发现，同一类扫表逻辑每天都在重复发生——这不是偶发问题，是设计缺陷。
