Les développeurs ont besoin d'indexer

Les problèmes de performances en SQL sont aussi vieux que le langage SQL lui-même. Certains n'hésitent pas à dire que SQL est intrinsèquement lent. Même s'il a pu y avoir une part de vérité au tout début du SQL, ce n'est plus du tout vrai. Et pourtant, les problèmes de performances en SQL sont toujours d'actualité. Comment cela est-il possible ?

Le langage SQL est certainement le langage de programmation de qua­trième génération ayant le plus de succès. Son principal intérêt se révèle dans sa capacité à séparer le « quoi » et le « comment ». Une requête SQL décrit le besoin sans donner d'instructions sur la manière de l'obtenir. Prenez cet exemple :

SELECT date_de_naissance 
  FROM employes 
 WHERE nom = 'WINAND'

La requête SQL se lit comme une phrase écrite en anglais qui explique les données réclamées. Écrire des requêtes SQL ne demande aucune connaissance sur le fonctionnement interne du système de base de données ou du système de stockage (disques, fichiers, etc.) Il n'est pas nécessaire d'indiquer à la base de données les fichiers à ouvrir ou la manière de trouver les lignes demandées. Beaucoup de développeurs ayant des années d'expérience avec SQL n'ont que très peu de connaissance sur le traitement qui s'effectue au niveau du système de bases de données.

La séparation du besoin et de la façon de l'obtenir fonctionne très bien en SQL mais cela ne veut pas dire pour autant que tout est parfait. Cette abstraction atteint ses limites quand des performances importantes sont attendues : la personne ayant écrit une requête SQL n'accorde pas d'importance sur la façon dont la base de données exécute la requête. En conséquence, cette personne ne se sent pas responsable d'une exécution lente. L'expérience montre le contraire. Afin d'éviter des problèmes de performance, cette personne doit connaître un peu le système de bases de données.

Il s'avère que la seule chose que les développeurs doivent connaître est l'indexation. En fait, l’indexation d’une base de données est un travail de développeurs car l’information la plus importante pour une bonne indexation ne se situe ni au niveau de la configuration du système de stockage ni dans la configuration du matériel, mais plutôt au niveau de l'application : « comment l'application cherche ses données ». Cette information n'est pas facilement accessible aux administrateurs de bases de données ou aux consultants externes. Il est parfois nécessaire de récupérer cette information en surveillant l'application. Par contre, les développeurs ont cette information facilement.

Ce livre couvre tout ce que les développeurs doivent savoir sur les index, et rien de plus. Pour être plus précis, ce livre couvre seulement le type d'index le plus important : l'index B-tree.

L'index B-tree fonctionne de façon pratiquement identique sur la plupart des bases de données. Ce livre utilise principalement la terminologie de la base de données Oracle, mais se réfère aux termes correspondant aux autres bases de données lorsque cela est approprié. Des notes fournissent des informations supplémentaires pour les bases de données MySQL, PostgreSQL et SQL Server®.

La structure de ce livre est conçue spécifiquement pour les développeurs ; la plupart des chapitres correspond à une partie distincte d'une requête SQL.

CHAPITRE 1 - Anatomie d'un index

Le premier chapitre est le seul qui ne couvre pas SQL. Il se focalise sur la structure fondamentale d'un index. Une compréhension de la structure des index est essentielle pour continuer. Ne sous-estimez pas ce chapitre, il est essentiel !

Bien que ce chapitre soit plutôt court, environ huit pages, vous verrez après l'avoir parcouru que vous comprendrez mieux le phénomène des index lents.

CHAPITRE 2 - La clause Where

Ce chapitre explique tous les aspects de la clause where, des recherches simples sur une seule colonne aux recherches complexes avec des intervalles et des cas spéciaux comme LIKE.

Ce chapitre est le cœur de ce livre. Une fois que vous aurez appris à utiliser ces techniques, vous devriez écrire des requêtes SQL bien plus performantes.

CHAPITRE 3 - Performance et scalabilité

Ce chapitre est une petite digression sur les mesures des performances et sur la scalabilité des bases de données. Cela vous permettra de comprendre pourquoi ajouter plus de matériel n'est pas la meilleure solution aux requêtes lentes.

CHAPITRE 4 - L'opération de jointure

Retour au SQL : ici, vous trouverez une explication sur l'utilisation des index pour obtenir des jointures de tables rapides.

CHAPITRE 5 - Regrouper les données

Vous êtes-vous déjà demandé s'il y avait une différence entre sélec­tionner une seule colonne ou toutes les colonnes ? Ce chapitre vous apportera cette réponse, ainsi qu'une astuce pour obtenir encore plus de performances.

CHAPITRE 6 - Trier et grouper

Même order by et group by peuvent utiliser des index.

CHAPITRE 7 - Résultats partiels

Ce chapitre explique comment bénéficier d'une exécution sérialisée si vous n'avez pas besoin de l'ensemble complet des résultats.

CHAPITRE 8 - INSERT, DELETE et UPDATE

Comment les index influencent-ils les performances en écriture ? Les index ne sont pas gratuits, utilisez-les avec précaution !

ANNEXE A - Plans d'exécution

Demandez à la base de données comment elle exécute une requête.

ANNEXE B - Liste des mythes

Liste les légendes fréquentes et explique la vérité. Sera étendu au fur et à mesure de l'écriture du livre.

ANNEXE C - Schéma d'exemple

Toutes les requêtes de création et d'insertion pour les tables exemples de ce livre.