MySQL原生不支持行级权限语法，必须用视图+SQL SECURITY DEFINER模拟；直接用USER()做行过滤不可靠，因其返回连接凭据名而非业务用户ID，易导致空结果或数据混淆，正确做法是用SQL SECURITY DEFINER存储函数封装用户映射逻辑并配合映射表。
MySQL 原生不支持行级权限语法（如 GRANT SELECT ON table WHERE ...），必须用视图 + SQL SECURITY DEFINER 模拟，且 USER() 直接用于 WHERE 条件极不可靠——它返回的是连接凭据名，不是业务用户 ID。
为什么不能直接用 USER() 做行过滤
常见错误现象：视图查出来全是空结果，或所有用户看到同一组数据。
-
USER()返回格式是'username@host'，比如'app_pool@10.0.1.5'，而业务系统里真正的用户标识在 JWT 或 session 中，根本不在数据库连接名里 - 连接池场景下，所有请求都显示为同一个
USER()（如'webapp'@'localhost'），彻底失去区分能力 - 用户名含
@字符时（如'alice@prod'@'192.168.1.1'），SUBSTRING_INDEX(USER(), '@', 1)会截断出错，得到'alice'而非预期的'alice@prod' - MySQL 8.0+ 默认开启
STRICT_TRANS_TABLES，若user_id是整型字段，而USER()解析出字符串去比较，会触发类型转换失败报错，整个查询中断
正确做法：用存储函数封装用户映射逻辑
把“谁在查”这个判断从字符串解析升级为可维护、可测试的逻辑层。
- 先建一张映射表：
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;
- 视图中调用它：
CREATE DEFINER = 'admin'@'localhost' SQL SECURITY DEFINER VIEW user_orders AS SELECT * FROM orders WHERE user_id = get_current_user_id();
- 函数内部可扩展逻辑：比如 fallback 到
CURRENT_USER()、查缓存表、甚至调用外部服务（通过 UDF 或应用层兜底）
权限配置必须闭环，漏一环就失效
只建视图不收权限，等于没设防。
- 立刻回收底层表权限：
REVOKE SELECT ON mydb.orders FROM 'alice'@'%'; - 只授视图权限：
GRANT SELECT ON mydb.user_orders TO 'alice'@'%'; - 检查是否干净：
SHOW GRANTS FOR 'alice'@'%';—— 输出里绝对不能出现orders或mydb.* - 定义者账号（如
'admin'@'localhost'）必须对orders和auth_mapping都有SELECT权限，缺一个视图就执行失败
容易被忽略的性能与行为细节
这种方案不是“开了就完事”，真实压测中常暴露问题。
- 视图用的是
MERGE算法（默认），但一旦函数出现在WHERE，MySQL 就无法下推条件，可能全表扫描orders再过滤，务必在user_id上建索引 - 函数
get_current_user_id()每次查询都会执行一次，如果映射表没加索引或数据量大，会成为瓶颈；建议加INDEX(conn_user) - 视图不支持参数，想让客服看本组订单、管理员看全部，就得建多个视图（
staff_orders、admin_orders）并配不同函数或条件分支，别指望一个视图通吃 -
SQL SECURITY DEFINER是关键开关，漏写或写成INVOKER，函数就以调用者身份运行，普通用户查auth_mapping会直接报错ERROR 1142
真正落地时，最复杂的不是写 SQL，而是把连接凭据、业务用户、数据库权限三者对齐。硬编码 USER() 解析是临时方案，函数 + 映射表才是可持续路径。一旦应用改用代理或容器化部署，连接名就彻底失控，提前抽象这层映射，后面省掉大量救火时间。
