Estimate'ы - это ни о чём. Вы же видите, что количество чтений из родного индекса стало даже меньше, чем из ручного на прошлом скрине (ему, видимо, тоже нужен ребилд, т.к. из него читать всё равно должно быть меньше).
Плюс, вы в запросе используете локальную переменную, что тоже может оказывать влияние на estimate, попробуйте этот запрос выполнить через sp_executesql
Новый индекс уже существующего, читать меньше. Условие на равенство бессмысленно, он это знает из статистики. Поле есть в индексе - видимо оно в составе ключа кластерного индекса (или вы включили его в included).
Фрагментация может влиять на план запроса - у Пола Вайта был пример, где при сильно фрагментировааном индексе выбирался параллельный план. Но я и правда не уверен, что она может влиять на выбор индекса.
Проверьте, кстати, fill factor у обоих индексов, если он ниже у родного индекса - это тоже будет влияние на разницу в чтении.
Предполагаю, что если вы сделаете ребилд индекса, количество чтений практически сравняется. Разница должна быть около 150 тысяч - 5 байт * 210 млн строк / 8192 (размер страницы) - столько сэкономлено за счёт описанных изменений ключа индекса.
А каков процент фрагментации "родного" 1Совского индекса и средняя заполненность страницы? Не могу понять чем может быть вызвана разница в 2 миллиона чтений для индексов, единственное различие между которыми - это 5 байтовая константа в ключе.
В вашем предыдущем посте данные из родного индекса возвращались также быстро, как из нового индекса в этом, даже когда на выходе были все 210 миллионов записей.
Что вы имеете в виду под "нижние ветки индекса"? В любом случае он будет опускаться на листовой уровень, т.к. только оттуда можно получить данные, которые нужно вывести.
В частности было отмечено, что без дополнительных условий в Index seek, в поток для Megre join попадают все записи индекса и приходится указывать дополнительные фильтры для ограничения. Вопрос: почему так происходит? - остался открытым.
Пропустил тот пост, сейчас прочитал - и так происходит потому что так работает merge join. Помогите ему, вместо фильтра по дате фильтр по ИдИсхСистемы >= (выбрать мин(СвязаннаяОпИдИсхСистемы) из Врем_...), если 1С так может (не помню уже). С вашим новым индексом, да и со старым тоже - это должно работать не хуже фильтра по дате
Предполагаю, что _Fld628 входит в ключ кластерного индекса, поэтому этот индекс содержит все нужные данные, но чуть меньше в размере, вот оптимизатор его и выбрал.
Разница в скорости выполнения тоже кажется вызванной банальным кешированием.
В отместку он взламывает школьную систему и переделывает расписание так, чтоб оказаться в одном классе с Кейт.
Не смог пройти мимо. В отместку он всё-таки взламывает школьную систему и вызывает "протечку бассейна", а в класс с ней записывается для собственного удовольствия
Я правильно понимаю, что раз статья опубликована человеком с подписью "редактор Хабра" - то теперь это тематика Хабра, а не какого-нибудь VC или Пикабу?
Засовывать varchar(max) в included-колонки индекса - так себе практика.
Согласен, вроде и не утверждал обратного, хотя иногда и приходится.
Computed колонки лучше делать persisted
Можете пояснить - зачем persisted? Зачем хранить и в кластерном индексе, и в самом индексе, если они мне особо и не нужны, а только для оптимизации запроса?
computed persisted-колонку LEFT(x, 200) и индекс по ней - если реально данные не длиннее 200 символов.
Зависит от того, какая средняя длина. Я предпочитаю объявлять больше, чтобы не было спилов в tempdb, если в выборке будут слишком длинные varchar'ы.
DROP INDEX ix_ON ON smth (field2_calculated);
GO
ALTER TABLE smth
DROP COLUMN field2_calculated;
GO
ALTER TABLE smth
ADD field2_calculated AS LEFT(field2, 200) PERSISTED;
GO
CREATE INDEX ix_ON ON smth (field2_calculated);
GO
Msg 1919, Level 16, State 1, Line 18 Column 'field2_calculated' in table 'smth' is of a type that is invalid for use as a key column in an index.
Явно приводить тип всё равно нужно.
Не забывайте ещё, что varchar(max) хранятся в куче
Не то, чтобы я активно топил за то, чтобы не делать ребилды индексов, но всё зависит, как минимум, от объёма активной порции данных. Если он не влезает в память, то похоже, что пора идти в магазин.
Более того, MS, оказывается, переписали свой whitepapper по перестройке индексов и там прямо пишут, что зачастую положительный эффект, наблюдаемый после ребилда - это следствие обновления статистики, а не ребилда как такого.
Тот же Озар, емнип, идёт ещё дальше и пишет, что зачастую и обслуживание статистики это "оверинжениринг", а эффект проявляется из-за того, что процедурный кэш инвалидируется.
Поиск специалиста, как быть и что делать?
ого
вы-то, да, огого, ага, сразу видно
Как улучшить английский в документации
Спасибо, многое ещё предстоит осмыслить, хотел уточнить вот что:
a'an зависит исключительно от произношения? Англоязычные, обычно, произносят SQL как "сиквел" - соответственно, подходит артикль 'a'. В доках оракла встречается, например, такое: A SQL script is a set of SQL commands saved as a file in SQL Scripts.
Оба варианта, получается, допустимы?
Селективный индекс от 1С — что выберет MS SQL?
Estimate'ы - это ни о чём. Вы же видите, что количество чтений из родного индекса стало даже меньше, чем из ручного на прошлом скрине (ему, видимо, тоже нужен ребилд, т.к. из него читать всё равно должно быть меньше).
Плюс, вы в запросе используете локальную переменную, что тоже может оказывать влияние на estimate, попробуйте этот запрос выполнить через sp_executesql
Селективный индекс от 1С — что выберет MS SQL?
Новый индекс уже существующего, читать меньше. Условие на равенство бессмысленно, он это знает из статистики. Поле есть в индексе - видимо оно в составе ключа кластерного индекса (или вы включили его в included).
Фрагментация может влиять на план запроса - у Пола Вайта был пример, где при сильно фрагментировааном индексе выбирался параллельный план. Но я и правда не уверен, что она может влиять на выбор индекса.
Проверьте, кстати, fill factor у обоих индексов, если он ниже у родного индекса - это тоже будет влияние на разницу в чтении.
Селективный индекс от 1С — что выберет MS SQL?
Предполагаю, что если вы сделаете ребилд индекса, количество чтений практически сравняется. Разница должна быть около 150 тысяч - 5 байт * 210 млн строк / 8192 (размер страницы) - столько сэкономлено за счёт описанных изменений ключа индекса.
Селективный индекс от 1С — что выберет MS SQL?
А каков процент фрагментации "родного" 1Совского индекса и средняя заполненность страницы? Не могу понять чем может быть вызвана разница в 2 миллиона чтений для индексов, единственное различие между которыми - это 5 байтовая константа в ключе.
В вашем предыдущем посте данные из родного индекса возвращались также быстро, как из нового индекса в этом, даже когда на выходе были все 210 миллионов записей.
Селективный индекс от 1С — что выберет MS SQL?
Покажите, пожалуйста, вывод set statistics io on для обоих запросов.
Кажется, что убрав одно поле из индекса, вы выиграли мегабайт 350 на 70 млн записей - этим не может объясняться разница в скорости выполнения
Селективный индекс от 1С — что выберет MS SQL?
Что вы имеете в виду под "нижние ветки индекса"? В любом случае он будет опускаться на листовой уровень, т.к. только оттуда можно получить данные, которые нужно вывести.
Селективный индекс от 1С — что выберет MS SQL?
Пропустил тот пост, сейчас прочитал - и так происходит потому что так работает merge join. Помогите ему, вместо фильтра по дате фильтр по ИдИсхСистемы >= (выбрать мин(СвязаннаяОпИдИсхСистемы) из Врем_...), если 1С так может (не помню уже). С вашим новым индексом, да и со старым тоже - это должно работать не хуже фильтра по дате
Селективный индекс от 1С — что выберет MS SQL?
Предполагаю, что _Fld628 входит в ключ кластерного индекса, поэтому этот индекс содержит все нужные данные, но чуть меньше в размере, вот оптимизатор его и выбрал.
Разница в скорости выполнения тоже кажется вызванной банальным кешированием.
С чем кушать Irregular Selectivity в MSSQL и не только
А почему не использовать sp_executesql? Проблему с SQL Injection он по крайней мере решит.
Ретроноутбуки в фильме «Хакеры»
Ага, именно поэтому на следующий день устраивает скандал из-за того, что видит, что он компьютер к сети подключил
Ретроноутбуки в фильме «Хакеры»
Не смог пройти мимо. В отместку он всё-таки взламывает школьную систему и вызывает "протечку бассейна", а в класс с ней записывается для собственного удовольствия
Крупные маркетплейсы задерживают доставку товаров россиянам
Я правильно понимаю, что раз статья опубликована человеком с подписью "редактор Хабра" - то теперь это тематика Хабра, а не какого-нибудь VC или Пикабу?
Нано-статья о том, как я в SAS NULL-ключи джойнил
Логика не двоичная используется с null.
В else "идёт" то, что не true. unknown - не true, поэтому попадает в else.
Нано-статья о том, как я в SAS NULL-ключи джойнил
Если не знаешь, что операции сравнения с null возвращают unknown, который не true, и не false, то да, сплошное удивление.
Восстановление удаленных строк в SQLite
Спасибо за статью! Не пользуюсь SQLite, но про внутренности БД всегда интересно читать)
Computed Columns и nvarchar(max)
Согласен, вроде и не утверждал обратного, хотя иногда и приходится.
Можете пояснить - зачем persisted? Зачем хранить и в кластерном индексе, и в самом индексе, если они мне особо и не нужны, а только для оптимизации запроса?
Зависит от того, какая средняя длина. Я предпочитаю объявлять больше, чтобы не было спилов в tempdb, если в выборке будут слишком длинные varchar'ы.
Явно приводить тип всё равно нужно.
зависит от реальной длины строки
Computed Columns и nvarchar(max)
Я имена вычисляемых столбцов вообще нигде по тексту не использую - только их определения.
Ваш скрипт, обслуживающий индексы, измеряет не то, что надо
Не то, чтобы я активно топил за то, чтобы не делать ребилды индексов, но всё зависит, как минимум, от объёма активной порции данных. Если он не влезает в память, то похоже, что пора идти в магазин.
Более того, MS, оказывается, переписали свой whitepapper по перестройке индексов и там прямо пишут, что зачастую положительный эффект, наблюдаемый после ребилда - это следствие обновления статистики, а не ребилда как такого.
Тот же Озар, емнип, идёт ещё дальше и пишет, что зачастую и обслуживание статистики это "оверинжениринг", а эффект проявляется из-за того, что процедурный кэш инвалидируется.