MySQL社区版无原生行级权限，最常用方案是SQL SECURITY DEFINER视图：定义者账户需有底层表权限，用户仅授视图权限，并须收回其对基表的直接访问权。
MySQL 视图本身不能直接实现行级权限控制
视图只是查询的封装，CREATE VIEW 不会自动过滤用户能看到哪些行；即使你基于 WHERE user_id = CURRENT_USER() 写了视图，普通用户仍可能绕过它（比如直接查底层表，或用子查询暴露数据）。MySQL 原生直到 8.0.22 才支持行级安全策略（RLS），且仅限企业版；社区版至今无内置 RLS 支持。
用视图 + SQL SECURITY DEFINER 模拟行级权限
这是社区版最常用、也最可控的模拟方案：通过定义视图时指定执行上下文为特定高权限账户，让视图内部的 WHERE 条件生效，且用户无法绕过。
- 必须显式声明
SQL SECURITY DEFINER，否则默认是INVOKER，条件就按调用者权限执行，起不到过滤作用 - 定义者账户（如
'view_admin'@'localhost'）需有底层表的SELECT权限，但普通用户只需对视图有SELECT - 视图中不能依赖不可控变量（如
USER()返回带 host 的完整字符串，匹配易出错；建议用SUBSTRING_INDEX(USER(), '@', 1)提取用户名） - 示例：
CREATE DEFINER = 'view_admin'@'localhost' SQL SECURITY DEFINER VIEW user_orders AS SELECT * FROM orders WHERE owner = SUBSTRING_INDEX(USER(), '@', 1);
权限分配时容易漏掉的关键点
光建好视图远远不够，权限链一环断掉就失效。
- 必须收回用户对原表的直接
SELECT权限：REVOKE SELECT ON db.orders FROM 'alice'@'%';，否则她可以绕开视图直接查 - 视图创建后，要单独授权：
GRANT SELECT ON db.user_orders TO 'alice'@'%'; - 如果视图涉及多张表，定义者账户必须对每张底层表都有对应权限；缺一张，视图就无法创建或执行报错
ERROR 1449 (HY000): The user specified as a definer ('view_admin'@'localhost') does not exist - 注意 MySQL 5.7+ 默认开启
sql_mode=STRICT_TRANS_TABLES，若视图中字段类型隐式转换失败（比如用字符串比数字主键），会导致整个视图查询失败，而不是静默跳过
性能和可维护性隐患
这种方案在数据量大、条件复杂时，容易变成“隐形性能杀手”。
- 视图不存储数据，每次查询都重跑底层
SELECT；如果视图里用了JOIN或子查询，且没在关联字段上建好索引，响应会明显变慢 - 所有用户共用一个视图逻辑，想按角色分不同过滤规则（比如管理员看全部、客服只看本组订单），就得建多个视图，权限管理迅速变臃肿
- MySQL 不支持视图参数化，无法像函数那样传参；想动态切换过滤条件，只能靠应用层拼 SQL 或用预处理语句 + 视图组合，但后者已脱离“纯视图权限”范畴
- 备份恢复时，
mysqldump默认不导出视图的DEFINER，还原后可能变成root@localhost，导致权限行为突变
事情说清了就结束。真要严格行级权限，社区版没捷径——要么接受视图 + DEFINER 的折中，要么把过滤逻辑提到应用层，或者换 PostgreSQL。
