|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Дилетантский вопрос. Создаем временную таблицу на которую нужен кластерный индекс, записей будет пусть 50к По производительности лучше кластерный индекс до вставки создать или после? По моему мнению быстрее получится сначала создать, а потом вставить данные. Т.к. данные уже будут вставляться в нужном порядке, но нужна будет предварительная сортировка. Если иначе, то будет создана куча, которую потом также нужно будет сортировать и перестраивать данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 11:06 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Kolu4ka, Вставка в кучу может быть быстрее, если соблюсти условия минимального логирования (см. https://docs.microsoft.com/en-US/sql/t-sql/statements/insert-transact-sql?view=sql-server-ver15#using-insert-intoselect-to-bulk-import-data-with-minimal-logging-and-parallelism и https://docs.microsoft.com/en-US/sql/relational-databases/import-export/prerequisites-for-minimal-logging-in-bulk-import?view=sql-server-ver15 . Первая вставка в пустцю таблицу с кластерным индексом тоже будет минимально логироваться, но следующие итерации будут с полным логированием. Ну и такой важный бонус: если создавать индекс по существующим данным, он вместе с собой соберёт актуальную статистику. А если сначала создать индекс, а потом наливать данные, придётся уповать на автообновление статистик. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 11:22 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Kolu4ka, сортировка будет использована при вставке в пустую таблицу, даже если Вы ее не укажете явно, то есть этого не избежать. Дважды заполнять таблицу я не вижу смысла - при вставке и при создании кластерного индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 11:33 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
0wl, спасибо, читала еще топик https://www.sql.ru/forum/1320821/insert-with-tablock Конечный вывод делаю для себя такой, если в свою таблицу я заливаю все данные одним insert(одна интерация) и дальнейшие операции с таблицей будут только по кластерному полю, то имеет смысл создавать кластерный индекс сначала и использовать tablock при вставке. Да, еще вопросик, если при работе с такой таблицей мне понадобится удалять записи, правильнее сделать поле для признака удаления и update его, что бы таблица не перестраивалась? Или можно сразу удалять? К примеру для удаления 10 из 50 тыс. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 12:35 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Kolu4ka Да, еще вопросик, если при работе с такой таблицей мне понадобится удалять записи, правильнее сделать поле для признака удаления и update его, что бы таблица не перестраивалась? Или можно сразу удалять? К примеру для удаления 10 из 50 тыс. Правильнее - не вставлять ненужное. Двойной кэшбэк. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 12:50 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Kolu4ka Конечный вывод делаю для себя такой, если в свою таблицу я заливаю все данные одним insert(одна интерация) и дальнейшие операции с таблицей будут только по кластерному полю, то имеет смысл создавать кластерный индекс сначала и использовать tablock при вставке. Вот скока не мучился - так и не пришел к однозначному выводу "что быстрее" Код: sql 1. 2.
Код: sql 1. 2.
Но второй вариант сильно проигрывает по необходимости явно писать Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 12:56 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Kolu4ka Дилетантский вопрос. Создаем временную таблицу на которую нужен кластерный индекс, записей будет пусть 50к По производительности лучше кластерный индекс до вставки создать или после? По моему мнению быстрее получится сначала создать, а потом вставить данные. Т.к. данные уже будут вставляться в нужном порядке, но нужна будет предварительная сортировка. Если иначе, то будет создана куча, которую потом также нужно будет сортировать и перестраивать данные. На этот вопрос есть только один строгий ответ: смотрите время выполнения в том и другом случаях и сравнивайте планы выполнения. Что же касается рекомендаций вообще, то имейте ввиду, что создание индекса на временной таблице - это DDL операция. Из-за которой меняется схема данных. И код процедуры будет перекомпилирован. Это не всегда плохо, но надо иметь это в виду. Поэтому если вы хотите избежать перекомпиляций, делайте объявление индекса внутри объявления временной таблицы, а не отдельной командой. И само собой в самом начале процедуры. Если вы не уверены на счёт перекомпиляций, то делайте так, чтобы их избежать, всегда. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 12:57 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
aleks222 Kolu4ka Конечный вывод делаю для себя такой, если в свою таблицу я заливаю все данные одним insert(одна интерация) и дальнейшие операции с таблицей будут только по кластерному полю, то имеет смысл создавать кластерный индекс сначала и использовать tablock при вставке. Вот скока не мучился - так и не пришел к однозначному выводу "что быстрее" Код: sql 1. 2.
Код: sql 1. 2.
Но второй вариант сильно проигрывает по необходимости явно писать Код: sql 1.
В серьёзных компаниях такой вопрос даже не стоит. Все поля всегда должны быть описаны явно. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 12:59 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Алекс прав, особой разницы в производительности нет, но пространства в базе, я предполагаю, будет затрачено больше в случае "перелива". Если добавление записей происходит не одной командой, то выгоднее по времени будет вариант с финальным созданием кластерного индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 13:04 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Kolu4ka Да, еще вопросик, если при работе с такой таблицей мне понадобится удалять записи, правильнее сделать поле для признака удаления и update его, что бы таблица не перестраивалась? Или можно сразу удалять? К примеру для удаления 10 из 50 тыс. Это зависит от многих обстоятельств. От размера таблицы и загрузки сервера например. Если у вас многие миллионы записей, то было бы неплохо такую таблицу уменьшить. Если очистка памяти не является необходимой, то лучше не удалять, а делать дополнительное поле и по нему индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 13:06 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Владислав Колосов Алекс прав, особой разницы в производительности нет, но пространства в базе, я предполагаю, будет затрачено больше в случае "перелива". Если добавление записей происходит не одной командой, то выгоднее по времени будет вариант с финальным созданием кластерного индекса. Одно мне тут непонятно: а зачем тогда создавать именно кластерный индекс? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 13:08 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Кесарь В серьёзных компаниях такой вопрос даже не стоит. Все поля всегда должны быть описаны явно. Удивительное дело. А шо select ... into #t "неописывает поля"? Вроде все однозначно описывается из исходных таблиц. Более того, если базовые таблицы переопределены - не надо метаться по процедурам, правя определения времянок. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 13:25 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Кесарь Что же касается рекомендаций вообще, то имейте ввиду, что создание индекса на временной таблице - это DDL операция. Из-за которой меняется схема данных. И код процедуры будет перекомпилирован. Это не всегда плохо, но надо иметь это в виду. Поэтому если вы хотите избежать перекомпиляций, делайте объявление индекса внутри объявления временной таблицы, а не отдельной командой. И само собой в самом начале процедуры. Если вы не уверены на счёт перекомпиляций, то делайте так, чтобы их избежать, всегда. https://sqlperformance.com/2017/05/sql-performance/sql-server-temporary-object-caching ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 13:38 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
invm Кесарь Что же касается рекомендаций вообще, то имейте ввиду, что создание индекса на временной таблице - это DDL операция. Из-за которой меняется схема данных. И код процедуры будет перекомпилирован. Это не всегда плохо, но надо иметь это в виду. Поэтому если вы хотите избежать перекомпиляций, делайте объявление индекса внутри объявления временной таблицы, а не отдельной командой. И само собой в самом начале процедуры. Если вы не уверены на счёт перекомпиляций, то делайте так, чтобы их избежать, всегда. https://sqlperformance.com/2017/05/sql-performance/sql-server-temporary-object-caching Немного не понял, что из написанного мной устарело, если по ссылке ровно оно самое? "To be cached, a temporary object additionally must not: Perform "DDL" after object creation" "Be sure to meet the conditions for temporary table caching, which most often means not creating indexes or statistics after the initial table creation statement. This is made more convenient from SQL Server 2014 onward due to the introduction of the INDEX clause of the CREATE TABLE statement." ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 14:09 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
aleks222 Кесарь В серьёзных компаниях такой вопрос даже не стоит. Все поля всегда должны быть описаны явно. Удивительное дело. А шо select ... into #t "неописывает поля"? Вроде все однозначно описывается из исходных таблиц. Более того, если базовые таблицы переопределены - не надо метаться по процедурам, правя определения времянок. Возможность переопределения базовых таблиц как бы ведёт к тому, что схема данных нестабильна. А значит будет перекомпиляция. Т.е. select into это DML и DDLв одном флаконе. Именно поэтому этого и нужно избегать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 14:12 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Кесарь aleks222 пропущено... Удивительное дело. А шо select ... into #t "неописывает поля"? Вроде все однозначно описывается из исходных таблиц. Более того, если базовые таблицы переопределены - не надо метаться по процедурам, правя определения времянок. Возможность переопределения базовых таблиц как бы ведёт к тому, что схема данных нестабильна. А значит будет перекомпиляция. Т.е. select into это DML и DDLв одном флаконе. Именно поэтому этого и нужно избегать. Я ЗА! Только вот эти скотины-пользователи... ЗЫ. Может хватит вещать прописные лозунги? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 14:19 |
|
Кластерный индекс до или после.
|
|||
---|---|---|---|
#18+
Кесарь, Процедуры уже давно не перекомпилируются. Перекомпилируются инструкции в процедуре. Какие именно и как это зависит от кешируемости временных объектов можете посмотреть выполнив указанный ниже простой пример с отслеживанием SQL:StmtRecompile Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2021, 14:52 |
|
|
start [/forum/topic.php?fid=46&fpage=22&tid=1684623]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 149ms |
0 / 0 |