| freeing items | 0.000171 |

| storing result in query cache | 0.000017 |

| logging slow query | 0.000007 |

| logging slow query | 0.000006 |

| cleaning up | 0.000008 |

+--------------------------------+------------+

从上可以清楚的看到时间消耗基本都花费在临时文件拷贝上了，对于排序其实还没花费多久。那问题的关键就是在于解决临时文件如何在内存中建立。

简单商讨了一下，觉得还是先建立索引看看吧。针对这个查询条件应该建立postTime和name的联合索引。但执行时发现：

mysql> alter table entityNameTemp add key idx_postTime_name ( postTime, name );

ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes

这怎么会超过长度了呢？name字段应该很短才对，postTime还是一个时间字段更长不了。但是一检查发现居然建表的人写的name是varchar(600)。突然想到mysql读取时内存开辟是根据声明的长度来的，再一联想，mysql估计需要读取文件的大小就是根据字段声明来算出来的。果断修改name到varchar(20)，一执行就几秒了，再看一下详细时间消耗：

mysql> show profile;

+--------------------------------+----------+

| Status | Duration |

+--------------------------------+----------+

| starting | 0.000036 |

| checking query cache for query | 0.000094 |

| Opening tables | 0.000216 |

| System lock | 0.000010 |

| Table lock | 0.000038 |

| init | 0.000038 |

| optimizing | 0.000014 |

| statistics | 0.000019 |

| preparing | 0.000018 |

| Creating tmp table | 0.000040 |

| executing | 0.000008 |

| Copying to tmp table | 3.863467 |

| Sorting result | 0.092263 |

| Sending data | 0.000061 |

| end | 0.000006 |

| removing tmp table | 0.004514 |

| end | 0.000009 |

| query end | 0.000005 |

| freeing items | 0.000035 |

| storing result in query cache | 0.000013 |

| logging slow query | 0.000005 |

| cleaning up | 0.000005 |

+--------------------------------+----------+

问题基本算解决了，查看临时文件使用情况也确实使用了内存临时文件。加上索引试试，查看执行计划也用上索引了，但是实际执行效果来看提升效果不大。因为还是要拷贝到临时文件表，innodb对于count操作优化确实比较难。

另外一个问题就是对整个系统的影响，这估计是因为用到了磁盘会导致io占用过高。现在查询时间比较短，现象比较难重现了。