Ускорение только для чтения таблицы MyISAM

Question

У нас есть большая таблица MyISAM, которая используется для архивации старых данных. Это архивирование выполняется каждый месяц, и кроме этих случаев данные никогда не записываются в таблицу. Можно ли как-то «сказать» MySQL, что эта таблица доступна только для чтения, чтобы MySQL могла оптимизировать производительность чтения из этой таблицы? Я посмотрел на механизм хранения MEMORY, но проблема в том, что эта таблица настолько велика, что она заняла бы большую часть памяти сервера, что мне не нужно.

Надеюсь, мой вопрос достаточно ясен, я новичок, когда дело доходит до администрирования БД, поэтому любые предложения или предложения приветствуются.

Answer 1

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

Таким образом, предполагая, что у вас есть активная таблица и таблицы сжатой истории с одинаковой структурой таблицы, вы можете использовать следующую схему:

Таблицы:

compressed_month_1
compressed_month_2
active_month

Создать таблицу слияния:

create table history_merge like active_month;
alter table history_merge 
    ENGINE=MRG_MyISAM 
    union (compressed_month_1,compressed_month_2);

Через месяц сожмите таблицу active_month и переименуйте ее в compress_month_3 . Теперь таблицы:

compressed_month_1
compressed_month_2
compressed_month_3
active_month

и вы можете обновить таблицу истории

alter table history_merge 
    union (compressed_month_1, compressed_month_2, compressed_month_3);

Answer 2

Да, вы можете сжать таблицы myisam.

Вот документ от 5.0: http://dev.mysql.com/doc/refman/5.0/en/myisampack.html

Answer 3

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

(Не совсем уверен, что это ухудшит производительность, если вам придется возвращать большую часть строк; рекомендуется тестирование; возможен компромисс между сжатием и чтением с диска).

Я бы сказал: также, конечно, примените обычное:

1. Предоставить соответствующие индексы (на основе наиболее часто используемых запросов)
2. Посмотрите на кластеризацию данных (опять же, если это полезно, учитывая запросы)