mysql行级权限需通过sql security definer视图封装过滤逻辑并仅授视图权限，禁用底层表访问；推荐用sql security definer存储函数替代substring_index解析user()以提升用户映射可靠性。
MySQL 本身不提供“角色继承”“权限模板”或“动态上下文行过滤”这类企业级权限模型，所谓细粒度分级授权，本质是库/表/列三级静态授权 + 视图封装 + 外部映射逻辑的组合工程。直接用 GRANT 做到“按部门查订单”“按区域看报表”，必须靠视图和函数兜底，否则就是裸权限，一查就穿。
用角色（ROLE）简化批量授权，但别指望它解决行级问题
MySQL 8.0+ 的 ROLE 是权限容器，不是执行上下文。它能帮你把“财务组所有用户都该有 sales_db.reports 的 SELECT 权限”这件事从重复 GRANT 中解耦出来，但无法让张三只看到华东数据、李四只看到华北数据。
- 先建角色：
CREATE ROLE 'finance_reader'@'%'; - 授表级权限：
GRANT SELECT ON sales_db.reports TO 'finance_reader'@'%'; - 再把人加进来：
GRANT 'finance_reader'@'%' TO 'zhangsan'@'%'; - 注意：角色默认不激活，应用连接后需显式执行
SET ROLE 'finance_reader'@'%';，否则权限不生效 - 角色不能替代视图——哪怕你给角色授了
SELECT权限，只要没禁掉基表访问，用户仍可绕过视图直查整张orders
列级权限必须叠加在表级权限之上，否则无效
MySQL 的列级授权不是独立开关，而是“增强型白名单”。如果你只执行 GRANT SELECT (id, name) ON mydb.users TO 'reporter'@'%';，但没先给 'reporter'@'%' 授过 SELECT 表权限，这条命令不会报错，但实际查任何字段都会被拒绝。
- 正确顺序：先
GRANT SELECT ON mydb.users TO 'reporter'@'%';，再GRANT SELECT (email, phone) ON mydb.users TO 'reporter'@'%'; - 列级
UPDATE同理：若 SQL 中更新了name和status，而你只授了UPDATE (name)，就会触发ERROR 1142 (42000): UPDATE command denied to user ... for column 'status' -
DELETE和ALTER不支持列级控制，它们天然作用于整行 - 列名必须精确匹配，大小写敏感（取决于
lower_case_table_names设置），不能用通配符或正则
行级隔离只能靠 SQL SECURITY DEFINER 视图 + 存储函数，别碰 USER()
硬编码 SUBSTRING_INDEX(USER(), '@', 1) 在生产环境大概率失效。连接池会让所有请求显示为 'app_pool'@'localhost'；业务用户 ID 是整型，而解析出的字符串参与比较会触发 MySQL 8.0+ 的严格类型检查，直接中断查询。
- 建映射表：
CREATE TABLE auth_mapping (conn_user VARCHAR(100) PRIMARY KEY, business_user_id INT NOT NULL); - 写函数（必须
SQL SECURITY DEFINER）：CREATE FUNCTION get_current_user_id() RETURNS INT READS SQL DATA DETERMINISTIC SQL SECURITY DEFINER BEGIN RETURN (SELECT business_user_id FROM auth_mapping WHERE conn_user = USER()); END; - 建视图（同样必须
SQL SECURITY DEFINER）：CREATE DEFINER='admin'@'localhost' SQL SECURITY DEFINER VIEW user_orders AS SELECT * FROM orders WHERE user_id = get_current_user_id(); - 最关键的一步：立刻收回基表权限 ——
REVOKE SELECT ON mydb.orders FROM 'reporter'@'%';，只授视图：GRANT SELECT ON mydb.user_orders TO 'reporter'@'%';
权限闭环验证比授权更重要
很多团队卡在“为什么视图不生效”，其实问题不出在视图定义，而出在权限没收干净。MySQL 不会阻止用户用 UNION 或子查询穿透视图，只要底层表权限还在，整套机制就等于没设防。
- 每次改完权限，必须手动验证：
SHOW GRANTS FOR 'reporter'@'%';—— 输出里不能出现任何基表名（如orders、users） - 用目标用户账号连上去，执行
SELECT * FROM orders LIMIT 1;，确认返回ERROR 1142 - 如果视图涉及多表
JOIN（比如关联users和orders），DEFINER账号必须对每张基表都有对应权限，缺一张，视图就查不了 - 函数内部的
SELECT也受权限约束——auth_mapping表必须由DEFINER可读，且不能被调用者直查
最常被忽略的一点：权限变更不是实时广播的。如果用户已建立长连接，新授的权限不会自动生效，得等连接断开重连，或手动执行 FLUSH PRIVILEGES;（仅当直接修改系统表时才强制需要，常规 GRANT 不需要）。但更稳妥的做法，是让应用层使用短连接，或在权限调整后滚动重启连接池。
