将输出保存到一个文件，然后用find命令来得到各次运行的时间：

C:\downloads>find "sec)" my_com

---------- MY_COM
4 rows in set (6 min 35.52 sec)
10 rows in set (8.36 sec)
10 rows in set (2 min 19.04 sec)
5 rows in set (15.43 sec)
5 rows in set (25.21 sec)
1 row in set (34.08 sec)
4 rows in set (28.48 sec)
2 rows in set (43.85 sec)
10 rows in set (28 min 13.00 sec)
20 rows in set (3 min 40.64 sec)
Empty set (16.66 sec)
2 rows in set (20 min 50.48 sec)
10 rows in set (1 min 11.77 sec)
1 row in set (49 min 11.58 sec)
1 row in set (1 min 24.77 sec)
10 rows in set (1 min 58.55 sec)
1 row in set (4 min 22.08 sec)
10 rows in set (37.06 sec)
1 row in set (2.26 sec)
10 rows in set (7 min 59.96 sec)
10 rows in set (19 min 30.41 sec)
5 rows in set (18 min 30.74 sec)

 　　下面是各组查询测试结果，取实际运行时间。

▲表1 TPC-H scale=10各种压缩和索引数据的测试对比，单位：秒

　　注意：带*号的项目使用修改后的等价查询。独立表空间不压缩(不加外键)，第13个查询没法在合理的时间完成，后续的查询也没有再继续执行。

　　从表1可知，如果没有外键约束，MySQL的前12个查询仍能在合理的时间内运行完成，其中第10、11个查询的时间比添加了外键以后还短，这说明查询优化器对这些查询的优化能力不错，而加上外键约束后，在表不压缩的情况下，大约35分钟就能将22个查询执行完毕，但有些查询的时间变长了，这说明，MySQL采用基于规则的优化，虽然访问表比访问索引更好，还是采用了访问索引的执行计划。

　　MySQL压缩基本上发挥不了提高查询速度的作用，除了个别查询(如查询2)比非压缩表速度快外，其他时间短的查询和未压缩表相当，而时间长的有未压缩表的几倍到几百倍。按理说减少了I/O物理读对整体查询应该有帮助的，但事实并非如此，可能跟MySQL的压缩算法压缩比不高，但解压开销较大有关。可以这么说，MySQL的压缩功能基本不适合于查询。