При чтении с диска производительность точно (на самом деле уже не точно) упадёт, и не факт, что снижение производительности при чтении фрагментированного индекса будет заметно меньше, чем при чтении нефрагментированного. А если данные уже в памяти - будет ли разница?
Разница может быть заметна в случае, если на страницах много свободного места, но это обычно не то, что понимают под фрагментацией. В статье тоже акцент на порядке страниц, а не их содержимом.
В какой ситуации фрагментация индекса повлияет на этот запрос? Насколько сильно?
SELECT * FROM MyTable WHERE ID = 12345
В случае, когда ID не уникальны? В случае, когда было много удалений и в индексе "образовался" "лишний" уровень?
Вообще, было бы здорово, если бы в примерах были не просто примеры запросов, а рельная статистика выполнения - с фрагментированным индексом и с дефрагментированным.
как предлагаете аттестовывать специалистов по ним?
Если вы прочтёте мой комментарий, то увидите, что я ничего не предлагаю. Всего лишь говорю, что ваше сравнение оценки программистов с методами нацистов - это абсурд.
Сертификации придумали не вчера, наверное, у любого крупного вендора этих сертификаций навалом.
Я абсолютно не сторонник "проф стандартов", но ваше утверждение (предположение?) - это абсурд. Экзамены в школе и ВУЗе ничего не напоминают? Разряды/категории у рабочих профессий (сварщики, электрики)?
with x (id, smth) as (select 1, 'smth' union all select 2, 'smth else' union all select 3, 'anthr')
, y (id) as (select 1 union all select 2 union all select 1)
select *
from x
where id in (select id from y);
Статья в блоге банка, значит, видимо, банк разделяет описанные принципы ведения переговоров. Это, кстати, вполне согласуется с тем, что Альфа - это пока единственный банк, в котором менеджер мне соврал в ответ на прямой вопрос.
Действительно, как правило схема на PROD стабильна, за исключением релизов. Но увы, есть системы, где это не так.
Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.
С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.
Это перевод статьи (которой уже больше 10 лет к тому же), поэтому добавлять что-то сюда считаю неправильным. Но вы вполне можете сами сделать и опубликовать расширенную версию :)
Следующим шагом, видимо, будет выход на рынок с "межоператорным шлюзом"?
Вообще, "шина данных" для ЭДО кажется хорошей идеей, даже для не-холдингов, если она берёт на себя работу со множеством операторов, потому что держать зоопарк коннекторов - это и правда боль. И делигировать эту боль кому-то было бы очень приятно:)
Кажется, что к выводам неплохо было бы добавить и регулярные проверки целостности. Старый полный бэкап + цепочка бэкапов ЖТ (при своевременном обнаружении) могли бы полностью решить проблему в примере 4.
Truncate– это команда DDL, она используется для удаления всех строк из таблицы и освобождения пространства, содержащего таблицу. Его нельзя откатить назад.
Можно откатить в MS SQL, PostgreSQL и, наверняка, в подавляющем большинстве РСУБД. В каких именно нельзя?
Drop– это команда DDL, она удаляет полные данные вместе со структурой таблицы (в отличие от команды truncate, которая удаляет только строки). Все строки, индексы и привилегии таблиц также будут удалены.
А Drop можно откатить? А в каких СУБД? А есть СУБД, где можно откатить Drop, но нельзя Truncate? Почему-то не указано...
А почему в обзоре pg_trgm индексов нигде не написано, что и обычные like/ilike он очень даже весомо ускоряет? Я практически уверен, что в 99% случаев их используют именно для ускорения запросов с like/ilke.
И в контексте использования для ускорения с like'ми было бы интересно узнать про выбор типа индекса gin/gist - в каком случае какой больше подходит.
Я сейчас ещё и на скриншоте пытался разницу найти (в тесте тоже не угадал), и понял, что оба синтаксически некорректные - в таблицах и cte remains_id, в условиях соединения - remainsid
TRUNCATE – это крайне простая и быстрая операция, по ней нельзя сделать rollback или наложить условия по столбцам. А потому, она выполняется мгновенно.
Какая интересная информация про ролбэк. Т.е. получается, что в результате выполнения этого:
create table #t1 (id int);
insert into #t1 (id) values (1);
select * from #t1;
begin tran;
truncate table #t1;
rollback tran;
select * from #t1;
я ну никак не мог получить это:
чудеса
?
Что касается "простой" операции - нужно уточнять, что это "простая" DDL-операция, которая накладывает SCH-M блокировку (которая не совместима ни с одной другой, даже SCH-S, которую накладывают запросы с NOLOCK-хинтом) на всё время выполнения, что приводит к тому, что ни одна другая сессия не может обратиться к таблице, пока операция не завершится. В случае локальных временных таблиц - это не беда, но вы ведь и не только про них пишете.
Не включено ли у вас (ваших клиентов) MEMORY_OPTIMIZED TEMPDB_METADATA?
в общем случае, да, прироста производительности от разделения не замечу, но речь шла о том, что бывают ситуации, когда эта техника допустима и может быть полезна
что касается заметности влияния индексов, испытываю жгучее желание тоже броситься в частности и потыкать в очевидно медленные вещи типа gin в pg, но в общем случае, при разумном подходе к индексированию - спорить не буду
ну и я видел красивую таблицу со 170 столбцами и 90 индексами (не в хранилище) - это относительно того, что я увижу, или не увижу
Есть примеры с замерами?
При чтении с диска производительность точно (на самом деле уже не точно) упадёт, и не факт, что снижение производительности при чтении фрагментированного индекса будет заметно меньше, чем при чтении нефрагментированного. А если данные уже в памяти - будет ли разница?
Разница может быть заметна в случае, если на страницах много свободного места, но это обычно не то, что понимают под фрагментацией. В статье тоже акцент на порядке страниц, а не их содержимом.
В какой ситуации фрагментация индекса повлияет на этот запрос? Насколько сильно?
В случае, когда ID не уникальны? В случае, когда было много удалений и в индексе "образовался" "лишний" уровень?
Вообще, было бы здорово, если бы в примерах были не просто примеры запросов, а рельная статистика выполнения - с фрагментированным индексом и с дефрагментированным.
Если вы прочтёте мой комментарий, то увидите, что я ничего не предлагаю. Всего лишь говорю, что ваше сравнение оценки программистов с методами нацистов - это абсурд.
Сертификации придумали не вчера, наверное, у любого крупного вендора этих сертификаций навалом.
Я абсолютно не сторонник "проф стандартов", но ваше утверждение (предположение?) - это абсурд. Экзамены в школе и ВУЗе ничего не напоминают? Разряды/категории у рабочих профессий (сварщики, электрики)?
Зачем там вообще distinct, в любом месте?
И зачем вообще вариант с IN, если есть с EXISTS.
Статья в блоге банка, значит, видимо, банк разделяет описанные принципы ведения переговоров. Это, кстати, вполне согласуется с тем, что Альфа - это пока единственный банк, в котором менеджер мне соврал в ответ на прямой вопрос.
На этот вопрос вы не ответили. Почему бы не использовать lateral?
Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.
С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.
т.е. выражение вида where not (smth = null) даст true (будет истинным)?
Это перевод статьи (которой уже больше 10 лет к тому же), поэтому добавлять что-то сюда считаю неправильным. Но вы вполне можете сами сделать и опубликовать расширенную версию :)
Следующим шагом, видимо, будет выход на рынок с "межоператорным шлюзом"?
Вообще, "шина данных" для ЭДО кажется хорошей идеей, даже для не-холдингов, если она берёт на себя работу со множеством операторов, потому что держать зоопарк коннекторов - это и правда боль. И делигировать эту боль кому-то было бы очень приятно:)
Спасибо за пост.
Кажется, что к выводам неплохо было бы добавить и регулярные проверки целостности. Старый полный бэкап + цепочка бэкапов ЖТ (при своевременном обнаружении) могли бы полностью решить проблему в примере 4.
Можно откатить в MS SQL, PostgreSQL и, наверняка, в подавляющем большинстве РСУБД. В каких именно нельзя?
А Drop можно откатить? А в каких СУБД? А есть СУБД, где можно откатить Drop, но нельзя Truncate? Почему-то не указано...
А почему в обзоре pg_trgm индексов нигде не написано, что и обычные like/ilike он очень даже весомо ускоряет? Я практически уверен, что в 99% случаев их используют именно для ускорения запросов с like/ilke.
И в контексте использования для ускорения с like'ми было бы интересно узнать про выбор типа индекса gin/gist - в каком случае какой больше подходит.
На скрине в моём комментарии видно, что distinct там не было
345? RLY?
Я сейчас ещё и на скриншоте пытался разницу найти (в тесте тоже не угадал), и понял, что оба синтаксически некорректные - в таблицах и cte remains_id, в условиях соединения - remainsid
Нужна пояснительная бригада
В какой СУБД ответ, который считается правильным, вернётся приведённым запросом?
Какая интересная информация про ролбэк. Т.е. получается, что в результате выполнения этого:
я ну никак не мог получить это:
?
Что касается "простой" операции - нужно уточнять, что это "простая" DDL-операция, которая накладывает SCH-M блокировку (которая не совместима ни с одной другой, даже SCH-S, которую накладывают запросы с NOLOCK-хинтом) на всё время выполнения, что приводит к тому, что ни одна другая сессия не может обратиться к таблице, пока операция не завершится. В случае локальных временных таблиц - это не беда, но вы ведь и не только про них пишете.
Не включено ли у вас (ваших клиентов) MEMORY_OPTIMIZED TEMPDB_METADATA?
в общем случае, да, прироста производительности от разделения не замечу, но речь шла о том, что бывают ситуации, когда эта техника допустима и может быть полезна
что касается заметности влияния индексов, испытываю жгучее желание тоже броситься в частности и потыкать в очевидно медленные вещи типа gin в pg, но в общем случае, при разумном подходе к индексированию - спорить не буду
ну и я видел красивую таблицу со 170 столбцами и 90 индексами (не в хранилище) - это относительно того, что я увижу, или не увижу