Сообщение Re[14]: [SQL Server] Анализ всех запросов к таблице от 30.07.2015 14:48
Изменено 30.07.2015 14:50 Somescout
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Somescout, Вы писали:
S>Это если у вас страница, куда происходит вставка, заполнена на 100%. Это же бывает достаточно редко. Точнее — мы имеем o(log(n)) операций в худшем случае.
По умолчанию fillfactor=100% и все leaf страницы полностью заполнены, а non-leaf (так и не знаю как правильно назвать это — branch, trunk?) резервируют место под одну запись.
S>Что такое "фрагментация таблицы"?
Это физическое непоследовательность страниц таблицы(индекса) и заполненность страниц. А поскольку при вставке в середину таблицы страница делится пополам, то это повышает фрагментацию. Насколько я понимаю, SQL Server использует read-ahead поэтому порядок страниц может влиять на скорость их загрузки, кроме того если индекс подошёл для index seek, там будет именно последовательное чтение страниц и любая фрагментация его замедлит.
S>Да, и почему вы думаете, что вставка "в конец" не будет првиводить к разбивке страницы? Ведь в b-tree все leaf-страницы одинаковые — что "в середине", что "с краю".
На этот вопрос уже ответили.
S>Здравствуйте, Somescout, Вы писали:
S>Это если у вас страница, куда происходит вставка, заполнена на 100%. Это же бывает достаточно редко. Точнее — мы имеем o(log(n)) операций в худшем случае.
По умолчанию fillfactor=100% и все leaf страницы полностью заполнены, а non-leaf (так и не знаю как правильно назвать это — branch, trunk?) резервируют место под одну запись.
S>Что такое "фрагментация таблицы"?
Это физическое непоследовательность страниц таблицы(индекса) и заполненность страниц. А поскольку при вставке в середину таблицы страница делится пополам, то это повышает фрагментацию. Насколько я понимаю, SQL Server использует read-ahead поэтому порядок страниц может влиять на скорость их загрузки, кроме того если индекс подошёл для index seek, там будет именно последовательное чтение страниц и любая фрагментация его замедлит.
S>Да, и почему вы думаете, что вставка "в конец" не будет првиводить к разбивке страницы? Ведь в b-tree все leaf-страницы одинаковые — что "в середине", что "с краю".
На этот вопрос уже ответили.
Re[14]: [SQL Server] Анализ всех запросов к таблице
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Somescout, Вы писали:
S>Это если у вас страница, куда происходит вставка, заполнена на 100%. Это же бывает достаточно редко. Точнее — мы имеем o(log(n)) операций в худшем случае.
По умолчанию fillfactor=100% и все leaf страницы полностью заполнены, а non-leaf (так и не знаю как правильно назвать это — branch, trunk?) резервируют место под одну запись.
S>Что такое "фрагментация таблицы"?
Это физическая (гм...) непоследовательность страниц таблицы(индекса) и заполненность страниц. А поскольку при вставке в середину таблицы страница делится пополам, то это повышает фрагментацию. Насколько я понимаю, SQL Server использует read-ahead поэтому порядок страниц может влиять на скорость их загрузки, кроме того если индекс подошёл для index seek, там будет именно последовательное чтение страниц и любая фрагментация его замедлит.
S>Да, и почему вы думаете, что вставка "в конец" не будет првиводить к разбивке страницы? Ведь в b-tree все leaf-страницы одинаковые — что "в середине", что "с краю".
На этот вопрос уже ответили.
S>Здравствуйте, Somescout, Вы писали:
S>Это если у вас страница, куда происходит вставка, заполнена на 100%. Это же бывает достаточно редко. Точнее — мы имеем o(log(n)) операций в худшем случае.
По умолчанию fillfactor=100% и все leaf страницы полностью заполнены, а non-leaf (так и не знаю как правильно назвать это — branch, trunk?) резервируют место под одну запись.
S>Что такое "фрагментация таблицы"?
Это физическая (гм...) непоследовательность страниц таблицы(индекса) и заполненность страниц. А поскольку при вставке в середину таблицы страница делится пополам, то это повышает фрагментацию. Насколько я понимаю, SQL Server использует read-ahead поэтому порядок страниц может влиять на скорость их загрузки, кроме того если индекс подошёл для index seek, там будет именно последовательное чтение страниц и любая фрагментация его замедлит.
S>Да, и почему вы думаете, что вставка "в конец" не будет првиводить к разбивке страницы? Ведь в b-tree все leaf-страницы одинаковые — что "в середине", что "с краю".
На этот вопрос уже ответили.