MySQL原生不支持行级权限语法，必须用SQL SECURITY DEFINER视图+存储函数封装用户映射逻辑（如查auth_mapping表）并严格收回基表权限，否则易因USER()不可靠、连接池混淆或类型转换失败导致空结果或越权访问。
MySQL 原生不支持 GRANT SELECT ON table WHERE user_id = CURRENT_USER() 这类语法，行级权限必须靠视图 + 权限隔离组合实现，漏掉任一环节都会失效。
为什么不能直接用 USER() 或 CURRENT_USER() 做视图过滤
常见错误现象：用户查 user_orders 视图返回空结果，或所有用户看到同一组数据。
-
USER()返回的是连接凭据名（如'app_pool@10.20.5.10'），不是业务系统里的用户 ID；JWT、Session 中的sub或user_id完全不在数据库连接上下文中 - 连接池场景下，所有请求都显示为同一个
USER()（如'webapp'@'localhost'），彻底失去区分能力 - 用户名含
@字符时（如'alice@prod'@'192.168.1.1'），SUBSTRING_INDEX(USER(), '@', 1)会截断出错，得到'alice'而非'alice@prod' - 若
user_id是整型字段，而解析出的字符串参与比较，MySQL 8.0+ 的STRICT_TRANS_TABLES会触发类型转换失败，整个查询中断
用存储函数封装用户映射才是可靠做法
把“谁在查”从字符串解析升级为可维护、可测试的逻辑层，避免硬编码解析。
- 先建映射表：
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 补充外部认证源
权限配置必须闭环，只授视图不收原表等于没设防
哪怕视图定义再严，只要用户还能直连 orders 表，整套机制就形同虚设。
- 立刻收回底层表权限：
REVOKE SELECT ON mydb.orders FROM 'alice'@'%'; - 只授予视图权限：
GRANT SELECT ON mydb.user_orders TO 'alice'@'%'; - 验证是否生效：
SHOW GRANTS FOR 'alice'@'%';—— 输出里不能出现orders字样 - 如果视图涉及多张表（如 JOIN
users和orders），DEFINER账户必须对每张基表都有对应权限，缺一张就会报ERROR 1449
MySQL 8.0.22+ 的原生行策略（RLS）仍不推荐生产直接启用
虽然支持 CREATE ROW POLICY，但落地成本高、调试难，且无法解决核心上下文缺失问题。
- 需禁用
STRICT_TRANS_TABLES，并授予SYSTEM_VARIABLES_ADMIN和ROLE_ADMIN权限，权限模型更复杂 - 策略函数内只能访问
USER()、CURRENT_USER()等有限 session 变量，依然拿不到 JWT 中的user_id - 拒绝报错统一为
Access denied，和账号密码错误一样，无法定位是哪条策略拦截的 - 低版本（包括全部 5.7 和 8.0.21-）根本不识别
CREATE ROW POLICY，执行即报ERROR 1064
真正稳定的行级控制，始终依赖应用层拼 WHERE user_id = ? 或由应用选择对应视图——而这些逻辑，终究得由代码决定，不是靠数据库自动推导。
