2016-01-05 2 views
0

У меня есть таблица MySQL, называемая EventTable, для хранения информации о событиях, в том числе их типов, времени и содержания и т. Д. Я удалил некоторые избыточные данные из таблицы и использовал команду optimize table EventTable, чтобы освободить неиспользуемое пространство и повысить производительность, то это показываетКак проверить оптимизацию работы MySQL или нет?

+----------+----------+----------+----------------------------------------- -------------------------------------------- + 
| 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';

, но таблица остается точно такой же, индекс не меняется вообще.

После этого я нашел комментарий ниже, в статье описано, что нет необходимости использовать последний для замены прежнего, bacause «Для таблиц InnoDB OPTIMIZE TABLE отображается в ALTER TABLE».

Итак, есть ли способ изучить работу «Оптимизация», как я ожидаю?

+0

Пожалуйста, исправьте свое форматирование. –

ответ

0

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 

Первый не показал никаких изменений; второй показал несколько изменений. I считают, что первый действительно перестроил таблицу и индексы, но они оказались точно такими же.

Каждый вторичный индекс - это BTree, состоящий из 1 или более блоков 16 КБ в «Длина данных».

OPTIMIZE TABLE почти никогда не стоит делать на столах InnoDB.