Meilleures pratiques SQL et réglage des performances

L’objectif du réglage des performances dans SQL est de minimiser le temps d’exécution de la requête et de réduire le nombre de ressources lors du traitement de la requête. Chaque fois que nous exécutons la requête, les performances dépendent de la quantité de données et de la complexité des calculs sur lesquels nous travaillons. Ainsi, en réduisant le nombre de calculs et de données, nous pouvons améliorer les performances. Pour cela, nous avons quelques bonnes pratiques et facteurs majeurs dont nous allons discuter en détail.

Types de données – Décider du bon type de données peut réduire l’espace de stockage et améliorer nos performances. Nous devons toujours choisir la taille minimale du type de données qui fonctionnera pour toutes les valeurs de toutes les colonnes.

• Le choix d’un type de données spécifique permet de s’assurer que seules des valeurs spécifiques sont stockées dans une colonne particulière et de réduire la taille de stockage.
• Parfois, nous devons convertir un type de données en un autre, ce qui augmente l’utilisation des ressources et réduit ainsi les performances. Ainsi, pour éviter cela lors de la création d’une table, il faut veiller à utiliser le bon type de données dans les tables de notre modèle de données, ce faisant, nous réduisons les risques de les modifier à l’avenir. De cette façon, nous n’avons pas besoin de convertir le type de données implicitement ou explicitement et notre requête s’exécute plus rapidement.
• Nous devrions utiliser un nouveau type de données au lieu du type de données obsolète.
• Enregistrez la date et l’heure dans une colonne séparée. Il est utile d’agréger les données sur la date et l’heure, ce qui aide également lorsque nous filtrons les données.
• Lorsque nous avons une colonne avec une longueur fixe, optez pour le type de données de longueur fixe, par exemple – Sexe, Valeur du drapeau, Code pays, Numéro de mobile, Code postal, etc.

Filtrage des données- Les performances des requêtes dépendent de la quantité de données que nous traitons, il est donc important de ne prendre que les données requises pour notre requête. Aussi, à quel niveau nous filtrons les données.

L’avenir des mégadonnées

Avec quelques conseils, vous pouvez créer une plate-forme de données adaptée aux besoins de votre organisation et tirer le meilleur parti de votre capital de données.

Obtenir le guide

Voyons quelques-uns des scénarios –

• Par exemple, si nous voulons voir l’agrégation pour l’année 2022 et pour le département ABC, nous devrions toujours filtrer les données avant l’agrégation dans le Où clause au lieu de Ayant.
• Si nous voulons joindre deux tables avec des données spécifiques, nous devons filtrer les données requises avant de joindre la table.

rejoint – Join est un concept très courant et utile dans les bases de données et les entrepôts de données. Afin d’améliorer les performances, il est très important de choisir la jointure appropriée à nos besoins. Vous trouverez ci-dessous quelques bonnes pratiques de jointure.

• Si nous ne voulons que des enregistrements correspondants provenant de tables jointes, nous devrions opter pour une jointure interne. Si nous voulons des données complètes d’une table, nous devrions opter pour la gauche ou alors droite jointure externe et si nous voulons des données complètes à la fois de la table, nous devrions opter pour jointure externe complète. Essayez toujours d’éviter Jointure croisée
• Utilisez ON au lieu d’écrire la condition de jointure sur la clause where.
• Utilisez le nom d’alias pour la table et la colonne.
• Évitez OU dans la condition de jointure.
• Préférez toujours joindre au lieu d’une sous-requête corrélée. la sous-requête corrélée a des performances médiocres par rapport aux jointures.

Exister vs IN –

• Nous devrions utiliser EXISTER au lieu de DANS chaque fois que la sous-requête renvoie une grande quantité de données.
• Nous devons utiliser IN lorsque la sous-requête renvoie une petite quantité de données.

Indice- Si nous parlons de réglage des performances dans SQL, Index joue un rôle très important. Nous pouvons créer un index implicitement ou explicitement. Nous devons utiliser l’index avec beaucoup de prudence car, d’une part, il augmente les performances de recherche, de tri et de regroupement des enregistrements, et d’autre part, il augmente l’espace disque et prend plus de temps lors de l’insertion, de la mise à jour et de la suppression de données. Il existe deux types d’index, Grappe et Hors cluster index. Nous ne pouvons avoir qu’un seul index cluster par table et chaque fois que nous créons une clé primaire dans la table, la base de données crée implicitement un index clusterisé. Nous pouvons avoir plusieurs index non cluster dans la table. Chaque fois que nous créons une clé unique sur la table, la base de données crée un index non cluster.

Vous trouverez ci-dessous quelques bonnes pratiques pour créer des index.

• Il est toujours recommandé de créer un index clusterisé avant de créer un index non clusterisé.
• Le type de données entier fonctionne plus rapidement avec l’index par rapport à la chaîne car l’entier a un faible espace requis. C’est pourquoi il est recommandé de créer une clé primaire sur la colonne Integer.
• Indexation dans la base de données OLTP -Il faut éviter plusieurs index dans la base de données OLTP (traitement des transactions en ligne) car il est nécessaire d’insérer et de modifier fréquemment les données. Par conséquent, plusieurs index peuvent avoir un impact négatif sur les performances.
• Indexation dans la base de données OLAP –La base de données OLAP (traitement analytique en ligne) est principalement utilisée à des fins analytiques, nous utilisons donc couramment des instructions de sélection pour obtenir les données. Dans ce scénario, nous pouvons utiliser plus d’index sur plusieurs colonnes sans affecter les performances.

Union vs Union All- Union all est plus rapide que Union car union vérifie les doublons et renvoie des valeurs distinctes tandis que Union all renvoie tous les enregistrements des deux tables. Si vous savez que les deux tables ont des enregistrements uniques et distincts l’un de l’autre, alors nous pouvons opter pour union tous pour de meilleures performances.

Voici quelques bonnes pratiques que nous pouvons suivre pour améliorer les performances SQL.