
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
16.06.2014, 16:48:23
|
|||
|---|---|---|---|
Мультиверсионность индексов в INNODB |
|||
|
#18+
на всякий случай дублирую сюда ответ разработчиков. вопрос был "как мы имеем покрывающие индексы не имея в индексах информации о версиях?" Alexey KopytovВопрос действительно интересный, потому что какого-то короткого ответа на него не существует. Более того, мне пришлось смотреть в код, потому что внятного ответа на вопрос не даёт ни документация, ни блоги разработчиков. Из спортивного интереса хочу провести опрос среди консультантов Перконы. ;) Итак, что происходит в случае поиска по вторичному индексу в InnoDB: - каждая транзакция имеет атрибут max_trx_id -- максимальный ID уже закомиченных транзакций на момент старта самой транзакции. То есть, каждая транзакция гарантировано видит все изменения, сделанные транзакциями с id <= max_trx_id - каждая страница (включая страницы вторичного индекса) тоже имеет поле max_trx_id. Это, соответственно, ID последней транзакции, которая обновляла эту страницу; - при поиске / сканировании InnoDB сначала находит значиние ключа в текущей версии страницы (так, как будто никакой мультиверсионности нет) - после этого InnoDB смотрит, можно ли этому значению доверять: если max_trx_id на странице меньше соответсвующего атрибута транзакции, то ответ "да", иначе ответ "нет". - если ответ "да", возвращаем результат - если ответ "нет", мы всё же пытаемся проверить значение с помощью Index Condition Pushdown. Если ICP говорит, что найденная запись вторичного ключа всё равно не удовлетворяет pushed down условию, то значение игнорируется - в последнем случае, мы делаем поиск по первичному ключу, находим соответствующую полную запись, восстанавливаем нужную версию записи по UNDO log (или убеждаемся, что такой записи на момент старта текущей транзакции не было). Всё это делается "под капотом" InnoDB, то есть сам сервер не в курсе. Он может выполнять запрос по "покрывающему индексу", как ему кажется. Вся разница в том, что если бы ещё и индекс был не покрывающем, сервер делал бы ещё запрос на поиск по первичному ключу в InnoDB, чтобы получить остальные поля. Трудно односложно ответить на вопрос: "поддерживает ли InnoDB мультиверсионность для вторичных ключей?". Да, поддерживает, НО может для этой поддержки делать поиск по первичному ключу в некоторых случаях, в зависимости от того, когда обновлялась последний раз страница и используется ли Index Condition Pushdown. Поддержка покрывающих индексов в оптимизаторе от этого никак не страдает -- покрывающие индексы остаются покрывающими с точки зрения сервера. Надеюсь, не очень запутанно объяснил. /Алексей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=47&mobile=1&tid=1834667]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
104ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 404ms |

| 0 / 0 |
