Да

Ну ок ок

К тому что некоторые всю жизнь там что-то дефрагментируют, и все без толку.

Но ладно, ты можешь попробовать

Нет! ;)
https://www.brentozar.com/archive/2012/08/sql-server-index-fragmentation/

А как же это холивар про фрагментацию индексов и без меня?
Хоть про обновление статистистики дождитесь пожалуйста.

Приветствую всех!

Подскажите пожалуйста, как мне выбрать строку с двумя известными значениями?

Индексы были фрагментирован почти на 100% в большинстве таблиц. Предыдущая команда за ними не следила особо похоже. Индексы перестроил, но конечно надо дождаться отработки джобы чтобы говорить о победе

Я слежу за тем чтобы индексы на моих таблицах никто не перестраивал и не дефрагментировал.
У меня базенка на 5,6 ТБ с неслабой нагрузкой. Я доктор зло?

И мне нравится ссылка выше на Озарта, уж он познал боль работы с индексами не по слухам.

Хорошо, тогда чем как не индексами можно объяснить такое поведение, как - select отрабатывает за 5 мин. insert from select + update from select отработало сегодня ночью за 12 часов. Я не очень силён в индексах, но знаю что они могут сильно замедлять обновление. Там же ему при обновлении нужно пробегаться по дереву, лезть в листья... если оно фрагментировано, то количество чтений и записей вырастает

Внешние ключи ещё могут влиять, на каждую вставку/обновление идёт проверка.

Мне представляет что начинать стоит не с таблицы, индекса, а с плана выполнения вопроса. Благо очень легко определить что же такого тяжелого в этом плане есть.
Затем по очереди смотреть объекты которые в этом запросе используются и смотреть не только на индексы, но и на статистику этих объектов (авто/асинхронная) и безусловно смотреть на сам запрос.

Даже если что-то на самом деле улучшится (а для этого нужно измерять до и после, а не ориентироваться на впечатления!), из этого не следует, что "дефрагментация" чем-то помогла (это обычная ошибка "после этого — значит, вследствие этого").
Rebuild и reorganize приводят ко многим последствиям (в том числе и негативным!), часть из которых (например, только положительные) можно получить и другими способами, если нужно.

В общем, мой (как и Brent-а в этой ссылке) посыл в том, что "дефрагментация" почти никогда не помогает сама по себе (но зачастую приводит к [существенным] негативным последствиям), но "выводы" по вышеописанной "логике" приводят к распространению идиотского мифа о том, что дефрагментация — это необходимо и полезно; клиенты начинают её требовать, и затем становится трудно объяснять, что она-то и привела к тем проблемам, с которыми мы разбираемся прямо сейчас. ;(

Ключи, причем статистику обновления и ПК и ФК рассматривать на том же уровне что таблицу и индекс, так как они участвуют в плане с тем же весом.

> но знаю что они могут сильно замедлять обновление.

Да. Необходимость изменения структуры индекса замедляет обновление (по сравнению с отсутствием этого индекса / такой необходимости).

> если оно фрагментировано, то количество чтений и записей вырастает

Ну конечно, нет. Наоборот, может существенно уменьшаться. Знаете, как устроено b-tree? Так вот "плотная" упаковка приводит к split-ам, а вот просто вставка в листы — нет.

Коллеги, спасибо за ответы. Правильно понимаю, что обновление статистики может перестроить план запроса под более свежую схему?

Да, зачастую так и бывает. Тем более, если у вас база не обслуживалась, то некоторая статистика может очень сильно устареть.

Подскажите что сделать:
Приходят запросы от пользователей
Запись идёт в бд(MySQL) в 3 разные таблицы
Как объединить все в одну
Чтобы совпадали данные

С помощью оператора union all или union, как вариант