Как правило, накладные расходы на вставку строки состоят из нескольких компонентов. Я могу подумать о следующем:
Для (1). Из-за кластеризованного индекса в столбце идентификаторов новая строка попадает в таблицу в «конце» таблицы, то есть на последней странице. В данном случае нет связи между размером таблицы и местом для поиска строки.
Для (2). Существует очень небольшая дополнительная нагрузка на обновление кластеризованного индекса по мере роста таблицы. Но это очень мало - и фрагментация, похоже, не является проблемой.
Для (3). Это не связано с размером таблицы.
Для (4). У вас, похоже, нет триггеров или ограничений, так что это не проблема.
Итак, по моим расчетам, при вставке таблицы будет очень мало дополнительных накладных расходов.
Примечание: могут быть и другие факторы. Например, вам может потребоваться увеличить табличное пространство для поддержки таблицы большего размера. Однако на самом деле это связано не только с размером таблицы, но и с отношением между размером данных и доступными ресурсами.
Похоже, ваша ссылка предназначена для встроенных функций, специфичных для архитектуры x86, согласно , этот memcmp реализован как архитектурно-независимый встроенный компонент gcc.
Изменить:
Компиляция следующего кода с помощью Cygwin gcc версии 3.3.1 для i686, -O2:
#include <stdlib.h>
struct foo {
int a;
int b;
} ;
int func(struct foo *x, struct foo *y)
{
return memcmp(x, y, sizeof (struct foo));
}
дает следующий результат (обратите внимание, что вызов memcmp () преобразуется в 8-байтовый "repz cmpsb"):
0: 55 push %ebp
1: b9 08 00 00 00 mov $0x8,%ecx
6: 89 e5 mov %esp,%ebp
8: fc cld
9: 83 ec 08 sub $0x8,%esp
c: 89 34 24 mov %esi,(%esp)
f: 8b 75 08 mov 0x8(%ebp),%esi
12: 89 7c 24 04 mov %edi,0x4(%esp)
16: 8b 7d 0c mov 0xc(%ebp),%edi
19: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi)
1b: 0f 92 c0 setb %al
1e: 8b 34 24 mov (%esp),%esi
21: 8b 7c 24 04 mov 0x4(%esp),%edi
25: 0f 97 c2 seta %dl
28: 89 ec mov %ebp,%esp
2a: 5d pop %ebp
2b: 28 c2 sub %al,%dl
2d: 0f be c2 movsbl %dl,%eax
30: c3 ret
31: 90 nop