NP
Кто на практике что может сказать про перф индексов в том числе кластерного на bigint и uniqueidentifier
Size: a a a
2020 May 28
K
Кто на практике что может сказать про перф индексов в том числе кластерного на bigint и uniqueidentifier
Я могу
Ша чай попью, поудобнее устроюсь и скажу
Ша чай попью, поудобнее устроюсь и скажу
K
Ночные работы, и в.ч. как раз по бигинт кластеру
K
По бигинту (июды не люблю, и, по ходу, это не только я не люблю)
В общем, первый момент
1. Поле сцука 8 байт.
2. Они производительнее индексов по дате, даже по дейттайм2(3) -6 байт. Факт.
Они производительнее индексов по варчар(8), но ! индекс по варчар(8) хорошо жмется в пределах страницы, бигинт так не жмется
В общем, первый момент
1. Поле сцука 8 байт.
2. Они производительнее индексов по дате, даже по дейттайм2(3) -6 байт. Факт.
Они производительнее индексов по варчар(8), но ! индекс по варчар(8) хорошо жмется в пределах страницы, бигинт так не жмется
K
3. У нас они есть сиквенс и айди и вот сегодня станут праймари ки кластер на секционированной таблице
K
Если это сиквенс и скуль 2019, то все, это бминго, в 2019-м уже есть оптимизация индексов для таких последовательных значений, и, по словам экспертов (по большей части правда мелкомягки) драматикали импрувят перфоманс
K
4. Если таблица секционирована именно по ключу Бигинт, то есть небольшой стрем, что при выравнивании остальных индексов они мал-мал распухнут - не забываем. поле 8 байт
K
5. если это поле вставляется не последовательно, а не пришей к пизде рукав, вразнобой типа 2,10,88,34, 54,1 - то через определенное время неизбежно придется ребилдить
K
Т.е. если с интом это придется делать попозже, то с бигинтом - пораньше
Проверено, когда внезапно выросла табла и пришлось бигинт айди делать
Проверено, когда внезапно выросла табла и пришлось бигинт айди делать
AC
Kostya
По бигинту (июды не люблю, и, по ходу, это не только я не люблю)
В общем, первый момент
1. Поле сцука 8 байт.
2. Они производительнее индексов по дате, даже по дейттайм2(3) -6 байт. Факт.
Они производительнее индексов по варчар(8), но ! индекс по варчар(8) хорошо жмется в пределах страницы, бигинт так не жмется
В общем, первый момент
1. Поле сцука 8 байт.
2. Они производительнее индексов по дате, даже по дейттайм2(3) -6 байт. Факт.
Они производительнее индексов по варчар(8), но ! индекс по варчар(8) хорошо жмется в пределах страницы, бигинт так не жмется
datetime2(3) - 7 байт
K
2 значит
AC
А индекс уникальный был по дате? Что с чем сравнивали?
K
А индекс уникальный был по дате? Что с чем сравнивали?
нет, не уникальный
сравнивали выдачу 1 записи
сравнивали выдачу 1 записи
K
с тор 1
K
диапазон тоже быстрее отрабатывал, но там уникальность по бигинту могла может быть чутка перевес создать
K
И еще момент, но его долго не тестил - если это поле включаешь в составной инлдекс, тоже побыстрее даты идет
K
может и показалось
AC
Просто если кластерный неуникальный, то там ещё по идее +4 байта на uniquifier
K
Просто если кластерный неуникальный, то там ещё по идее +4 байта на uniquifier
до этого тест чище был
вообще кластера не было
а был бигинт + уникальность по нему
вообще кластера не было
а был бигинт + уникальность по нему
K
а сейчас будет кластер но предвариательное уже показало что еще быстрее все