Альтернативы механизму устройства хранения данных ПАМЯТИ для MySQL
Этот код работает нормально:
bool conduct_it_support(bool init) {
bool on_off_attempt=init;
char selectVal[10] = "000000000";
std::cout << "Have you tried turning it off and on again? (true / false)\n";
std::cin >> selectVal;
if(selectVal == "false") {
on_off_attempt=false;
}
else {
on_off_attempt=true;
}
return on_off_attempt;
}
int main()
{
bool attempt;
attempt = conduct_it_support(attempt); {
std::cout << "so it was " << attempt << "?\n";
}
Попробуйте этот код здесь .
5 ответов
Таблица с 800k строками не должна быть никакой проблемой к mysql, какой механизм устройства хранения данных Вы используете. С размером 100 МБ полная таблица (данные и ключи) должна жить в памяти (mysql ключевой кэш, кэш файла ОС, или propably в обоих).
Сначала Вы проверяете индексы. В большинстве случаев оптимизация индексов дает Вам лучшее повышение производительности. Никогда не делайте ничто больше, если Вы не вполне уверены, они находятся в форме. Вызовите использование запросов EXPLAIN и наблюдайте за случаями, где не или неправильный индекс используется. Это должно быть сделано с данными реального мира а не на сервере с данными тестирования.
После оптимизации индексов, запросы должны закончиться частью секунды. Если запросы являются все еще слишком медленными, затем просто стараются не выполнять их при помощи кэша в Вашем приложении (memcached, и т.д.). Учитывая, что данные в таблице никогда не изменяются не должно быть никаких проблем со старыми данными кэша и т.д.
Если Ваша таблица запрашивается много, она, вероятно, уже кэшируется на уровне операционной системы, в зависимости от того, сколько памяти находится в Вашем сервере.
MyISAM также допускает предварительно загружение индексов таблицы MyISAM в память с помощью механизма, названного Кэшем Ключа MyISAM. После создания ключевого кэша, можно загрузить индекс в кэш с помощью ИНДЕКСА КЭША или ЗАГРУЗИТЬ ИНДЕКСНЫЙ синтаксис.
Я предполагаю, что Вы проанализировали свою таблицу и запросы и оптимизировали Ваши индексы после фактических запросов? Иначе это - действительно что-то, что необходимо сделать прежде, чем попытаться сохранить всю таблицу в памяти.
Принятие данных редко изменяется, Вы могли потенциально повысить производительность запросов значительно с помощью кэширования запроса MySql.
Если у Вас есть достаточно памяти, выделенной для использования Mysql - в пуле буферов Innodb, или для использования MyIsam, можно считать базу данных в память (просто 'ВЫБОР * от имени таблицы') и если нет никакой причины удалить его, это остается там.
Вы также получаете лучшее ключевое использование, поскольку таблица MEMORY только делает колотившие хешу ключи, а не полный доступ B-дерева, который для меньших, групповых ключей мог бы быть жирами достаточно, или не так с такой большой таблицей.
Как обычно, лучшая вещь сделать это для сравнительного тестирования его.
Другая идея при использовании v5.1, для использования типа АРХИВНОЙ ТАБЛИЦЫ, который может быть сжат и может также ускорить доступ к содержанию, если они легко сжимаемы. Это подкачивает процессорное время для распаковывания для доступа IO/memory.
Если данные никогда не изменяются, Вы могли бы легко копировать таблицу по нескольким серверам баз данных.
Таким образом, Вы могли разгрузить некоторые запросы к другому серверу, получив некоторую дополнительную комнату дыхания для основного сервера.
Улучшение скорости зависит от текущей загрузки базы данных, не будет никакого улучшения, если Ваша загрузка базы данных будет очень низкой.
PS:
Вы знаете, что таблицы MEMORY забывают свое содержание, когда база данных перезапускает!