涂抹MySQL--第5章 MySQL数据库中的权限体系 - 5.1谈谈权限处理逻辑-CSDN博客

提到权限，通常都是用户A拥有对象B的权限，很多朋友想必已经对此形成了思维定势，毕竟像Oracle或SQL Server这类大型数据库软件中的权限验证，也都是如此设定，指定甲用户拥有操作乙对象的权限。

而MySQL数据库的权限验证在设计阶段就体现的有所不同，它在这中间又加了一级维度，变成从丙处来的那个甲拥有访问乙的权限。可能有些同学一下子转不过弯来，那我换一个角度来描述：甲只有从丙处连接过来，才能够访问对象乙。这样对比的话，是否又跟Oracle/SQL Server这类数据库的身份验证机制比较相似了呢，只是如Oracle这类数据库软件，默认是不加丙这一层的（如果想加当然也可以支持），而在MySQL中，丙（来源）成了一个必选项，也就是说，对于MySQL数据库，甲的身份当然重要，但甲从哪儿来的也同样重要，即使同样叫“甲”，从A处来和从B处来的甲的权限可以不同，甚至应该视作是两个不同的用户。

在本章正式开始前先描述这样一段，并不是想说MySQL有多么高级或先进，只是想表达这样一种看法，MySQL确实有所不同。OK，接下来，跟随三思一起，进入MySQL的权限世界吧！

5.1 谈谈权限处理逻辑

所有权限认证的根本目的，都是为了让用户只能做允许它做的事情，MySQL也不例外，大家（泛指数据库产品）实现的原理也都差不多，只不过机制上稍有差异，在权限粒度控制上有所不同。

MySQL数据库服务采用的是白名单的权限策略，也就是说，明确指定了哪些用户能够做什么，但没法明确地指定某些用户不能做什么，对权限的验证主要是通过mysql库下的几个数据字典表，来实现不同粒度的权限需求，关于这几个字典表后面会有章节详细介绍。这里简要介绍其处理逻辑，MySQL在检查用户连接时可以分为两个阶段。

5.1.1 能不能连接

当用户发出请求尝试连接MySQL服务时，MySQL首先是检查登录用户的相关信息，比如发起登录请求的主机名是否匹配、登录使用的用户名或密码是否正确，如果这一关过不去，那连接就直接被拒绝了，常见的登录失败信息“ERROR 1045 (28000): Access denied for user '...'”，就是在这个阶段的验证未通过抛出的错误提示。

MySQL数据库验证权限有3个维度：我是谁、从哪儿来、到哪儿去（真像哲学家探讨人生的终极命题呀）。这3个维度中，前两个决定能不能连接，就是说验证用户的身份是否合法，本步通过之后，才会涉及能不能访问目标对象的环节。

在MySQL数据库中验证用户，需要检查3项值：用户名、用户密码和来源主机，这3项信息的正确值（创建用户时指定），保存在mysql库中的user表对象内，分别对应user表对象中的user、password和host三列。如果事先看过user表中这几列的定义，会发现MySQL的设计非常有意思，这3列居然都可以为空（注意不是NULL值），这也是某些场景里登录MySQL数据库不需要输入用户名或不需要输入密码的原因。

5.1.2 能不能执行操作

连接到数据库之后，能不能执行操作，比如说建库、建表、改表，查询或修改数据等，这个阶段涉及的因素（对象）要复杂一点点，除了上面提到的mysql.user字典表起作用外，另外还有mysql.db、mysql.tables_priv、mysql.columns_priv、mysql.proc_priv（事实上在5.6.10版本以前，还有mysql.host表，不过之后版本中，host表已经明确被废弃，其实在之前版本里它也没什么用，原本就是被判了死缓，现在缓期过完了，不过没有转为无期，而是直接执行死刑）几个字典表来对数据库，或针对对象甚至是对象列做更细粒度的控制。

这些字典表虽说各有分工，但相互之间在权限分配上还是会有一定的重合，比如说tables_priv字典表一看就知道是专门针对表对象的权限明细，不过user表和db表中也可以授予用户操作表对象的权限。那么MySQL服务是怎么来区分这些权限的呢？我的个人理解，总的原则仍然是按照粒度。

比如要执行对整个数据库服务的管理操作，那么一定是根据user表中的记录验证权限是否匹配，因为只有这个表是针对MySQL服务全局的；如果请求某个明确的数据库对象，比如更新某个表中记录，那么MySQL服务也仍然会按照粒度从粗到细的方式，先检查user字典表中全局的设置，找不到匹配的话，则继续检查db字典表这样的方式；一旦在某个粒度匹配到合适的权限，就允许用户执行，否则继续查询更细的粒度表；如果所有的粒度滤过一遍，还是没能匹配到合适的权限，那么用户的操作就会被拒绝了。

通过上述逻辑还可以明确一点，就是粒度控制越细，权限验证上的步骤就会越多，相应对性能必然会有影响，这一点在进行权限分配时务必考虑在内。

5.1.3 权限变更何时生效

向用户分配的权限，哪些情况下会生效呢？一般来说，MySQL数据库在启动时就会将前面提到的几个权限字典表中的内容读到内存里，当有用户连接或执行操作时，根据内存中的数据来检查用户是否有权限执行相应的操作。

注意，如果你读的足够认真并且大脑持续在进行思考，这会儿应该会产生这样的一个疑问：如果用户连接上数据库后，管理员对该用户的权限进行了修改操作，是否即时生效呢？针对这个问题，答案是：看情况！

如果是通过GRANT、REVOKE、SET PASSWORD、RENAME USER等MySQL提供的命令执行修改，那么权限将马上生效，因为这些命令将触发系统重新载入授权表（GRANT TABLES）到内存。
如果是手动修改字典表方式（INSERT、UPDATE、DELETE），没错，MySQL中可以手动修改字典表中的记录达到变更用户权限的目的，但这种情况下权限并不会马上生效，除非重启MySQL服务，或者DBA主动触发授权表的重新装载。

问题又来了，授权表被重新加载后，对当前已连接的客户端又会产生哪些影响呢？具体如下：