Производительность вставки Sql и размер стола

В sql производительность вставки зависит от количества записей в таблице? Я знаю, что оператор обновления может отличаться, но что делать с вставками?Производительность вставки Sql и размер стола

Например, оператор insert в таблице с 10 миллионами записей будет таким же, как оператор insert в другой таблице с той же схемой, кроме записей 1k?

/*my schema*/ 
[id] [int] NOT NULL, 
[type] [nvarchar](20) NOT NULL, 
[relatedP] [int] NULL, 
[relatedC] [int] NULL, 
[eventdate] [DateTime] NOT NULL 

/*no triggers and inserts as simple as*/ 
INSERT INTO myTable (id,type,relatedP,relatedC,eventdate) VALUES (@id,@type,@relatedP,@RelatedC,@date)

источник

2014-01-08 user1492051

It действительно сводится к типу индексации, который у вас есть на столе. Если в индексе много индексов, вставки будут занимать намного больше времени, поскольку эти индексы должны быть обновлены, больше созданных листов и т. Д. Или если для кластерных индексов используются большие поля и т. Д. Если в таблице нет индексов, тогда объем данных в таблице не имеет большого значения. – Brettski

Это будет зависеть от многих факторов, таких как ограничения, индексы и значения по умолчанию в таблице (например, вставки в неиндексированную таблицу кучи должны занимать постоянное время) и могут ли они работать в постоянное время. Кроме того, индексы будут занимать немного больше времени, так как иерархия страниц станет более глубокой. – StuartLC

Спасибо, что то, что мне нужно знать, у меня простая схема из 5 столбцов с базовыми типами, в моем случае нет индексации, но размер просто увеличивается примерно на 4,4 млн. Записей сейчас, было интересно, должен ли я быть – user1492051

Потому что кажется, что ваша таблица не имеет кластерного индекса (ни первичный ключ, который будет вызывать кластерный индекс по умолчанию), то он будет создан в качестве heap.

Кроме того, в вашей таблице также нет никаких некластеризованных индексов - как правило, по мере увеличения количества строк в таблице с индексами глубина индекса также будет постепенно получать deeper, что означает, что производительность вставки будет слегка ухудшена.

Но поскольку, похоже, у вас нет индексов, ограничений, значений по умолчанию, индексированных представлений или постоянных вычисляемых столбцов, вставки должны быть постоянными, когда таблица растет.

(ИМО table with no indexing at all is fairly unusual - фильтруются производительность запросов, вероятно, будет плачевной - как правило, это будет только полезно, например, для журнала или козел данных, которые затем полностью прочитать повторно с читателем и перерабатывают в финальные столы.)

источник

2014-01-08 06:16:53 StuartLC

именно его таблица журналов событий – user1492051

Как в стороне, 'BulkCopy', как правило, действительно эффективный способ получения данных в таких таблицах. например Если вы используете .net, вы можете загружать строки в память, а затем периодически использовать [SqlBulkCopy] (http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlbulkcopy.aspx) – StuartLC

i использовал массовый экземпляр в .NET раньше, но разве он не удаляет данные, которые уже есть в таблице? – user1492051

Производительность вставки Sql и размер стола

ответ

Смежные вопросы