Clustered index : ralentit l'INSERT ?

J'ai un collègue qui soutient qu'il faut utiliser des clefs primaire en "NON CLUSTERED" pour améliorer les performences d'INSERT, dans SQL SERVER 2000.

Je n'arrête pas de chercher, et je trouve des propos contradictoires sur ce sujet.

exemples :

Citation:

---

“…SQL Server 2000 supports a maximum of 249 non-clustered indexes per table. However, it’s important to keep in mind that non-clustered indexes slow down the data modification and insertion process, so indexes should be kept to a minimum…”
http://databases.about.com/od/sqlser...ndextuning.htm


“…This means, if you add a clustered index to a table that is heavily inserted, updated, or deleted, you will probably need to rebuild or de-fragment the index more often than when a non-clustered index is used….”
http://searchsqlserver.techtarget.co...239664,00.html

---

Est-ce vrai pour de nombreux INSERT, pour des DELETE / INSERT ?

Qu'en pensez-vous ? Merci par avance pour cet "arbitrage" ! :)

Les index cluster sont fortement conseillé car il permettent de marier l'index et les données de la table en une seule structure alors que l'index heap doublonne les données.
Cepandant il faut savoir choisir la ou les colonnes qui seront celle du classement de l'index. En effet avec des colonnes indexées du cluster qui parviennent à chaque insert en ordre aléatoire l'effort sera très important alors qu'avec une colonne monotone (au sens mathématique du terme) l'effort sera inexistant.
C'est pourquoi l'index cluster doit en principe porter sur une coonne de type autoincrément ou horodatage.
Si ce n'est pas le cas, il faut étudier de façon plus serré le problème, notamment avec une maintenance de l'index.
En tous cas avoir toujours un index cluster est une bonne chose dans 95% des cas.
Voir les travaux de Kimberly Tripp (sql skills) sur le sujet.

A +

Bonjour, ta question est intéressante. En effet, avoir des indexs clustered sur les clés primaires identity est recommandé la plus part du temps. Ensuite tout dépend de ta clé primaire. Si celle-ci se partage sur plusieurs champs qui ne sont pas des champs indentity alors avoir un index cluster sur un des champs peut s'avérer intéressant.

Tu abordes le problème du tunning de base de données. Je te conseille avant de créer tes indexs, d'analyser les requêtes les plus fréquemment exécutées sur ta base de données. Quelques soient leurs types (SELECT,INSERT,UPDATE,DELETE). Après cet état des lieux de l'activité SQL de ta base, il te faut analyser les champs ayant le plus d'impact sur tes requêtes. A partir de cette étude préalable, tu pourras définir tes besoins au niveau de tes indexs.

Je te conseillerai donc de rechercher sur le net des articles consacrés au tunning de base de données.

Bon débat.

Merci beaucoup pour vos réponses.

Comme l'index clustered organise le fichier selon la donnée , je me demandais si chaque INSERT ne "bouleversait" pas à chaque fois la table, ce qui ne semble pas être le cas si la valeur est auto-incrément.

Ce qui me surprend, c'est que dans ma table, selon le "générateur de profil" le SELECT est très rapide (peu de "read", "duration" faible), alors qu'un UPDATE ou un INSERT provoquent un grand nombre de "Reads" (dans les 500) et peu de "Writes"...

Je me demandais alors si cela ne venait pas de l'index clustered ?

Pour insérer une ligne il faut savoir ou l'insérer dans les différents index. C'est pourauoin un insert commence par des lectures pour trouver la position de la ligne et des différentes composantes d'indexation pour savoir ou situer les données.

A +