必须用 SQL SECURITY DEFINER + 显式剥离基表权限，否则 GRANT SELECT ON view 仍报错；因 MySQL 运行时校验调用者对所有依赖对象的权限，而非仅视图本身。
直接给 BI 工具账号授 SELECT 权限到基表或库，等于把整张底裤掀开——它能查 information_schema、能 SHOW CREATE VIEW 看出字段来源、甚至可能因视图逻辑变更而突然报错。真要只读特定视图，必须用 SQL SECURITY DEFINER + 显式权限剥离。
为什么 GRANT SELECT ON view_name 之后还报 “SELECT command denied”
这不是权限没给，而是 MySQL 在运行时校验的是“调用者对所有依赖对象的权限”，不是视图本身。常见原因包括：
- 视图定义里用了用户无权访问的基表（比如
sales和customers），哪怕你只GRANT SELECT ON bi_db.v_sales_summary，只要用户没被显式授权这些基表，就仍会报错 - 视图是
SQL SECURITY INVOKER（默认值之一），导致执行时按 BI 账号身份去查底表，而非按视图创建者身份 - 用户残留了旧的库级权限（如
GRANT SELECT ON bi_db.*），MySQL 优先走这条路径，绕过视图授权逻辑 - 视图嵌套了另一层视图，而上游视图没单独授过
SELECT权限
必须显式指定 SQL SECURITY DEFINER 创建视图
否则权限隔离形同虚设。DEFINER 账号（比如 'admin'@'localhost'）必须有源表 SELECT 权限，BI 账号则完全不需要碰基表。建视图时务必写全：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
CREATE DEFINER='admin'@'localhost' SQL SECURITY DEFINER VIEW bi_db.v_sales_summary AS SELECT date, region, SUM(amount) AS total_revenue FROM sales JOIN regions USING(region_id) WHERE status = 'completed' GROUP BY date, region;
漏掉 DEFINER 或写成 INVOKER，等于白干。
三步清空权限再精准授予（关键操作链）
MySQL 不支持“原子化只开视图权限”，必须手动剥离基表访问能力：
- 先用
SHOW GRANTS FOR 'bi_reader'@'10.20.%'查当前所有权限，重点看有没有ON bi_db.*或具体表名的SELECT - 逐个回收：执行
REVOKE SELECT ON bi_db.sales FROM 'bi_reader'@'10.20.%'、REVOKE SELECT ON bi_db.regions FROM 'bi_reader'@'10.20.%'；不要用REVOKE ALL PRIVILEGES ON bi_db.*，它不清理视图相关权限 - 确认基表权限已空后，再执行
GRANT SELECT ON bi_db.v_sales_summary TO 'bi_reader'@'10.20.%' - 最后检查是否还有隐式继承的全局权限：
REVOKE ALL PRIVILEGES ON *.* FROM 'bi_reader'@'10.20.%'，只留USAGE
容易被忽略的细节：ALGORITHM 和 SHOW CREATE VIEW
MySQL 8.0 默认启用视图合并（view merging），查询 SELECT * FROM v_sales_summary 可能被重写成直查 sales 和 regions 表——此时若 BI 账号没基表权限，照样报错。解决方法：
- 建视图时加
ALGORITHM = TEMPTABLE强制物化中间结果（性能略降，但权限可控） - 或者确保
SQL SECURITY DEFINER+ DEFINER 账号权限足够，靠 DEFINER 身份兜底 -
SHOW CREATE VIEW权限默认随SELECT一起授予，BI 用户能直接看到视图定义里的字段名和表名，别指望靠视图“隐藏敏感列”
