<p>只给 SELECT 权限却还能删数据，根本原因是用户残留 GRANT OPTION 或误配全局权限；需用 SHOW GRANTS 确认、显式 REVOKE GRANT OPTION、避免 . 授权、按需授表级权限，并注意 host 匹配、认证插件、连接池刷新及系统表访问限制。</p>
只给 SELECT 权限却还能删数据？检查 GRANT OPTION 和 USAGE
很多管理员以为执行 GRANT SELECT ON db1.* TO 'u1'@'%'; 就万事大吉，结果发现用户仍能执行 DROP TABLE 或修改表结构。根本原因常是：该用户之前被授予过 GRANT OPTION，或者账号本身有 USAGE 权限但误配了全局权限（如 GRANT ALL ON *.* 后又未 REVOKE 干净）。
实操建议：
- 新建账号后，先用
SHOW GRANTS FOR 'u1'@'%';确认当前实际权限，不要依赖记忆或脚本注释 - 显式回收高危权限：
REVOKE GRANT OPTION ON db1.* FROM 'u1'@'%'; - 避免使用
GRANT USAGE以外的全局权限（*.*），哪怕只是临时调试——它会覆盖库级限制 - 如果用户只需查一张表，直接授
SELECT到表级：GRANT SELECT ON db1.t_user TO 'u1'@'%';，比库级更收敛
连接时提示 Access denied for user？确认 host 匹配和认证插件
即使 GRANT 语句执行成功，用户也可能连不上，典型错误信息是 Access denied for user 'u1'@'10.20.30.40'。这不是权限不足，而是 MySQL 根本没匹配到对应账号记录。
关键点：
-
'u1'@'localhost'和'u1'@'%'是两个完全独立的账号，不能互相替代；远程连接必须明确指定非localhost的 host（如'%'、'192.168.1.%'或具体 IP） - MySQL 8.0+ 默认用
caching_sha2_password插件，而老客户端（如某些 Python MySQLdb）不支持；建号时应显式指定兼容插件：CREATE USER 'u1'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd123'; - 执行
GRANT后必须跟FLUSH PRIVILEGES;（仅当手动改了mysql.user表才强制需要；正常用GRANT则自动生效）
应用报错 Table 'mysql.proc' doesn't exist？禁用存储过程相关权限
有些 ORM 或监控工具（如早期 Django、Zabbix）在连接后会尝试查 mysql.proc 或调用 SHOW PROCEDURE STATUS，一旦用户没对应权限就报错，甚至中断连接。这不是业务逻辑问题，而是权限粒度太粗导致的副作用。
安全做法是主动阻断这类隐式依赖：
- 不授予
PROCEDURE、EXECUTE、ALTER ROUTINE等任何与存储对象相关的权限 - 如果应用确实需要读系统表（极少见），只开最小范围：
GRANT SELECT ON mysql.columns_priv TO 'u1'@'%';，而不是整个mysql库 - 验证方式：用该用户登录后执行
SHOW DATABASES;—— 正常应只看到被授权的库；若能看到mysql，说明权限收得不够紧
权限变更后应用仍缓存旧连接？注意连接池生命周期
权限改了，但 Java HikariCP、Python SQLAlchemy 连接池里的长连接可能还在用旧上下文，导致新权限不生效，甚至出现“明明 revoke 了却还能查”的假象。
必须同步处理连接池：
- 重启应用是最稳妥方式；如不能重启，需触发连接池刷新（如 HikariCP 的
evictConnections()或设置maxLifetime=30000让连接自然淘汰） - 测试时别只用命令行连一次就下结论；要用应用真实走一遍查询路径，包括事务开启、预编译语句、多语句 batch 等场景
- 线上环境建议配合
pt-show-grants工具导出账号权限快照，每次变更后 diff 对比，避免遗漏隐式继承的权限
最小权限不是设完 GRANT 就结束的事——host 匹配、认证插件、连接池残留、系统表访问，每个环节都可能绕过你的限制。真正落地时，要像攻击者一样去试探边界，而不是只看文档里那几行 SQL 是否执行成功。
