说到MySQL权限管理，这真是个让人又爱又恨的话题。记得去年我们公司就出过这么个事儿：新来的运维同事不小心给测试账号开了全局权限，结果差点把生产库的表给删了，当时整个技术部都炸锅了！从那以后，我就特别关注MySQL权限管理的那些”坑”。今天就跟大家聊聊几个最常见的权限管理问题，希望能帮你们避开这些雷区。
为什么root账号不能随便用？
我知道很多开发同学为了方便，动不动就用root账号连接数据库，这简直就是在玩火！MySQL的root账号就像Linux的root一样，拥有所有权限。万一账号泄露，攻击者可以直接删库跑路。我建议至少要创建专门的运维账号，只给必要的权限。比如只给备份账号SELECT和LOCK TABLES权限就够了，写操作账号单独配置。
GRANT语句的常见误区
很多人用GRANT授权时都会犯两个错误：一是习惯性加上WITH GRANT OPTION（允许被授权者继续授权），二是不指定具体的数据库。这就好比把钥匙随便给人还允许他配钥匙！正确的做法应该是像这样：GRANT SELECT ON dbname.* TO ‘user’@’host’，只给特定库的特定权限。
那些年踩过的”通配符”坑
MySQL支持使用%作为主机名的通配符，但这里有个大坑：’user’@’%’和’user’@’192.168.1.%’的匹配优先级是不一样的！我曾经遇到过一个奇葩问题：配置了’dev’@’10.%’和’dev’@’10.0.0.%’两个账号，结果来自10.0.0.1的连接总是指向权限较少的那个账号，排查了半天才发现是匹配顺序的问题。
权限回收的”后遗症”
你以为REVOKE之后权限就立刻生效了？太天真了！MySQL的权限变更要等到下次重新连接才会生效，这在生产环境可是个重大隐患。我的解决办法是执行FLUSH PRIVILEGES强制刷新，或者干脆KILL掉相关会话。不过要注意，频繁执行FLUSH PRIVILEGES会影响性能，这个度要把握好。
审计才是终极方案
说真的，权限管理不能只靠人工配置。我现在都会启用MySQL的审计插件，记录所有账号的操作日志。有次就靠这个抓住了某个开发在非工作时间偷偷改生产数据的行为（他坚称是测试环境…）。可以考虑用企业版的audit plugin，或者开源的MariaDB审计插件，这钱真的不能省！
权限管理看似简单，实际上处处是坑。建议大家定期用SHOW GRANTS检查账号权限，复杂的权限体系最好写成文档。你们有没有遇到过什么奇葩的权限问题？欢迎在评论区分享你的”血泪史”～
评论