Хранение данных плюс индексные данные в памяти - InnoDB по сравнению с MyISAM
Примите базу данных, состоящую из 1 ГБ данных и 1 ГБ индексных данных.
Чтобы минимизировать диск IO и следовательно максимизировать производительность, я хочу выделить память MySQL так, чтобы весь набор данных включая индексы мог быть сохранен в RAM (предположите, что машина имеет RAM в изобилии).
Параметр InnoDB innodb_buffer_pool_size используется для определения размера буфера памяти, который InnoDB использует для данных кэша и индексов его таблиц. (Отметьте: память используется для данных И индексов.)
Параметр MyISAM key_buffer_size используется для определения размера буфера памяти, который MyISAM использует для индексов кэша своих таблиц. (Отметьте: память используется ТОЛЬКО для индексов.)
Если бы я хочу, чтобы база данных на 2 ГБ (данные на 1 ГБ и индекс на 1 ГБ) вписалась в память под InnoDB, я просто настроил бы innodb_buffer_pool_size быть 2GB. Два гигабайта будут содержать и данные и индекс.
Однако при устанавливании ключа MyISAM key_buffer_size к 2GB то пространство будет использовано для индекса, но не для данных.
Мои вопросы:
- Может "размер буфера данных" MyISAM (не, индексируют данные) быть настроенным явно?
- Когда MyISAM считает данные таблицы (исключая индексные данные) от диска и когда он будет читать из памяти?
1 ответ
- В MyISAM нет кэша данных общего назначения. Это описано в описании "key_buffer_size" из официальной документации:
Это происходит потому, что MySQL полагается на операционную систему для выполнения кэширования файловой системы при чтении данных, поэтому вы должны оставить некоторое место для кэша файловой системы.
Современные ОС, особенно Linux, имеют очень умную подсистему виртуальной памяти, которая сохраняет часто используемые файлы в кэше страниц, поэтому дисковый ввод-вывод сводится к минимуму, когда рабочий набор помещается в доступной памяти.
- Поэтому, отвечая на второй вопрос: никогда.
Важно не впасть в "переразмер буфера" для различных переменных myisam, таких как read_buffer_size, read_rnd_buffer_size, sort_buffer_size, join_buffer_size и т.д., поскольку некоторые из них выделяются динамически, поэтому больше не всегда означает быстрее - а иногда даже может быть медленнее - см. этот пост на mysqlperformanceblog для очень интересного случая.
Если вы используете 5.1 на платформе posix, вы можете проверить myisam_use_mmap на вашей рабочей нагрузке. Предполагается, что это поможет в случаях высокой конкуренции, уменьшая количество вызовов malloc().