Таблица по сравнению с временной производительностью таблицы
Одна вещь, которую Вы могли попробовать, который даст Вам довольно достойный цифровой отпечаток файла, берет преобразование Фурье и смотрит на распределение различных частот, существующих в файле. Все еще очень возможно сделать два совсем других звуковых файла, которые имеют то же преобразование Фурье, но это несколько маловероятно, если Ваши файлы прибывают из неизобретенного источника...
6 ответов
В вашей ситуации мы используем постоянную таблицу, называемую промежуточной таблицей. Это распространенный метод при большом импорте. На самом деле мы обычно используем две промежуточные таблицы: одна с необработанными данными, а другая с очищенными данными, что упрощает исследование проблем с фидом (они почти всегда являются результатом новых и разнообразных способов, которые находят наши клиенты для отправки нам нежелательных данных, но мы должны доказать это). Кроме того, вы избегаете таких проблем, как необходимость увеличения временной базы данных или создание проблем для других пользователей, которые хотят использовать временную базу данных, но должны ждать, пока она вырастет для вас, и т. Д.
Вы также можете использовать SSIS и пропустить промежуточные таблицы (таблицы) , но я считаю, что возможность вернуться и исследовать без перезагрузки таблицы 50 000 000 очень полезна.
Постоянная таблица работает быстрее, если структура таблицы должна быть на 100% одинаковой, поскольку нет накладных расходов на выделение пространства и построение таблицы.
Временная таблица работает быстрее в некоторых случаях (например, когда вам не нужны индексы, которые присутствуют в постоянной таблице, что замедлит вставку / обновление)
Постоянная таблица в большинстве случаев работает быстрее, чем временная таблица.
Посмотрите: http://www.sql-server-performance.com/articles/per/dehibited_temp_tables_p1.aspx
Временные таблицы находятся в памяти (если они не слишком большие), поэтому теоретически они должны быть ДЕЙСТВИТЕЛЬНО быстрыми. Но обычно это не так. Как правило, старайтесь держаться подальше от временных таблиц, если только это не единственное решение. Не могли бы вы дать нам дополнительную информацию о том, что вы пытаетесь сделать? Вероятно, это можно было бы сделать с помощью производного запроса
Если вы не используете tempdb, убедитесь, что модель восстановления базы данных, с которой вы работаете, не установлена на «Полная». Это приведет к большим накладным расходам при вставке этих 50-мегабайтных строк.
В идеале, вы должны использовать промежуточную базу данных, простую модель восстановления, на RAID 10, если это возможно, и заранее определить размер, чтобы обеспечить достаточно места для всех ваших операций. Отключите автоматическое увеличение.
Используйте INSERT ... WITH (TABLOCK), чтобы избежать записи в журнал на уровне строк:
INSERT INTO StagingTable WITH (TABLOCK) (.....)
SELECT .....
Аналогично для BULK INSERT. Если вы отбрасываете и создаете заново, создайте кластерный индекс до для вставки. Если вы не можете, вставьте сначала в одну таблицу, затем вставьте из нее в другую таблицу с правильной кластеризацией и обрежьте первую таблицу. По возможности избегайте небольших партий на BULK INSERT. Внимательно прочтите документацию BULK INSERT, так как вы можете саботировать производительность, используя неправильные параметры.
Избегайте INSERT ... EXEC. Регистрируется каждая строка.
Избегайте ОБНОВЛЕНИЙ, если вам не нужно подсчитывать промежуточные итоги. Как правило, дешевле вставить из одной таблицы в другую, а затем усечь первую таблицу, чем обновлять на месте. Выполнение общих вычислений является исключением, так как они могут быть выполнены с помощью UPDATE и переменных для накопления значений между строками.
Избегайте табличных переменных для чего-либо, кроме управляющих структур, поскольку они препятствуют распараллеливанию. Не присоединяйте таблицу из 50 миллионов строк к табличной переменной, вместо этого используйте временную таблицу.
Не бойтесь курсоров для итерации. Используйте курсорные переменные и объявите их с ключевым словом STATIC для столбцов с низкой мощностью в начале кластеризованного индекса. Используйте это, чтобы разделить большие таблицы на более управляемые части.
Не пытайтесь сделать слишком много в одном операторе.
I personally would use a permanent table and truncate it before each use. In my experience it is easier to understand/maintain. However, my best advice to you is to try both and see which one performs better.