не была такой сильной, если зарезервировать условно 20-30%, то это лучшее чем у тебя места нет вообще и он сразу тебе страницу на две поделит, по сути сделав сразу в ней 50% фрагментацию при первом же апдейте при котором не сможет изменить в рамках текущей страницы
Уменьшение фактора приведет к давлению на память, повышению I/O, длительности бекапов, не говоря уж про размер на диске
Каждый пункт спорный. ИО может существенно уменьшиться за счёт уменьшения page split, а из-за отсутствия или сильного снижения page split и все остальные "аргументы" могут тоже сыграть как раз в мою сторону
Поднять тот же объем данных в разреженных страницах потребует больше памяти. И так далее.
Ну так, а я про что. В первый день пока page split было мало у него твой вариант выигрышный, а остальные шесть дней уже мой. Но это конечно я из воздуха взял и придумал пример, нужно реально знать и понимать что там происходит. Мой вариант будет выигрышный если у него условно по какой то причине обновляются рандомно почти в каждой странице хотя бы одна строка, например гуидный индекс и много апдейтов. То есть при филопатор условно 80 у него будет 20% пустого места в странице, а при полном филфакторе спустя время может быть 50% и тогда и в памяти таблица будет больше и физически больше и бекап соответственно тоже. Но повторюсь тут нужно смотреть, я просто накидываю варианты и иногда филфактор если его уменьшить действительно даст выигрыш.
Да, надо знать ситуацию на месте. Автор получил непростой фронт работы для своих знаний, похоже.
Это точно, ну как минимум мне все интересно, думаю разберусь, вы вот в чате уже 2-3 раза неплохо помогли👍
Обсуждают сегодня