EXECUTE权限专用于调用存储过程，不替代SELECT/INSERT等表级权限；撤销表DML权限、仅授EXECUTE、设DEFINER执行是安全关键；误留表权限或动态拼接SQL将使防护失效。
EXECUTE 权限即可调用，无需授予 SELECT/INSERT/UPDATE/DELETE 等底层表权限——这是存储过程在安全性上真正起效的核心机制。
为什么直接授表权限会放大风险？
应用账号若拥有对 users 表的 SELECT 权限，就可能被构造恶意查询绕过业务逻辑（比如 SELECT * FROM users WHERE status = 'active' 变成 SELECT password_hash FROM users）；更危险的是，一旦 SQL 注入漏洞存在，攻击者可直接拼接任意语句。而存储过程把数据访问路径收束到预定义接口，输入参数被严格绑定类型和方向（IN/OUT/INOUT），数据库层面对参数值不做字符串拼接，天然规避大多数注入场景。
如何配置才能真正发挥安全优势？
关键不在“写不写存储过程”，而在“怎么授权”：
- 撤销应用账号对所有业务表的直接 DML 权限：
REVOKE INSERT, UPDATE, DELETE ON mydb.orders FROM 'app_user'@'%'; - 仅授予其对特定存储过程的
EXECUTE权限：GRANT EXECUTE ON PROCEDURE mydb.create_order TO 'app_user'@'%'; - 确保存储过程内部使用
DEFINER身份（如DEFINER='dbadmin'@'localhost'）执行，而非调用者身份——这样过程内操作由高权限账户代理完成，调用者完全无权越界
哪些常见误操作会让安全优势归零？
写了存储过程但没改权限策略，等于白写：
- 仍给应用账号
SELECT权限到核心表，哪怕它只调用get_user_profile过程，也能绕过直接查表 - 过程里用
CONCAT拼接用户输入构建动态 SQL（如SET @sql = CONCAT('SELECT * FROM ', user_table);），相当于自己打开注入后门 - 用
SQL SECURITY INVOKER定义过程，导致执行时以调用者权限检查——此时若调用者没表权限，过程直接失败；若已有表权限，过程反而成了多余外壳
真正起作用的安全边界，是权限模型 + 执行上下文 + 输入处理三者咬合的结果。单独依赖某一项，都容易在上线后被绕过。
