分析：由于字段 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个字符：altertable tt modify actualpc varchar(15); 现在 tt.actualpc 和 et.employid 都是 varchar(15)，在执行一次explain:

[sql] 
table  type    possible_keys key   key_len ref   rows  extra   
tt     all      assignedpc,  null   null   null  3872  using clientid, where actualpc   
do     all       primary     null   null   null  2135  range checked for each record (keymap: 1)   
et_1   all       primary     null   null   null   74   range checked for eachrecord (key map: 1) et eq_ref primary primary 15 tt.actualpc 1  

这还不够，它还可以做的更好：现在 rows值乘积已经少了74倍。这次查询需要用2秒钟。

第二个改变是消除在比较 tt.assignedpc = et_1.employid 和 tt.clientid= do.custnmbr 中字段的长度不一致问题：

   altertable tt modify assignedpc varchar(15), ->modify clientid varchar(15);
[sql] 
table type possible_keys  key   key_len  ref         rows extra   
et    all    primary      null   null    null        74   
tt    ref  assignedpc,   actualpc 15    et.employid  52    using clientid, where actualpc   
et_1 eq_ref primary      primary  15    tt.assignedpc 1   
do   eq_ref primary      primary  15     tt.clientid  1  

这看起来已经是能做的最好的结果了。遗留下来的问题是，mysql默认地认为字段tt.actualpc的值是均匀分布的，然而表tt并非如此。幸好，我们可以很方便的让mysql分析索引的分布：mysql>analyze table tt; 到此为止，表连接已经优化的很完美了，explain 的结果如下：

[sql] 
table type   possible_keys   key   key_len  ref        rows  extra   
tt    all    assignedpc      null   null    null       3872  using clientid, where actualpc   
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  

请注意，explain 结果中的 rows字段的值也是mysql的连接优化程序大致猜测的，请检查这个值跟真实值是否基本一致。如果不是，可以通过在select 语句中使用 straight_join 来取得更好的性能，同时可以试着在from分句中用不同的次序列出各个表。

调整My sql数据库性能：

改变索引缓冲区长度(key_buffer)：一般，该变量控制缓冲区的长度在处理索引表（读/写操作）时使用。MySQL使用手册指出该变量可以不断增加以确保索引表的最佳性能，并推荐使用与系统内存25％的大小作为该变量的值。这是MySQL十分重要的配置变量之一，如果你对优化和提高系统性能有兴趣，可以从改变key_buffer_size变量的值开始。

改变表长(read_buffer_size)：当一个查询不断地扫描某一个表，MySQL会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果你认为连续扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能。

设定打开表的数目的最大值(table_cache)：该变量控制MySQL在任何时候打开表的最大数目，由此能控制服务器响应输入请求的能力。它跟max_connections变量密切相关，增加 table_cache值可使MySQL打开更多的表，就如增加max_connections值可增加连接数一样。当收到大量不同数据库及表的请求时，可以考虑改变这一值的大小。

对缓长查询设定一个时间限制(long_query_time)：MySQL带有“慢查询日志”，它会自动地记录所有的在一个特定的时间范围内尚未结束的查询。这个日志对于跟踪那些低效率或者行为不端的查询以及寻找优化对象都非常有用。long_query_time变量控制这一最大时间限定，以秒为单位。

Mysql 优化表命令

AnalyzeTable MySQL 的Optimizer（优化元件）在优化SQL语句时，首先需要收集一些相关信息，其中就包括表的cardinality（可以翻译为“散列程度”），它表示某个索引对应的列包含多少个不同的值——如果cardinality大大少于数据的实际散列程度，那么索引就基本失效了。

我们可以使用SHOW INDEX语句来查看索引的散列程度：SHOWINDEX FROM PLAYERS;

TABLE KEY_NAME COLUMN_NAMECARDINALITY

------- -------- ----------- -----------

PLAYERS PRIMARYPLAYERNO 14

因为此时PLAYER表中不同的PLAYERNO数量远远多于14，索引基本失效。

下面我们通过Analyze Table语句来修复索引：

ANALYZE TABLE PLAYERS;

SHOW INDEX FROM PLAYERS;

结果是：

TABLE KEY_NAME COLUMN_NAMECARDINALITY

------- -------- ----------- -----------