MYSQL Оптимизация таблицы с 137000 строками - PullRequest
Новая
       20

MYSQL Оптимизация таблицы с 137000 строками

2 голосов
/ 05 июня 2009

Я пытаюсь оптимизировать базу данных redmine , пока она не доставила слишком много боли; Изменения (в основном журнал всех SVN-изменений) составляют 137000 строк (ish), и для таблицы установлены основные настройки по умолчанию. Нет упаковки ключей и т. Д.

Таблица выглядит следующим образом 

ID int[11] Auto Inc (PK)
changeset_id int[11]
action varchar[1]
path varchar[255]
from_path varchar[255]
from_revision varchar[255]
revision varchar[255]
branch  varchar[255]

Индексы: первичные (ID),
для changeset_id установлено значение INDEX BTREE

Все о кодировке latin1, основанной на информации из http://forge.mysql.com/wiki/Top10SQLPerformanceTips

Механизм таблицы - InnoDB Pack Keys имеет значение по умолчанию (только пакеты char varchar)

Все остальные параметры отключены.

Какой лучший способ оптимизировать это? (Укороченная черта; o))

Ответы [ 2 ]

2 голосов
/ 05 июня 2009

Существуют некоторые общие методы оптимизации для mysql: во-первых, убедитесь, что ваши типы данных соответствуют ABC (см. здесь ). Если перейти сверху вниз, ID и changeset_id выглядят хорошо, действие, вероятно, должно быть char 1 вместо varchar (допускает значение NULL, если вы можете оставить его пустым (и в общем, убедитесь, что значение NULL) правильно на других полях)). Что касается 5 других полей (которые в зависимости от размера, вероятно, будут доминировать в таблице), являются ли строки правильным типом данных? (Я предполагаю, да с path, from_path, branch, но, возможно, revision должен быть числом (я предполагаю, что это не так, он поддерживает git или что-то в этом роде))

Кроме того, они выглядят как цели нормализации, тем более что таблица "paths" и "revisions" нормализует четыре из них ( вот базовый учебник , если вам это нужно)

2 голосов
/ 05 июня 2009

Это полностью зависит от ваших характеристик чтения и записи, то есть от запросов, которые вы делаете, и от того, как часто вы пишете в него.

Способ оптимизации для записи заключается в минимизации количества индексов. В идеале вы должны использовать то, что на сервере MS SQL было бы «кластеризованным индексом» с монотонно увеличивающимся ключом, гарантируя, что вы записываете новые записи в конец таблицы, а другой отдельный индекс не пишете. Еще лучше даже пропустить СУБД и записать в какой-нибудь обычный старый файл журнала, если вам не нужны транзакционные возможности.

Что касается запросов, то они могут быть настолько сложными, насколько вам нравится Имейте в виду, однако, что если вам нужен какой-либо значительный объем данных из таблицы для запроса (т. Е. Это больше, чем просто поиск одной записи на основе ключа), сканирование таблицы может быть не такой уж плохой вещью. Как правило, если вы просматриваете более 3-5% содержимого таблицы, сканирование таблицы будет очень быстрым. Опять же, для этого простой старый файл, вероятно, будет быстрее, чем СУБД.

Если вам нужно оптимизировать оба варианта, рассмотрите возможность оптимизации для записи, а затем регулярно делайте копию, оптимизируемую для запросов, и выполняйте запросы к копии.

...