MySQL性能优化全攻略－ 相关数据库命令

核心提示： 现在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)了，执行EXPLAIN进行分析得到的结果如下所示：table type possible_keys key key_len ref rows Extratt ALL AssignedPC,ClientID,Actu

现在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)了，执行EXPLAIN进行分析得到的结果如下所示：

　　table type possible_keys key key_len ref rows Extra
　　tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used
　　do ALL PRIMARY NULL NULL NULL 2135
　　range checked for each record (key map: 1)
　　et_1 ALL PRIMARY NULL NULL NULL 74
　　range checked for each record (key map: 1)
　　
　　et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
　　

这还算不上完美，但已经好多了（行数的乘积现在少了一个系数74）。现在这个SQL命令执行大概需要数秒钟时间。

为了避免tt.AssignedPC = et_1.EMPLOYID以及tt.ClientID = do.CUSTNMBR比较中的列长度不匹配，我们可以进行如下改动：

mysql > ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),

MODIFY ClientID VARCHAR(15);

现在EXPLAIN显示的结果如下：

　　table type possible_keys key key_len ref rows Extra
　　et ALL PRIMARY NULL NULL NULL 74
　　tt ref AssignedPC,ClientID,ActualPC ActualPC 15 et.EMPLOYID 52 where used
　　et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
　　do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1

这个结果已经比较令人满意了。

余下的问题在于，默认情况下，MySQL假定tt.ActualPC列的值均匀分布，而事实上tt表的情况并非如此。幸而，我们可以很容易地让MySQL知道这一点：

shell > myisamchk --analyze PATH_TO_MYSQL_DATABASE/tt

shell > mysqladmin refresh

现在这个连接操作已经非常理想，EXPLAIN分析的结果如下：

　　table type possible_keys key key_len ref rows Extra
　　tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used
　　et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
　　et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
　　do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
　　

▲ OPTIMIZE

OPTIMIZE能够恢复和整理磁盘空间以及数据碎片，一旦对包含变长行的表进行了大量的更新或者删除，进行这个操作就非常有必要了。OPTIMIZE当前只能用于MyISAM和BDB表。

结束语：从编译数据库服务器开始、贯穿整个管理过程，能够改善MySQL性能的因素实在非常多，本文只涉及了其中很小的一部分。尽管如此，我们希望本文讨论的内容能够对你有所帮助。