как указатель в индексе MySql (дерево B +) остается действительным, в то время как указатель может сохраняться на диске и возвращаться на другую страницу?

Question

Я знал, что индекс дерева B + в движке Innode MySql хранится в страницах (страницы управляются MySql). Один узел находится на одной странице. И я знал, что MySql помещает некоторые узлы на диск, когда свободных страниц недостаточно, а затем иногда читает узлы обратно с диска, снова помещая их на некоторые свободные страницы. Итак, вот мой вопрос:

1, ЕСЛИ один узел имеет указатель на один из его дочерних узлов, в то время как дочерний узел теперь находится на странице 1. Например, указатель на дочерний узел - 0x7c11111111111111 (потому что адрес дочернего узла - 0x7c11111111111111).

2, тогда свободных страниц недостаточно, поэтому MySql помещает дочерний узел на диск и иногда снова считывает диск обратно из дочернего узла на одну страницу, например, на страницу 2 (поскольку страница 2 теперь свободна).

3, по моему мнению, адрес дочернего узла изменился (опять не 0x7c11111111111111, потому что узел находится на странице 2, а не на странице 1 снова). Так, как родительский узел все еще может найти дочерний узел, в то время как указатель все еще 0x7c11111111111111?

Answer 1

Каждый узел дерева B + InnoDB (либо данные, либо индекс) постоянно нумеруется «номером блока», который, по сути, является его местоположением в файле (.ibd или ibdata1). Когда узел выбирается в buffer_pool, он помещается туда, где есть место для него. Механизм поиска отображает номер блока на адрес RAM в buffer_pool.

Если этот блок будет изменен, он в конечном итоге будет записан на диск в том же месте файла.

Если этот блок разделен (например, из-за INSERTing слишком большого количества строк в нем), тогда другой блок извлекается из свободного списка для разделения. Из-за + в «B + Tree» это означает, что необходимо обновить пару ссылок, чтобы вставить этот новый блок в последовательную цепочку блоков B + Tree. Все это делается, пока блоки находятся в buffer_pool. И родитель этих двух узлов нуждается в обновлении и, возможно, также в разделении.

Блок, измененный по любой причине, помечается как «грязный». Фоновая задача позаботится о том, чтобы в конечном итоге записать грязные блоки на диск.

Блоки никогда (кроме совпадений) не нумеруются последовательно 1,2,3 и т. Д. «Следующий» блок может иметь любое «число». Кроме того, числа не обязательно являются монотонными, поскольку «свободный» блок для удовлетворения «разбиению» может иметь меньшее число.

Все вышеперечисленное является более сложным из-за «табличных пространств», buffer_pool_instances, расширений ibdata1, отмены, повтора, цепочки истории и других вещей.