error 1356主因是sql security invoker模式下当前用户缺少视图所依赖基表的select权限，或definer账号失效、迁移后未同步更新；需逐表授权或重建视图并显式指定sql security invoker。
为什么视图查不了，却提示 ERROR 1356？
这通常不是表不存在或字段写错，而是 SQL SECURITY INVOKER 模式下，当前用户缺少视图所依赖基表的 SELECT 权限。MySQL 在执行时直接用调用者身份去检查每张底层表——哪怕你只对视图授了权限，只要其中一张基表没给权限，就报这个错。
常见诱因包括：
- 迁移库后，
DEFINER账号被删（比如从'dev'@'%'改成'dev'@'192.168.1.%'），但没同步更新视图定义者 - 用
mysqldump导出再导入，视图自动带上了原环境的DEFINER，而新环境没有该账号 - 开发误设
SQL SECURITY INVOKER，又没给调用者逐表授权
怎么把现有视图改成 INVOKER 模式？
不能直接 ALTER VIEW ... SQL SECURITY INVOKER —— MySQL 不支持修改已有视图的安全模型。必须重建：
- 先用
SHOW CREATE VIEW view_name拿到原始定义语句 - 把语句里的
DEFINER = 'xxx'@'yyy'整段删掉（或保留但无实质影响） - 在
CREATE VIEW后显式加上SQL SECURITY INVOKER - 执行重建语句（需有
CREATE VIEW权限）
示例：
CREATE OR REPLACE SQL SECURITY INVOKER VIEW user_summary AS SELECT id, name, email FROM users WHERE status = 'active';
注意：CREATE OR REPLACE 不会保留原视图的注释或字符集设置，如有特殊要求，得手工补全。
切到 INVOKER 后，用户要授哪些权限？
不是“给视图授权”就完事了。INVOKER 模式下，MySQL 会按用户身份去查所有基表，所以必须确保该用户对视图中出现的每张表都有对应操作权限：
- 如果视图只读，就对每张基表单独授
GRANT SELECT ON db.table TO 'user'@'%' - 如果视图含
INSERT或UPDATE（不推荐），还得授对应 DML 权限 - 权限必须精确到表级，
GRANT SELECT ON db.*不足以让 INVOKER 模式通过——MySQL 会逐表校验 - 若视图用了函数（如
NOW()、自定义函数），还要确认该用户有EXECUTE权限（对函数）
INVOKER 模式下最容易忽略的坑
看似简单，实操中几个点常被跳过：
-
CURRENT_USER()和USER()行为不同：前者返回认证用户（'alice'@'10.0.1.%'），后者带连接 host；在视图 WHERE 条件里用错会导致过滤失效 - 视图嵌套时，INVOKER 权限是链式检查的——外层视图用 INVOKER，内层视图也得是 INVOKER，否则权限链断裂
- MySQL 8.0+ 默认开启
sql_mode=STRICT_TRANS_TABLES，如果视图中字段类型隐式转换失败（比如字符串和数字比），整个查询直接报错，不会静默跳过 - 主从复制中，如果从库用户权限配置不一致，INVOKER 视图在从库上可能查不到数据，但不报错——只返回空结果集
真正要用好 INVOKER，核心不是改那行 SQL SECURITY，而是把权限落到每张基表、每个调用场景里去验证。否则，它只是把错误从“定义时报”延后到了“查询时报”。
