Discussion :

[Etanne]

Bonjour à tous,

Je suis actuellement entrain de poser les indexes dans une base de données.

Je me pose la question suivante, il est déconseillé de poser des indexes sur les petites tables (contenu avec quelques lignes).

Mais comment savoir si table est "petite" ? Existe-il une formule ?

Je pensai à ce genre de formule :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(Taille de toutes les colonnes * nombre de lignes) / Taille d'une page

Et donc si on dépasse X pages, alors il serait plus intéressant d'utiliser un INDEX.

Mais que vaudrait X ?

Merci

[zinzineti]

L'Expert que je connais actuellement sur ce sujet est SqlPro il a écrit de nombreux articles sur le sujet et des scripts de maintenances des index sur SQL Server. Et vous trouverez la version complète et bien détaillée de TOUT ce qu'il faut savoir et savoir faire sur les index dans les fiches .PDF qui accompagne la dernière édition de son livre SQL 4è édition. Je vous le conseille vivement

[SQLpro]

... il est déconseillé de poser des indexes sur les petites tables (contenu avec quelques lignes).

Non, je n'ai jamais dit cela est cette remarque est stupide.

Il est toujours conseillé de placer les bons index :
- triviaux (FK, colonnes fréquemment cherchées...)
- en fonction des requêtes réllement effectuées en production

MAIS...

Un index sur une petite table ne sert pas à grand chose.
Par exemple si une table fait une page (les données des tables sont stockées dans des pages de 8 Ko) un index sur des données de cette table fera 2 pages au minimum (une page racine "d'aiguillage" + une page de données).
L'utilisation de l'index sera plus donc plus couteux que le lecture directe de la page

MAIS... (bis)
Petite table peut devenir grande !
Aussi par sécurité il convient de tout indexer, car de toutes façon c'est l'optimiseur qui choisira en final si l'index est plus ou moins couteux que la lecture directe de la table !

A +

[Etanne]

Non, je n'ai jamais dit cela est cette remarque est stupide.

J'ai repris d'info de la MSDN :

Une petite table est une table dont le contenu tient dans une ou quelques pages de données. Évitez d'indexer des tables très petites, car une analyse de table est généralement plus efficace. Elle évite le chargement et le traitement des pages d'index. En ne créant pas d'index sur de très petites tables, vous évitez que l'optimiseur en choisisse un.

Il est toujours conseillé de placer les bons index :
- triviaux (FK, colonnes fréquemment cherchées...)
- en fonction des requêtes réllement effectuées en production

C'est ce que je fait actuellement, j'analyse l'ensemble des requêtes effectuées

Un index sur une petite table ne sert pas à grand chose.
Par exemple si une table fait une page (les données des tables sont stockées dans des pages de 8 Ko) un index sur des données de cette table fera 2 pages au minimum (une page racine "d'aiguillage" + une page de données).
L'utilisation de l'index sera plus donc plus couteux que le lecture directe de la page

Puis-je à partir de 2 pages, en déduire que l'utilisation d'un index soit plus avantageux ?

Petite table peut devenir grande !
Aussi par sécurité il convient de tout indexer, car de toutes façon c'est l'optimiseur qui choisira en final si l'index est plus ou moins couteux que la lecture directe de la table !

Quand tu parles de l'optimiseur, tu parles de l'outil fournit avec SQL-Server ?

Merci encore pour l'aide

[StringBuilder]

L'optimiseur n'est pas "fourni avec SQL Server", c'est le moteur même de SQL Server.

C'est le bout de code qui va décidé, après interprétation de ta requête, de comment l'exécuter. C'est un mécanisme interne à tout SGBD.

[Etanne]

Aaaaaaaaaaaaaah, c'était dans la MSDN .

Le fait de mettre un index sur une table qui consomme qu'une page coûtera au moteur de choisir entre utiliser l'indexation et la lecture directe de la seule page.

C'est cette décision qui représente un surcoût !

Merci à tous de votre aide !

[StringBuilder]

Ouais enfin les décisions de l'optimiseur, c'est en général un micronième du coût de la requête.

Ou alors c'est que tu fais sans arrêt "select id from matable where id = 1" avec une table ayant une unique colonne id et une unique ligne avec la valeur 1...

Et à ce moment, les motivations d'utilisation d'un SGBD sont... assez obscures.