Performances d'insertion SQL Server avec et sans clé primaire

Résumé: j'ai une table peuplées par les éléments suivants:

insert into the_table (...) select ... from some_other_table

L'exécution de la requête ci-dessus avec pas clé primaire sur the_table est ~15x plus rapide que de courir à avec une clé primaire, et je ne comprends pas pourquoi.

Les détails: je pense que c'est mieux expliqué par des exemples de code.

J'ai une table:

create table the_table (
    a int not null,
    b smallint not null,
    c tinyint not null
);

Si j'ai ajouter une clé primaire, cette requête d'insertion est terriblement lent:

alter table the_table
    add constraint PK_the_table primary key(a, b);

-- Inserting ~880,000 rows
insert into the_table (a,b,c)
    select a,b,c from some_view;

Sans la clé primaire, la même requête d'insertion est d'environ 15x plus rapide. Cependantaprès avoir rempli the_table sans clé primaire, je peux ajouter la contrainte de clé primaire et qui ne prend que quelques secondes. Ce seul fait vraiment pas de sens pour moi.

Plus d'infos:

  • Le plan d'exécution estimé montre 0% total des requêtes temps passé sur l'index cluster insérer
  • SQL Server 2008 R2 édition Développeur, 10.50.1600

Des idées?

source d'informationauteur Eric

  1. -5

    C'est une bonne question, mais une assez merdique question. Avant de vous demander pourquoi un index ralentit inserts, savez-vous ce qu'un index?

    Si pas, je vous suggère de lire. Un index cluster est un B-arbre (arbre Équilibré), de sorte que chaque insert est en...... attendre.... l'équilibre de l'arbre. Donc cluster inserts sont plus lent que l'insertion sur le tas. Si vous ne savez pas ce qu'est un tas de l'est, puis-je suggérer de cesser d'utiliser SQL Server jusqu'à ce que vous comprenez les bases. D'autre que vous tentez d'utiliser un produit dont vous n'avez aucune idée de ce que vous faites, et, fondamentalement, la conduite d'un camion sur l'autoroute, les yeux bandés, pensant que vous êtes sur un vélo. Des résultats inattendus...

    Ainsi, lorsque vous créez un Index cluster après un tableau est rempli, votre 'tas' a une statistique à utiliser, et SQL peut, en gros, d'optimiser un peu les choses. Ce processus est beaucoup plus compliqué que cela, mais dans certains cas, vous constaterez que la création d'un index cluster après le fait, pourrait être beaucoup plus lent que de simplement insérer. Cela a tout à voir avec la clé, le nombre de colonnes, les types de colonnes, etc. Ce n'est malheureusement pas un sujet qui est digne d'une réponse, ce n'est plus un ensemble de cours et de quelques livres par lui-même. En regardant votre tableau ci-dessus, il est TRÈS simple tableau avec les ~7byte lignes. Dans cet exemple, une création d'index après l'insertion sera plus rapide, mais chuck dans quelques varchar(250)'s, etc, et l'autre paire de manche changements.

    Si vous ne le saviez pas, un index cluster, (si votre table a une), EST à votre table.

    Espère que cette aide.

  2. 6

    Fait ce n'est pas aussi claires que Ryk suggère.

    Il peut effectivement être plus rapide pour ajouter des données à une table avec un index puis dans un tas.

    Lire ce arctle - et pour autant que je suis conscient de ses assez bien considéré:

    http://www.sqlskills.com/blogs/kimberly/post/The-Clustered-Index-Debate-Continues.aspx

    Garder à l'esprit de ses écrits par MVP SQL Server et le Directeur Régional de Microsoft.

    Inserts sont plus rapides dans un cluster de table (mais seulement dans le "droit" cluster tableau) que par rapport à un segment. Le principal problème ici est que les recherches dans le IAM/PFS pour déterminer l'emplacement insérer dans un segment de mémoire sont plus lents que dans un cluster de table (où insérer le lieu est connu, défini par la clé cluster). Les Inserts sont plus rapides lorsqu'il est inséré dans un tableau où l'ordre est défini (CL) et où l'ordre est de plus en plus. J'ai quelques chiffres simples, mais je pense à la création d'un beaucoup plus grand/scénario complexe et la publication de ceux-ci. Simple/rapide tests sur un ordinateur portable ne sont pas toujours comme "excitant".

  3. 2

    Je pense que si vous créez une simple clé primaire qui est ordonné et composé d'un seul auto-incrémentation d'une colonne, puis insère dans un tel tableau pourrait être plus rapide. Le plus probable, une clé primaire composée de plusieurs colonnes peuvent être la cause de ralentissement dans les inserts. Lorsque vous utilisez une clé composite pour la clé primaire, puis les lignes insérées peut pas ajoutés à la fin du tableau, mais faudra peut-être ajouter quelque part dans le milieu de la physique existant afin de lignes dans la table, ce qui ajoute encore à l'heure d'insertion et rend donc les INSERTS plus lent. Il faut donc utiliser un seul auto-incrémentation d'une colonne comme la valeur de la clé primaire dans votre cas, afin d'accélérer les insertions.