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

Question

Я пытаюсь оптимизировать Редмайн базу данных, прежде чем она станет слишком болезненной;Изменения (по сути, журнал всех изменений SVN) составляют 137 000 строк (около 1000), а для таблицы установлены базовые настройки по умолчанию.Никакой упаковки ключей и т. д.

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

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]

Индексы:Первичный (идентификатор),
Changeset_id установлен в INDEX BTREE

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

Двигатель таблицы - это клавиши Pack Innodb, установленные по умолчанию (только пакет char varchar)

Все остальные опции отключены.

Как лучше всего это оптимизировать?(Бар усечь ;о) )

Answer 1

Существует несколько общих методов оптимизации MySQL:первое — убедиться, что ваши типы данных соответствуют ABC (см. здесь).Если перейти сверху вниз, ID и Changeset_id выглядят хорошо, действие, вероятно, должно быть символом.1 вместо varchar (обнуляемый, если вы можете оставить его пустым (и, как правило, убедитесь, что ваш обнуляемый параметр установлен правильно в других полях)).Что касается пяти других полей (которые, в зависимости от размера, вероятно, будут доминировать в таблице), являются ли строки правильным типом данных?(Думаю, да, с путем, from_path, веткой, но, возможно, ревизия должна быть числом (я предполагаю, что это не так, поэтому она поддерживает git или что-то в этом роде))

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

Answer 2

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

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

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

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