Комментарии 3
В рамках статьи было бы интересно посмотреть на поведение SQL Server при смене типа первичного ключа на UUID, в качестве ещё одного способа ухода от конкуренции за последнюю страницу индекса.
Как можно оценить влияние латчей на вставку в конец таблицы с кластеризованным индексом?
Если изменить индекс, то какова вероятность, что проигрыш от перестроения индекса (таблицы) превысит выигрыш от снижения количества латчей?
PS Таблица 150 тыс строк, строки короткие, 40 байт в среднем, вероятность , попадания на одну (последнюю) страницу вставляемых данных сохраняется даже при изменении порядка формирования кластерного индекса.
PPS При вставке в таблицу идёт проверка условия, в ходе которого SEEK по кластерному индексу. Если его поменять, то, скорее всего, будет SCAN.
Т.е. базовый тест - 58 сек, с параметром OPTIMIZE_FOR_SEQUENTIAL_KEY = ON 55.6 сек, первичный ключ с некластерным индексом - 57.6 сек, таблицы, оптимизированные для памяти - 32.7 сек. Т.е. прирост производительности такой себе...
Мы избавились от PAGELATCH_EX, но никакой выгоды не получили.
А зачем избавлялись-то?
Можно сказать, что таблицы, оптимизированные для памяти ещё какой-то выход. Но если у вас на сервере, допустим 128 Гб RAM, а таблица, которую надо оптимизировать, где-то 500 Гб, то как-то оно, знаете, не то получается...
Избавляемся от PAGELATCH_EX в SQL Server