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语句。
