下面的例子展示了如何通过 EXPLAIN 提供的信息来较大程度地优化多表联合查询的性能。

假设有下面的 SELECT 语句，正打算用 EXPLAIN 来检测：

EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,

tt.ProjectReference, tt.EstimatedShipDate,

tt.ActualShipDate, tt.ClientID,

tt.ServiceCodes, tt.RepetitiveID,

tt.CurrentProcess, tt.CurrentDPPerson,

tt.RecordVolume, tt.DPPrinted, et.COUNTRY,

et_1.COUNTRY, do.CUSTNAME

FROM tt, et, et AS et_1, do

WHERE tt.SubmitTime IS NULL

AND tt.ActualPC = et.EMPLOYID

AND tt.AssignedPC = et_1.EMPLOYID

AND tt.ClientID = do.CUSTNMBR;

在这个例子中，先做以下假设：

要比较的字段定义如下：

数据表的索引如下：

tt.ActualPC 的值是不均匀分布的。

在任何优化措施未采取之前，经过 EXPLAIN 分析的结果显示如下：

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, NULL NULL NULL 3872

ClientID,

ActualPC

range checked for each record (key map: 35)

由于字段 type 的对于每个表值都是 ALL，这个结果意味着MySQL对所有的表做一个迪卡尔积；这就是说，每条记录的组合。这将需要花很长的时间，因为需要扫描每个表总记录数乘积的总和。在这情况下，它的积是 74 * 2135 * 74 * 3872 = 45,268,558,720 条记录。如果数据表更大的话，你可以想象一下需要多长的时间。

在这里有个问题是当字段定义一样的时候，MySQL就可以在这些字段上更快的是用索引（对 ISAM 类型的表来说，除非字段定义完全一样，否则不会使用索引）。在这个前提下，VARCHAR 和 CHAR是一样的除非它们定义的长度不一致。由于 tt.ActualPC 定义为 CHAR(10)，et.EMPLOYID 定义为 CHAR(15)，二者长度不一致。

为了解决这个问题，需要用 ALTER TABLE 来加大 ActualPC 的长度从10到15个字符：

MySQL手册版本 5.0.20-MySQL优化(四) （1） MySQL手册版本 5.0.20-MySQL优化(二) （1）(3)

评论 (0) All