MySQL中EXECUTE权限仅适用于调用存储过程、函数等可执行对象，不等同于SQL执行权限；需显式授予SELECT、INSERT等具体权限，且应遵循最小权限原则，避免ALL PRIVILEGES。
GRANT 语句必须指定具体权限和对象
MySQL 不支持笼统的“执行权限”概念，EXECUTE 权限只适用于存储过程、函数、触发器等可执行数据库对象，不是对 SQL 语句（如 SELECT、INSERT）的统称。误以为 GRANT EXECUTE ON *.* 能让用户运行任意 SQL，会导致权限不足或越权错误。
常见错误现象：ERROR 1142 (42000): SELECT command denied to user，本质是没给 SELECT 权限，而非缺少 EXECUTE。
-
EXECUTE权限仅用于调用已存在的存储过程或函数：例如GRANT EXECUTE ON PROCEDURE mydb.calc_total TO 'user1'@'localhost'; - 想允许增删改查，必须显式授予
SELECT、INSERT、UPDATE、DELETE等权限 - 权限对象可以是数据库级（
mydb.*）、表级（mydb.users）或列级（需在GRANT中列出列名）
CREATE ROUTINE 和 ALTER ROUTINE 是创建/修改存储过程的前提
即使给了 EXECUTE 权限，用户也无法自己创建存储过程——那需要额外的 CREATE ROUTINE 权限；修改已有过程则需要 ALTER ROUTINE。这两个权限常被忽略，导致 CREATE PROCEDURE 报错 ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s)（MySQL 5.7+ 默认禁用 SUPER，改用细粒度权限）。
- 授予创建权限：
GRANT CREATE ROUTINE ON mydb.* TO 'dev'@'%'; - 授予修改权限：
GRANT ALTER ROUTINE ON mydb.* TO 'dev'@'%'; - 这两个权限本身不赋予执行能力，仍需单独
GRANT EXECUTE
FLUSH PRIVILEGES 并非总是必要
使用 GRANT 或 REVOKE 后，权限会立即生效（MySQL 5.7.6+ 默认行为），无需手动执行 FLUSH PRIVILEGES。只有在直接操作 mysql 系统库表（如 INSERT INTO mysql.user）后才需要刷新。
滥用 FLUSH PRIVILEGES 不但多余，还可能掩盖真实问题：比如权限未生效其实是由于主机名匹配失败（'user'@'192.168.1.%' vs 'user'@'localhost'），而不是缓存没刷新。
- 确认用户连接来源：
SELECT USER(), CURRENT_USER();—— 前者是客户端声明的身份，后者才是 MySQL 实际匹配到的账号 - 检查账号是否存在且主机名精确匹配：
SELECT Host, User FROM mysql.user WHERE User = 'xxx'; - 修改权限后，新连接立即生效；已有连接的权限不变，需重连
最小权限原则下避免 ALL PRIVILEGES
GRANT ALL PRIVILEGES ON mydb.* TO 'app'@'10.0.2.%'; 看似方便，实则风险极高：它包含 DROP、CREATE VIEW、TRIGGER 等应用通常不需要的能力，一旦应用漏洞被利用，攻击面大幅扩大。
生产环境应严格按需授权。例如 Web 应用通常只需：
-
SELECT,INSERT,UPDATE,DELETE（禁止DROP和CREATE TABLE） - 如果调用存储过程，再加
EXECUTE，不加CREATE ROUTINE - 明确限制主机范围，避免用
'%'匹配所有地址
权限颗粒度越细，出问题时定位和回滚越快。别省那几行 GRANT 语句。
