MySQL原生不支持行级权限（RLS），因其权限系统仅支持库表和列粒度，无WHERE条件级授权语法；8.0.22+虽引入CREATE ROW POLICY但启用门槛高，且视图模拟易因权限、上下文、连接池等问题失效。
MySQL原生不支持行级权限（RLS）
因为权限系统设计上只到表（database.table）和列（database.table(column)）粒度，没有WHERE条件级的授权语法。你写不出GRANT SELECT ON orders WHERE user_id = 123这种语句——MySQL解析器直接报错ERROR 1064 (42000)。
8.0.22+ 虽有 CREATE ROW POLICY，但启用门槛高
即使你用的是 MySQL 8.0.22 或更高版本，CREATE ROW POLICY也远非开箱即用：
-
sql_mode里必须禁用STRICT_TRANS_TABLES，否则策略函数返回NULL会被截断成0，导致过滤失效 - 执行用户得有
SYSTEM_VARIABLES_ADMIN和ROLE_ADMIN权限，普通DBA账号通常没这个权限 - 策略函数里不能用
NOW()、RAND()等非确定性函数，否则优化器可能跳过策略检查 - 主从复制场景下，策略函数若依赖
USER()，从库回放时USER()是空字符串，策略直接失效
视图模拟行权限时最常踩的三个坑
绝大多数人靠VIEW + SQL SECURITY DEFINER来“模拟”行级控制，但实际落地时容易翻车：
- 忘了
REVOKE SELECT ON orders FROM 'user'@'%'——只要底层表权限还在，视图就是摆设 - 在视图
WHERE里用SUBSTRING_INDEX(USER(), '@', 1)，结果应用走连接池时所有请求都显示为app_pool@localhost，所有人看到同一组数据 - 视图定义里用了
CURRENT_USER()但没配SQL SECURITY DEFINER，导致过滤逻辑以调用者身份执行，而普通用户根本没权限查映射表
真正卡住权限边界的不是语法，是执行上下文
MySQL 的权限检查发生在语句解析阶段，不介入查询执行过程。这意味着：
- 视图里的
WHERE user_id = ?写法无效——视图不接受参数，?会被当成字面量0 - 存储过程或函数无法替代视图做透明拦截，因为 ORM 和原始 SQL 都绕过它们直查表
- 哪怕你用
WITH CHECK OPTION建了可更新视图，用户仍可通过INSERT INTO orders SELECT ... FROM user_orders绕过过滤
所以所谓“行级权限”，本质是把访问入口收窄到一个受控视图，并确保没人能绕过去——这要求你同时管住账号、连接方式、应用SQL写法和运维操作习惯，而不是指望一条GRANT语句自动生效。
