Почему размер файла MYD такой большой? - PullRequest
1 голос
/ 30 июля 2009

Когда я создавал данные о стрессе для таблицы, я обнаружил, что генерируются следующие файлы.

-rw-rw---- 1 mysql mysql       8858 Jul 28 06:47 card.frm
-rw-rw---- 1 mysql mysql 7951695624 Jul 29 20:48 card.MYD
-rw-rw---- 1 mysql mysql   51360768 Jul 29 20:57 card.MYI

На самом деле я вставил 1985968 записей в эту таблицу. Но размер файла индекса невероятен.

Структура таблицы

create table card(
    company_id int(10),
    emp_number varchar(100),
    card_date varchar(10),
    time_entry text,
    total_ot varchar(15),
    total_per varchar(15),
    leave_taken double,
    total_lop double,
    primary key (company_id,emp_number,card_date),
    index (company_id,card_date)
);

Есть ли способ уменьшить размер файла MYD?

Ответы [ 2 ]

8 голосов
/ 30 июля 2009

Обратите внимание, что .MYI - это ваш индекс, а .MYD - это ваши данные. Единственный способ уменьшить размер вашего .MYD - это удалить строки или изменить размеры столбцов.

50 МБ для индекса на 2 миллиона строк невелико.

Давайте посмотрим на размер таблицы:

  • company_id - 4 байта
  • emp_number - 101 байт
  • дата_карты - 11 байт
  • total_ot - 17 байт
  • total_per - 17 байт
  • left_taken - 9 байт
  • total_lop - 9 байт
  • time_entry - средняя (длина (time_entry)) + 3 байта

Это дает нам длину строки 172 + time_entry байтов. Если time_entry составляет в среднем 100 байт. Вы смотрите на 272 * 2000000 = 544MB

Для меня важно количество VARCHAR. Номер сотрудника должен быть varchar (100), или даже varchar вообще? Вы полностью дублируете эти данные в своем индексе (company_id, emp_number, card_date) при индексации всего столбца.

Вам, вероятно, здесь не нужен varchar, и, возможно, он не включен в первичный ключ.

Вам действительно нужно time_entry, чтобы быть полем TEXT? Это, вероятно, самый большой потребитель пространства в вашей базе данных.

Почему вы используете varchar (10) для даты карты? Если бы вы использовали DATETIME, вы бы использовали только 8 байтов вместо 11, TIMESTAMP был бы 4 байта, а DATE был бы 3 байта.

Вы также добавляете 1 байт для каждого столбца, который может быть НЕДЕЙСТВИТЕЛЕН.

Также попробуйте запустить команды ANALYZE / REPAIR / OPTIMIZE TABLE.

3 голосов
/ 30 июля 2009

Многое зависит от того, насколько большим может быть текстовое поле time_entry. Я собираюсь предположить, что это маленький, меньше чем 100 байтов. Тогда у вас есть примерно 4 + 100 + 10 + 100 + 15 + 15 + 8 + 8 = примерно 300 байт данных на запись. У вас есть 2 миллиона записей. Я ожидаю, что база данных будет 600 мегабайт. Фактически вы показываете 8000 мегабайт данных в MYD на диске, или в 12 раз. Что-то не так.

Ваш лучший диагностический инструмент - Показать статус таблицы . В частности, проверьте Avg_row_length и Data_length, они дадут вам некоторое представление о том, куда движется пространство.

Если вы используете таблицы MyISAM, вы можете обнаружить, что myisamchk поможет уменьшить таблицу. Этот инструмент особенно помогает, если вы вставили, а затем удалили много строк из базы данных. «Оптимизировать таблицу» тоже может помочь. MyISAM поддерживает сжатые таблицы только для чтения через myisampack . Впрочем, я бы отнесся к этому как к последнему средству.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...