MySQL管理（续）

访问控制技巧

由于MySQL中访问控制系统工作的方法的影响，在建立你的用户之前你必须知道两个特征。

当建立的用户只能从MySQL服务运行的计算机上登录到MySQL服务(也就是说，你需要他们telnet到服务器并在那里运行MySQL的客户端程序，或者是使用象PHP这样的服务器端脚本语言进行通信)，你大概会问自己GRANT命令的部分应该填什么内容。如果服务是运行在www.host.net。你是应该将用户设置为[email protected]还是username@localhost呢？

答案是，你不能依赖其中的任何一种来处理任何连接。从理论上来说，如果用户在连接时(无论是使用mysql客户端还是使用PHP的mysql_connect函数)指定了主机名，这个主机名必须与访问控制系统中的记录匹配。但是因为你也许不想强迫你的用户指定主机名(事实上，mysql客户端的用户也许根本不会指定主机名)，你最好使用下面这种工作环境。

对于用户需要能够从MySQL服务在其上运行的机器上连接MySQL的情况，在MySQL访问控制系统中建立两个用户记录：一个使用实际的主机名(例如，[email protected])，另一个使用localhost(例如，username@localhost)，当然，你需要为两个用户分别grant/revoke所有的权限。

MySQL管理者所要面对的另一个带有普通性的问题是一个其中的主机名使用了通配符的用户记录(例如，前面提到jessica@%.host.net)没起作用。发生这种情况，一般是由于MySQL访问控制系统中记录的优先级的问题。具体地说，越具体的主机名优先级越高(例如，www.host.net是最具体的，%.host.net是比较具体的，而%是最不具体的)。

在一个新安装后，MySQL访问控制系统包含两个匿名用户记录(它允许在当前主机上使用任何用户名进行连接--这两个记录分别支持从localhost连接以及从服务器的实现的主机名进行连接)，以及两个root用户目录。我们上面讨论的情况发生时是由于匿名用户目录的优先级比我们的新记录高，因为他们的主机名更具体。

让我们看看www.host.net上user表的内容，我们假定已经添加了Jessica的记录。数据行是按照MySQL服务在确认连接时的优先级排列的：

正如你看到的，因为Jessica的记录的主机名最不具体，它的优先级最低。当Jessica试图从www.host.net连接时，MySQL服务将他的连接匹配为一个匿名用户记录(空白的User值与任何人匹配)。因为这些匿名记录不需要口令，而也许Jessica输入了他的口令，MySQL将拒绝这个连接。即使Jessica没有输入口令，他可能也只被给予了匿名用户的权限(非常有限)，而不是他原来被赋予的权限。

解决这个问题的方法是，要么你删除匿名用户的记录(DELETE FROM user WHERE User="")，要么再为所有的可能从localhost连接的用户指定两条记录(例如，相对于localhost以及相对于服务器的实际主机名)：

因为要为每个用户维护三个用户记录(以及相应的三套权限)会很麻烦，所以我们推荐你删除匿名用户，除非你需要用他们来完成什么特殊的应用：

被锁在外面？

就象把钥匙丢失在车上一样，在花费了一个小时安装并调试好一个新的MySQL服务器之后忘记了口令的确是件麻烦事。幸运的是，如果你有访问MySQL运行的计算机的root权限，或者你能够使用运行MySQL服务的用户登录(如果你按照第一章中的指导，这是指mysqlusr)，那么不会出什么问题。按照下面的步骤，你可以获得服务的控制权。

首先，你必须关闭MySQL服务。因为通常使用的mysqladmin需要用到你忘了的口令，你只能通过杀掉服务的进程来完成这项工作。使用ps命令或者看看服务的PID文件(在MySQL数据目录下)，确定MySQL服务的进程的ID，然后使用下面的命令终止它：

这里是MySQL服务的进程的ID。这样将可以终止服务。除非绝对必要，不要使用kill -9，因为这样有可能损坏你的表文件。如果你被迫只能这么做，下面将告诉你如何检查和修复那些文件。

关闭了服务之后，你可以通过运行带--skip-grant-tables命令行选项的safe-mysqld (在Windows下使用mysqld或mysqld-nt)命令重启它。这将指示MySQL服务允许自由的访问，明显的，我们应该尽可能地短时间的使用这种模式运行服务，以避免固有的安全风险。

连接成功后，改变你的root口令：

最后，断开连接并指示MySQL服务重载授权表以接收新的口令：

现在一切都好了--甚至不会有人知道你干了什么。就象你虽然将钥匙丢在了车上，而你自己也在车上一样。

检查和修复MySQL数据文件

由于临时断电，使用kill -9中止MySQL服务进程，或者是Jessica的朋友idiot@%.host.net又犯了一个错误，所有的这些都可能会毁坏MySQL的数据文件。如果在被干扰时，服务正在改变文件，文件可能会留下错误的或不一致的状态。因为这样的毁坏有时是不容易被发现的，当你发现这个错误时可能是很久以后的事了。于是，当你发现这个问题时，也许所有的备份都有同样的错误。

MySQL参考手册的第十五章讲述了MySQL自带的myisamchk的功能，以及如何使用它检查和修复你的MySQL数据文件。虽然这一章对于每个想要搭建一个强壮的MySQL服务的人都是推荐阅读的，我们还是有必要在这里对其中的要点进行讨论。

在我们继续之前，你必须意识到myisamchk程序对用来检查和修改的MySQL数据文件的访问应该是唯一的。如果MySQL服务正在使用某一文件，并对myisamchk正在检查的文件进行修改，myisamchk会误以为发生了错误，并会试图进行修复--这将导致MySQL服务的崩溃！这样，要避免这种情况的发生，通常我们需要在工作时关闭MySQL服务。作为选择，你也可以暂时关闭服务以制作一个文件的拷贝，然后在这个拷贝上工作。当你做完了以后，重新关闭服务并使用新的文件取代原来的文件(也许你还需要使用期间的变更日志)。

MySQL数据目录不是太难理解的。每一个数据库对应一个子目录，每个子目录中包含了对应于这个数据库中的数据表的文件。每一个数据表对应三个文件，它们和表名相同，但是具有不同的扩展名。tblName.frm文件是表的定义，它保存了表中包含的数据列的内容和类型。tblName.MYD文件包含了表中的数据。tblName.MYI文件包含了表的索引(例如，它可能包含lookup表以帮助提高对表的主键列的查询)。

要检查一个表的错误，只需要运行myisamchk(在MySQL的bin目录下)并提供文件的位置和表名，或者是表的索引文件名：

上面的两个命令都可以执行对指定表的检查。要检查数据库中所有的表，可以使用通配符：

要检查所有数据库中的所有表，可以使用两个通配符：

如果不带任何选项，myisamchk将对表文件执行普通的检查。如果你对一个表有怀疑，但是普通的检查不能发现任何错误，你可以执行更彻底的检查(但是也更慢！)，这需要使用--extend-check选项：

对错误的检查是没有破坏性的，这意味着你不必担心执行对你的数据文件的检查会使已经存在的问题变得更糟。另一方面，修复选项，虽然通常也是安全的，但是它对你的数据文件的更改是无法撤消的。因为这个原因，我们强烈推荐你试图修复一个被破坏的表文件时首先做个备份，并确保在制作这个备份之前你的MySQL服务是关闭的。

当你试图修复一个被破坏的表的问题时，有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立，删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。

这三种修复方法如下所示：

第一种是最快的，用来修复最普通的问题；而最后一种是最慢的，用来修复一些其它方法所不能修复的问题。

检查和修复MySQL数据文件

如果上面的方法无法修复一个被损坏的表，在你放弃之前，你还可以试试下面这两个技巧：

如果你怀疑表的索引文件(*.MYI)发生了不可修复的错误，甚至是丢失了这个文件，你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上，使用下面的命令删除表的内容：

mysql> DELETE FROM tblName;

在删除表的内容的同时，会建立一个新的索引文件。退出登录并重新关闭服务，然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。最后，使用myisamchk执行标准的修复(上面的第二种方法)，根据表的数据的内容和表的格式文件重新生成索引数据。

如果你的表的格式文件(tblName.frm)丢失了或者是发生了不可修复的错误，但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表，你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题，使用上面的方法重建一个新的)一起使用。首先制作一个数据和索引文件的拷贝，然后删除原来的文件(删除数据目录下有关这个表的所有记录)。

启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了，但是最好你还是执行一下标准的修复(上面的第二种方法)。

结语

OK，的确这一章没有多少我们通常所习惯的可以具体执行某项实际工作的代码。但是所有的这些工作--备份和恢复数据库，管理MySQL的访问控制系统，数据表的检查和修复--都将有助于我们建立一个经得住时间考验的MySQL数据库服务器。

在本教程的倒数第二章——第九章中，我们会学习一些更复杂的SQL技术以使得我们的关系型数据库服务器可以完成一些你之前也许从未想到过的工作。