базы данных и отведение диск работа

Question

Я читал электронную книгу главу об индексах и стратегии индексирования, многие из этих аспектов я уже знаю, но я stucked на кластерные индексы в InnoDB, вот цитата:

кластеризация дает наибольшее улучшение для рабочих нагрузок, связанных с I/O. Если данные вписываются в память, то порядок, в котором он обращается, не имеет значения , поэтому кластеризация не приносит большой пользы.

Я верю, что это правда, но как мне догадаться, будут ли данные помещаться в память? Как база данных решает, когда обрабатывать данные в памяти, а когда нет?

Допустим, у нас есть таблица Emp с колоннами ID, Имя и Телефон заполненными 100 000 записей

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

SELECT * FROM Employee; 

Как я знаю, если это будет использовать выгоды от кластерного индекс?

Это как-то по отношению к этой теме Difference between In memory databases and disk memory database

, но все же я не уверен, как база данных будет вести себя

Answer 1

Ваш пример может быть 20MB.

«В память» на самом деле означает «в InnoDB buffer_pool», размер которого контролируется innodb_buffer_pool_size, которое должно быть установлено до около 70% от доступного RAM.

Если ваш запрос попадает на диск, а не находит все кэшированный в buffer_pool, он будет работать (это просто правило большого пальца) в 10 раз медленнее.

Что вы говорите о «кластерном индексе», вводит в заблуждение. Позвольте мне перевернуть ситуацию ...

• InnoDB действительно нуждается в PRIMARY KEY.
• PK (по определению в MySQL) UNIQUE.
• Для стола может быть только один ПК.
• ПК может быть «естественным» ключом, состоящим из одной (или более) колонок, которые «естественно» работают.
• Если у вас нет «естественного» выбора, используйте id INT UNSIGNED NOT NULL AUTO_INCREMENT.
• ПК и данные хранятся в одном и том же формате. (На самом деле B + Дерево.) Это приводит к тому, что «ПК кластер с данными».

Реальный вопрос заключается не в том, что-то кластерно, а в том, что оно кэшируется в ОЗУ. (Помните 10x RoT.)

• Если таблица небольшая, она останется в кеше (как только все ее блоки будут затронуты), следовательно, избегайте попадания дисков.
• Если какое-то подмножество огромной таблицы «горячее», оно будет оставаться в кеше.
• Если вы должны получить доступ к огромной таблице «случайно», вы будете страдать от замедления из-за большого количества обращений к диску. (Это происходит при использовании UUID, в PRIMARY KEYили другого типа INDEX.)

Как база данных решить, когда для обработки данных в оперативной памяти, а когда нет?

Это тоже «неправильно». Вся обработка выполняется в памяти. Поэтапно фрагменты таблиц и индексов перемещаются в/из buffer_pool. Блок (в InnoDB) составляет 16 КБ. И buffer_pool - это «кеш» таких блоков.

SELECT * FROM Employee; 

Простой, но дорого. Он функционирует таким образом:

1. Таблица «Открыть» Employee (если еще не открыта - другой «кеш» обрабатывает это).
2. Перейти к началу таблицы. Это включает в себя сверление левой стороны БТР PK на первый листовой узел (блок). И вытащите его в buffer_pool, если он еще не кэширован.
3. Прочитать строку - это будет в этом листовом узле.
4. Прочтите следующую строку - это возможно в том же блоке. Если нет, получите «следующий» блок (при необходимости прочитайте с диска).
5. Повторите шаг 4 до завершения таблицы.

Все становится более интересным, если у вас есть статья WHERE. И тогда это зависит от того, вовлечен ли ПК или какой-то другой INDEX.

И т.д. и т.д.