如何检查MySQL的优化工作与否？

Question

我有一个名为“EventTable”的 MySQL 表，用于存储事件的信息，包括它们的类型， 发生时间、内容等。我已经从表中删除了一些冗余数据并使用命令optimize table EventTable释放未使用的空间并提高性能，然后它显示

+----------+----------+----------+-----------------------------------------  -------------------------------------------- +
| Table | Op | Msg_type | Msg_text |
+----------+----------+----------+------------------------------------------------------------------------------------- +
| EventTable | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| EventTable | optimize | status | OK |
+----------+----------+----------+--------------------------------------------------------------------------------------+

然后根据http://www.justin.my/2010/09/table-does-not-support-optimize-doing-recreate-analyze-instead/

我用

ALTER TABLE advcms.event ENGINE='InnoDB';

相反，但表保持不变，索引根本没有改变。

然后我发现文章下面的评论描述了不需要用后者代替前者，因为“对于 InnoDB 表，OPTIMIZE TABLE 映射到 ALTER TABLE”。

那么，有什么方法可以按我的预期检查“优化”工作吗？

Answer 1

OPTIMIZE 和普通的ALTER 都做同样的事情。它可能实际上是“什么都没有”。

除了SHOW TABLE STATUS（或对information_schema的等效查询）之外，没有其他方法可以查明它做了什么。

mysql> SHOW TABLE STATUS LIKE 'parts3'\G
*************************** 1. row ***************************
           Name: parts3
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 6726
 Avg_row_length: 31
    Data_length: 212992
Max_data_length: 0
   Index_length: 0
      Data_free: 665845760
 Auto_increment: NULL
    Create_time: 2014-03-05 13:10:04

mysql> OPTIMIZE TABLE parts3;
+-------------+----------+----------+-------------------------------------------------------------------+
| Table       | Op       | Msg_type | Msg_text                                                          |
+-------------+----------+----------+-------------------------------------------------------------------+
| test.parts3 | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.parts3 | optimize | status   | OK                                                                |
+-------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.52 sec)

mysql> SHOW TABLE STATUS LIKE 'parts3'\G
*************************** 1. row ***************************
           Name: parts3
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 6726
 Avg_row_length: 31
    Data_length: 212992
Max_data_length: 0
   Index_length: 0
      Data_free: 665845760
 Auto_increment: NULL
    Create_time: 2014-03-05 13:10:04

这是另一个：

mysql> SHOW TABLE STATUS LIKE 'j_1'\G
*************************** 1. row ***************************
           Name: j_1
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 949
 Avg_row_length: 466
    Data_length: 442368
Max_data_length: 0
   Index_length: 294912
      Data_free: 665845760
 Auto_increment: NULL
    Create_time: 2014-03-05 13:10:34

mysql> OPTIMIZE TABLE j_1;
+---------+----------+----------+-------------------------------------------------------------------+
| Table   | Op       | Msg_type | Msg_text                                                          |
+---------+----------+----------+-------------------------------------------------------------------+
| try.j_1 | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| try.j_1 | optimize | status   | OK                                                                |
+---------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.61 sec)

mysql> SHOW TABLE STATUS LIKE 'j_1'\G
*************************** 1. row ***************************
           Name: j_1
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 980
 Avg_row_length: 351
    Data_length: 344064
Max_data_length: 0
   Index_length: 393216
      Data_free: 665845760
 Auto_increment: NULL
    Create_time: 2014-03-05 13:10:34

第一个没有变化；第二个显示了一些变化。我相信第一个确实重建了表和索引，但它们的大小恰好相同。

每个二级索引都是一个BTree，由“Data_length”中的1个或多个16KB块组成。

OPTIMIZE TABLE 在 InnoDB 表上几乎不值得做。