окей, есть ещё два частных случая (хотя на счёт row overflow у меня нет твёрдой уверенности, что это справедливо для всех случаев), когда при использовании списка столбцов в память поднимутся не все поля
в общем случае же, в контексте предмета обсуждения, речь о том, что может иметь смысл выносить что-то в отдельную таблицу со связью 1-1, в т.ч. для экономии памяти
Сравнение значений. Если в таблице присутствуют значения NULL, то при выполнении операции сравнения, например, WHERE column_name = NULL, результатом будет False. Вместо этого нужно использовать оператор IS NULL.
Это ("результатом будет False") неправда. результатом будет Unknown, который и не True, и не False. Если бы результатом был False, то условие вида where not (colum_name = null) возвращало бы всё, где column_name не-null, а это так не работает.
Estimate'ы - это ни о чём. Вы же видите, что количество чтений из родного индекса стало даже меньше, чем из ручного на прошлом скрине (ему, видимо, тоже нужен ребилд, т.к. из него читать всё равно должно быть меньше).
Плюс, вы в запросе используете локальную переменную, что тоже может оказывать влияние на estimate, попробуйте этот запрос выполнить через sp_executesql
Новый индекс уже существующего, читать меньше. Условие на равенство бессмысленно, он это знает из статистики. Поле есть в индексе - видимо оно в составе ключа кластерного индекса (или вы включили его в included).
Фрагментация может влиять на план запроса - у Пола Вайта был пример, где при сильно фрагментировааном индексе выбирался параллельный план. Но я и правда не уверен, что она может влиять на выбор индекса.
Проверьте, кстати, fill factor у обоих индексов, если он ниже у родного индекса - это тоже будет влияние на разницу в чтении.
Предполагаю, что если вы сделаете ребилд индекса, количество чтений практически сравняется. Разница должна быть около 150 тысяч - 5 байт * 210 млн строк / 8192 (размер страницы) - столько сэкономлено за счёт описанных изменений ключа индекса.
А каков процент фрагментации "родного" 1Совского индекса и средняя заполненность страницы? Не могу понять чем может быть вызвана разница в 2 миллиона чтений для индексов, единственное различие между которыми - это 5 байтовая константа в ключе.
В вашем предыдущем посте данные из родного индекса возвращались также быстро, как из нового индекса в этом, даже когда на выходе были все 210 миллионов записей.
Что вы имеете в виду под "нижние ветки индекса"? В любом случае он будет опускаться на листовой уровень, т.к. только оттуда можно получить данные, которые нужно вывести.
В частности было отмечено, что без дополнительных условий в Index seek, в поток для Megre join попадают все записи индекса и приходится указывать дополнительные фильтры для ограничения. Вопрос: почему так происходит? - остался открытым.
Пропустил тот пост, сейчас прочитал - и так происходит потому что так работает merge join. Помогите ему, вместо фильтра по дате фильтр по ИдИсхСистемы >= (выбрать мин(СвязаннаяОпИдИсхСистемы) из Врем_...), если 1С так может (не помню уже). С вашим новым индексом, да и со старым тоже - это должно работать не хуже фильтра по дате
Предполагаю, что _Fld628 входит в ключ кластерного индекса, поэтому этот индекс содержит все нужные данные, но чуть меньше в размере, вот оптимизатор его и выбрал.
Разница в скорости выполнения тоже кажется вызванной банальным кешированием.
В отместку он взламывает школьную систему и переделывает расписание так, чтоб оказаться в одном классе с Кейт.
Не смог пройти мимо. В отместку он всё-таки взламывает школьную систему и вызывает "протечку бассейна", а в класс с ней записывается для собственного удовольствия
Я правильно понимаю, что раз статья опубликована человеком с подписью "редактор Хабра" - то теперь это тематика Хабра, а не какого-нибудь VC или Пикабу?
прикол в том, что вы сами выдумали тейк про каждый столбец-таблица и сами его осудили
индексы на каждый чих тоже не бесплатное удовольствие
окей, есть ещё два частных случая (хотя на счёт row overflow у меня нет твёрдой уверенности, что это справедливо для всех случаев), когда при использовании списка столбцов в память поднимутся не все поля
в общем случае же, в контексте предмета обсуждения, речь о том, что может иметь смысл выносить что-то в отдельную таблицу со связью 1-1, в т.ч. для экономии памяти
если таблица не columnstore, с диска всё равно поднимутся все поля
Это ("результатом будет False") неправда. результатом будет Unknown, который и не True, и не False. Если бы результатом был False, то условие вида where not (colum_name = null) возвращало бы всё, где column_name не-null, а это так не работает.
ого
вы-то, да, огого, ага, сразу видно
Спасибо, многое ещё предстоит осмыслить, хотел уточнить вот что:
a'an зависит исключительно от произношения? Англоязычные, обычно, произносят SQL как "сиквел" - соответственно, подходит артикль 'a'. В доках оракла встречается, например, такое: A SQL script is a set of SQL commands saved as a file in SQL Scripts.
Оба варианта, получается, допустимы?
Estimate'ы - это ни о чём. Вы же видите, что количество чтений из родного индекса стало даже меньше, чем из ручного на прошлом скрине (ему, видимо, тоже нужен ребилд, т.к. из него читать всё равно должно быть меньше).
Плюс, вы в запросе используете локальную переменную, что тоже может оказывать влияние на estimate, попробуйте этот запрос выполнить через sp_executesql
Новый индекс уже существующего, читать меньше. Условие на равенство бессмысленно, он это знает из статистики. Поле есть в индексе - видимо оно в составе ключа кластерного индекса (или вы включили его в included).
Фрагментация может влиять на план запроса - у Пола Вайта был пример, где при сильно фрагментировааном индексе выбирался параллельный план. Но я и правда не уверен, что она может влиять на выбор индекса.
Проверьте, кстати, fill factor у обоих индексов, если он ниже у родного индекса - это тоже будет влияние на разницу в чтении.
Предполагаю, что если вы сделаете ребилд индекса, количество чтений практически сравняется. Разница должна быть около 150 тысяч - 5 байт * 210 млн строк / 8192 (размер страницы) - столько сэкономлено за счёт описанных изменений ключа индекса.
А каков процент фрагментации "родного" 1Совского индекса и средняя заполненность страницы? Не могу понять чем может быть вызвана разница в 2 миллиона чтений для индексов, единственное различие между которыми - это 5 байтовая константа в ключе.
В вашем предыдущем посте данные из родного индекса возвращались также быстро, как из нового индекса в этом, даже когда на выходе были все 210 миллионов записей.
Покажите, пожалуйста, вывод set statistics io on для обоих запросов.
Кажется, что убрав одно поле из индекса, вы выиграли мегабайт 350 на 70 млн записей - этим не может объясняться разница в скорости выполнения
Что вы имеете в виду под "нижние ветки индекса"? В любом случае он будет опускаться на листовой уровень, т.к. только оттуда можно получить данные, которые нужно вывести.
Пропустил тот пост, сейчас прочитал - и так происходит потому что так работает merge join. Помогите ему, вместо фильтра по дате фильтр по ИдИсхСистемы >= (выбрать мин(СвязаннаяОпИдИсхСистемы) из Врем_...), если 1С так может (не помню уже). С вашим новым индексом, да и со старым тоже - это должно работать не хуже фильтра по дате
Предполагаю, что _Fld628 входит в ключ кластерного индекса, поэтому этот индекс содержит все нужные данные, но чуть меньше в размере, вот оптимизатор его и выбрал.
Разница в скорости выполнения тоже кажется вызванной банальным кешированием.
А почему не использовать sp_executesql? Проблему с SQL Injection он по крайней мере решит.
Ага, именно поэтому на следующий день устраивает скандал из-за того, что видит, что он компьютер к сети подключил
Не смог пройти мимо. В отместку он всё-таки взламывает школьную систему и вызывает "протечку бассейна", а в класс с ней записывается для собственного удовольствия
Я правильно понимаю, что раз статья опубликована человеком с подписью "редактор Хабра" - то теперь это тематика Хабра, а не какого-нибудь VC или Пикабу?
Логика не двоичная используется с null.
В else "идёт" то, что не true. unknown - не true, поэтому попадает в else.
Если не знаешь, что операции сравнения с null возвращают unknown, который не true, и не false, то да, сплошное удивление.