如何检查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表，将优化表映射到ALTER”。

那么，有什么方法可以像我所期望的那样检查“优化”工作吗？

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“中的一个或更多16 in块组成。

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