MySQL优化全攻略-相关数据库命令_数据库技巧

※tt.ActualPC值分布不均匀

在进行任何优化之前，EXPLAIN对SELECT执行分析的结果如下：

table type possible_keys key key_len ref rows Extra

et ALL PRIMARY NULL NULL NULL 74

do ALL PRIMARY NULL NULL NULL 2135

et_1 ALL PRIMARY NULL NULL NULL 74

tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872

range checked for each record (key map: 35)

每一个表的type都是ALL，它表明MySQL为每一个表进行了完全连接！这个操作是相当耗时的，因为待处理行的数量达到每一个表行数的乘积！即，这里的总处理行数为74 * 2135 * 74 * 3872 = 45,268,558,720。

这里的问题之一在于，如果数据库列的声明不同，MySQL（还）不能有效地运用列的索引。在这个问题上，VARCHAR和CHAR是一样的，除非它们声明的长度不同。由于tt.ActualPC声明为CHAR(10)，而et.EMPLOYID声明为CHAR(15)，因此这里存在列长度不匹配问题。

为了解决这两个列的长度不匹配问题，用ALTER TABLE命令把ActualPC列从10个字符扩展到15字符，如下所示：

mysql > ALTER TABLE tt MODIFY ActualPC VARCHAR(15);

现在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);