SQL SECURITY DEFINER 会暴露表结构，因其以定义者权限执行且 SHOW CREATE PROCEDURE 可见明文语句；应改用 SQL SECURITY INVOKER 或视图封装。
直接给存储过程授 EXECUTE 权限本身不会暴露表结构，但如果你用的是默认的 SQL SECURITY DEFINER，且 DEFINER 是高权限账号（比如 'root'@'localhost'），那调用者就能绕过自己原本没有的 SELECT、INSERT 等表级权限——表结构虽不直接可见，但通过 SHOW CREATE PROCEDURE 或反复试探性 CALL + 报错信息，仍可能被逆向推测出来。
为什么 SQL SECURITY DEFINER 会“悄悄”暴露表信息
当存储过程声明为 SQL SECURITY DEFINER（这也是 MySQL 默认行为），内部所有 SQL 都以 DEFINER 身份执行，完全无视调用者的实际权限。这意味着：
- 即使用户对底层表
users连SELECT权限都没有，只要能CALL sp_get_user_by_id(123)，就可能拿到数据——而数据本身就会泄露字段名、类型、甚至枚举值范围 -
SHOW CREATE PROCEDURE db.sp_x对有EXECUTE权限的用户默认是可执行的，返回的定义里明文写着SELECT id, name FROM users，表名、字段名全暴露 - 如果过程里用了动态 SQL（
PREPARE+EXECUTE），且错误未捕获，报错信息如Table 'db.nonexistent' doesn't exist也会反推表结构
GRANT EXECUTE ON PROCEDURE 的真实生效条件
MySQL 8.0.16+ 才真正支持按单个过程授 EXECUTE，但必须满足两个前提，缺一不可：
- 先执行
GRANT USAGE ON `db`.* TO 'u'@'%'——跳过这步，后续GRANT EXECUTE ON PROCEDURE db.sp_x会静默失败（无报错，但权限不生效） - 用户必须对过程所在数据库有
EXECUTE数据库级权限，或显式授予该过程；仅靠USAGE不够，也不需要SELECT或ALL PRIVILEGES -
REVOKE EXECUTE ON PROCEDURE db.sp_x FROM 'u'@'%'在 MySQL 中无效：只要用户还有db.*的EXECUTE，就能调所有该库下的过程
想真正隔离表结构？必须改 SQL SECURITY
只靠授权无法阻止表结构泄漏，关键在过程创建时的权限上下文。要让调用者只能“用功能”，不能“看实现”，必须显式指定：
- 创建时加
SQL SECURITY INVOKER：这样过程内每条 SQL 都检查调用者权限，没SELECT就查不了表，自然也拿不到字段名 - 但代价是：你得提前给调用者授对应表的最小必要权限（比如只给
SELECT(id,name)，不给email），否则过程直接报错 - 验证当前设置：
SELECT ROUTINE_NAME, SQL_SECURITY FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA='db' AND ROUTINE_NAME='sp_x' - 重建过程才能改
SQL SECURITY，ALTER PROCEDURE 不支持修改该属性
替代方案：用视图 + 权限封装代替裸过程
如果业务逻辑简单（比如固定字段查询），比写存储过程更安全的做法是：
- 建一个视图
CREATE VIEW v_user_summary AS SELECT id, name, status FROM users - 只授用户对这个视图的
SELECT权限：GRANT SELECT ON db.v_user_summary TO 'u'@'%' - 视图定义对用户不可见（除非有
SHOW VIEW权限），且无法通过CALL推测原表结构 - 若需参数化，可用带参数的表值函数（MySQL 8.0.29+ 支持）或应用层拼接，避免动态 SQL 泄露
最常被忽略的一点：SQL SECURITY 是开关，GRANT EXECUTE 是门禁卡——卡给了，但门锁没换，还是防不住从门缝里偷看里面摆设的人。
