Вы смотрите на показатели разделения страниц в инструменте мониторинга или Perfmon, и вы слышали, что разделения страниц — это плохо, поэтому вы снижаете коэффициент заполнения, ожидая, что количество разделений страниц уменьшится.
Вы отслеживаете не тот показатель.
Чтобы доказать это, давайте проверим счётчик разделений страниц, добавим 10 000 страниц в таблицу, а затем проверим его снова:
DECLARE @StartingPageSplits BIGINT = (SELECT cntr_value FROM sys.dm_os_performance_counters
WHERE counter_name LIKE 'Page Splits/sec%');
DROP TABLE IF EXISTS dbo.PageSplitTest;
CREATE TABLE dbo.PageSplitTest
(Id INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
BigData CHAR(8000));
INSERT INTO dbo.PageSplitTest(BigData)
SELECT 'BigData'
FROM generate_series(1, 10000);
SELECT cntr_value - @StartingPageSplits AS PageSplits
FROM sys.dm_os_performance_counters
WHERE counter_name LIKE 'Page Splits/sec%';
Я намеренно спроектировал там очень особенную таблицу: каждая строка сама по себе занимает около 8 000 байт. Ни одна строка не может делить страницу с другой строкой. Каждой строке нужна собственная 8-килобайтная страница. Здесь просто не существует такого понятия, как разделение этой страницы для перемещения строк. Каждая новая строка получает собственную страницу в конце объекта, потому что мы используем кластерный первичный ключ на основе identity. Новые строки добавляются в конец.
Так почему же этот счётчик показывает более 10 000 разделений страниц каждый раз, когда вы запускаете тест?
Глупый счётчик Page Splits включает выделение новых страниц.
Я не понимаю, почему этот счётчик Perfmon когда-либо был построен таким образом, но он всегда был таким. Всякий раз, когда для таблицы добавляется новая страница, в этом счётчике это называется «разделением страниц», даже когда ничего не разделяется. Так что просто выполняя вставки, вы получите разделения страниц, независимо от того, как настроен ваш индекс или коэффициент заполнения.
Примечание: я создал приведённую выше анимацию с помощью Claude Code, но всё остальное в этом посте — полностью моё, включая T-SQL.
Так почему же так много людей введены в заблуждение относительно снижения коэффициента заполнения ради уменьшения разделений страниц? Потому что они используют Copilot, я полагаю. Я спросил SSMS Copilot: «В SQL Server снизит ли уменьшение коэффициента заполнения показатели счётчика Page Splits/sec в Perfmon при той же рабочей нагрузке?»
SSMS Copilot:
В SQL Server снизит ли уменьшение коэффициента заполнения показатели счётчика Page Splits/sec в Perfmon при той же рабочей нагрузке?
SSMS
0 ссылок
Думал 33 мс
Да — обычно, при одной и той же рабочей нагрузке, снижение FILLFACTOR уменьшит количество Page Splits/sec, вызванных заполнением страниц индекса.
| Аспект | Что происходит, когда коэффициент заполнения ниже |
|---|---|
| Свободное место на листовой странице | После перестроения/реорганизации на каждой странице остаётся больше места |
| Случайные вставки / расширяющиеся обновления | Менее вероятно, что немедленно потребуется разделение в середине страницы |
| Счётчик Page Splits/sec | Часто уменьшается (особенно на индексах с интенсивной записью и случайными ключами) |
Однако не гарантируется, что он всегда будет падать:
| Оговорка | Почему |
|---|---|
| Область действия счётчика | Page Splits/sec включает разделения не только от одного индекса или шаблона рабочей нагрузки |
| Шаблоны последовательных вставок | Может не получить большой выгоды от более низкого коэффициента заполнения |
| Очень интенсивная запись | Свободное место может быть израсходовано быстро, разделения возвращаются |
| Компромисс | Более низкий коэффициент заполнения увеличивает размер индекса, что может повысить чтения и давление на память |
Практическое руководство
| Рекомендация | Причина |
|---|---|
| Тестируйте с базовой линией до/после | Проверьте фактическое влияние на вашу рабочую нагрузку |
| Применяйте избирательно к проблемным индексам | Избегайте ненужного раздувания всех индексов |
| Периодически пересматривайте коэффициент заполнения | Шаблоны данных меняются со временем |
Итак: снижение коэффициента заполнения — распространённый способ уменьшить разделения страниц, но настраивайте его для каждого индекса и подтверждайте измерением.
GPT-5.3-Codex
Bing тоже согласился:
Copilot Search
Влияние снижения коэффициента заполнения на Page Splits/sec
Снижение коэффициента заполнения в SQL Server может уменьшить количество разделений страниц в секунду в некоторых сценариях, но эффект сильно зависит от вашей рабочей нагрузки и от того, как вставляются или обновляются данные.
Как работает коэффициент заполнения
Коэффициент заполнения определяет процент пространства на каждой странице индекса листового уровня, заполненного данными. Значение по умолчанию 100% означает, что страницы заполнены, не оставляя свободного места для роста. Когда страница заполнена и необходимо вставить новую строку, SQL Server выполняет разделение страницы — перемещая примерно половину строк на новую страницу, чтобы освободить место. [Microsoft Learn +1]
Влияние снижения коэффициента заполнения
- Более низкий коэффициент заполнения (например, 80–90%) оставляет свободное место на каждой странице, поэтому новые строки могут быть вставлены без разделения. Это может уменьшить разделения страниц, если новые данные равномерно распределены по
ChatGPT по крайней мере упомянул, что есть подвохи, например последовательные вставки:
ChatGPT:
В SQL Server снизит ли уменьшение коэффициента заполнения показатели счётчика Page Splits/sec в Perfmon при той же рабочей нагрузке?
Да — если разделения происходят потому, что вставкам/обновлениям нужно место в середине страниц индекса, снижение коэффициента заполнения должно уменьшить счётчик SQLServer:Access Methods\Page Splits/sec для той же рабочей нагрузки, по крайней мере до тех пор, пока это зарезервированное свободное пространство не будет израсходовано.
Page Splits/sec конкретно считает разделения, вызванные переполнением страниц индекса. Снижение коэффициента заполнения оставляет свободное место на листовых страницах при построении/перестроении индекса, поэтому последующие строки часто могут поместиться без разделения страницы. Microsoft явно говорит, что более низкий/хорошо выбранный коэффициент заполнения может уменьшить разделения страниц таким образом. [Microsoft Learn +1]
Есть две важные оговорки:
- Последовательные вставки: если вы вставляете постоянно возрастающие ключи (IDENTITY, datetime и т. д.), снижение коэффициента заполнения обычно не поможет существенно. Вы постоянно заполняете самую правую страницу; пустое пространство, зарезервированное на тысячах более старых страниц, в основном тратится впустую.
- Выгода убывает: коэффициент заполнения не поддерживается непрерывно. Если вы перестроите индекс с 80%, страницы начнут с 20% пустого пространства, но SQL Server не поддерживает их на 20% пустыми. По мере заполнения этого пространства рабочей нагрузкой
Page Splits/secможет снова подняться до прежнего уровня.
ChatGPT также сослался на эту страницу документации Microsoft Learn, которая действительно говорит — без каких-либо оговорок — что Page Splits/sec — это «количество разделений страниц в секунду, возникающих в результате переполнения страниц индекса».
Вот почему так важно, сейчас больше чем когда-либо, сомневаться во всём, что не приложена демонстрация.
Иногда кажется, что треть моих учебных курсов — это просто исправление неверной информации, которую вам скормили откуда-то ещё. Это не ваша вина — ну, то есть ваша, если вы так и не попадёте на учебные курсы, хе-хе!
Комментариев нет:
Отправить комментарий