MySQL行级权限需通过DEFINER+SQL SECURITY DEFINER视图封装过滤逻辑并仅授予视图权限，禁用底层表访问；推荐用SQL SECURITY DEFINER存储函数替代SUBSTRING_INDEX解析USER()，以提升用户映射可靠性。
MySQL 行级权限靠视图 + 用户权限组合实现，原生不支持 WHERE 条件级授权
MySQL 本身没有 GRANT SELECT ON table WHERE user_id = CURRENT_USER() 这种语法。所谓“行级权限”，本质是用视图封装过滤逻辑，再对视图单独授予权限，把访问控制前移到查询层。
怎么用视图模拟行级权限：必须用 DEFINER + SQL SECURITY DEFINER
如果只建普通视图并授予权限，用户仍可能绕过——比如直接查底层表，或通过 UNION、子查询等方式穿透视图。关键在定义视图时绑定执行上下文：
CREATE ALGORITHM=MERGE DEFINER='admin'@'localhost' SQL SECURITY DEFINER VIEW user_orders AS SELECT * FROM orders WHERE user_id = SUBSTRING_INDEX(USER(), '@', 1);-
DEFINER指定谁有权限读原始表（通常是高权限账号） -
SQL SECURITY DEFINER强制视图以DEFINER身份执行，用户无法篡改 WHERE 条件中的SUBSTRING_INDEX(USER(), '@', 1) - 避免用
SQL SECURITY INVOKER—— 它会让 WHERE 中的函数以调用者身份运行，而普通用户通常没权限查information_schema或执行某些函数
权限授予必须只给视图，且禁用底层表访问
哪怕视图定义得再严，只要用户还能直接 SELECT 原表，整套机制就失效：
- 先回收所有对原表的权限：
REVOKE SELECT ON mydb.orders FROM 'alice'@'%'; - 只授予视图权限：
GRANT SELECT ON mydb.user_orders TO 'alice'@'%'; - 检查是否残留权限：
SHOW GRANTS FOR 'alice'@'%';—— 输出里不能出现orders字样 - 注意：MySQL 8.0+ 的角色（
ROLE）能简化批量授权，但角色本身不改变权限粒度，仍需配合视图使用
容易踩的坑：SUBSTRING_INDEX(USER(), '@', 1) 不可靠，推荐用存储函数封装用户映射
USER() 返回 username@host，但实际业务中用户标识往往来自应用层（如 JWT 中的 sub），或需要映射到内部 ID。硬编码字符串解析极易出错：
- 用户连接名含
@（如user@prod@192.168.1.1）会导致SUBSTRING_INDEX截断错误 - 应用用代理连接池时，所有请求可能都显示为
app_pool@localhost，失去区分度 - 更稳的做法是建一个存储函数，比如
get_current_user_id()，内部查一张映射表（auth_mapping），把USER()或CURRENT_USER()映射到业务用户 ID - 视图里写成
WHERE user_id = get_current_user_id()，函数需用SQL SECURITY DEFINER创建，且只对DEFINER开放查映射表权限
真正难的不是写视图，而是让每个环节都卡死——从连接方式、用户命名规范，到函数权限链和映射表维护，漏一环就可能越权。
