Navigation · Définir comme page d'accueil · Ajouter aux favoris · Mobile Tencent · Page d'accueil de Tencent Actualités Blog Forum Commentaires Finance Titres Fonds d'actions de Hong Kong Divertissement Stars Films Musique Sports NBA Football Complet Voitures Immobilier Appareils ménagers Technologie Numérique Mobile Téléchargements Émotions féminines Parentalité Mode Shopping Voyages Lecture Original Éducation Partir à l'étranger Jeux Anime Animation Constellations Vidéo Images en direct Expo Charité Enfants Nouveau disque d'or chinois populaire Visitez le monde coloré de la mode et des produits de luxe Téléphones mobiles les plus vendus au niveau national Suivez le classement pour voir quelles célébrités ont leur anniversaire aujourd'hui Votre emplacement : Tencent. Page d'accueil > Technologie et numérique > Digital Scroll News > Texte
Catch-21 pour le développement de bases de données SQL Server http://digi.QQ.com 21 décembre 2009 09:43 Zhongguancun en ligne Si vous êtes responsable d'un projet basé sur SQL Server, ou si vous êtes nouveau sur SQL Server, vous avez peut-être être confronté à des problèmes de performances de base de données, et cet article vous fournira des conseils utiles (dont la plupart peuvent également être utilisés avec d'autres SGBD).
Ici, je ne vais pas présenter de conseils pour l'utilisation de SQL Server, et je ne peux pas non plus fournir une solution panacée. Ce que je fais, c'est résumer certaines expériences sur la façon de créer une bonne conception. Cette expérience vient de ce que j’ai appris au cours des dernières années, où j’ai vu bon nombre des mêmes erreurs de conception se répéter encore et encore.
1. Connaissez les outils que vous utilisez
Ne sous-estimez pas cela, c’est le point le plus critique que je vais aborder dans cet article. Peut-être avez-vous également constaté que de nombreux programmeurs SQLServer ne maîtrisent pas toutes les commandes T-SQL ni les outils utiles fournis par SQLServer.
"Quoi ? Je vais perdre un mois à apprendre des commandes SQL que je n'utiliserai jamais ???", pourriez-vous dire. C'est vrai, vous n'avez pas besoin de faire ça. Mais vous devriez passer un week-end à parcourir toutes les commandes T-SQL. Votre tâche ici est de comprendre qu'à l'avenir, lorsque vous concevrez une requête, vous vous souviendrez : "Au fait, voici une commande qui peut pleinement réaliser la fonction dont j'ai besoin", alors allez sur MSDN pour vérifier la syntaxe exacte de cette commande.
Permettez-moi de le répéter : n'utilisez pas de curseurs. Si vous souhaitez détruire les performances de l’ensemble du système, ils constituent votre premier choix le plus efficace. La plupart des débutants utilisent des curseurs sans se rendre compte de l'impact qu'ils ont sur les performances. Ils occupent de la mémoire, verrouillent les tables de toutes leurs manières étranges et fonctionnent comme un escargot. Et le pire, c'est qu'ils peuvent faire en sorte que toute l'optimisation des performances que votre administrateur de base de données puisse faire équivaut à ne pas le faire. Savez-vous que chaque fois que vous exécutez FETCH, vous exécutez une commande SELECT ? Cela signifie que si votre curseur contient 10 000 enregistrements, il effectuera 10 000 SELECT ! Ce sera beaucoup plus efficace si vous utilisez un ensemble de SELECT, UPDATE ou DELETE pour terminer le travail correspondant.
Les débutants pensent généralement que l’utilisation de curseurs est une manière de programmer plus familière et plus confortable, mais malheureusement, cela peut entraîner de mauvaises performances. De toute évidence, l’objectif général de SQL est ce que vous souhaitez réaliser, et non comment.
Une fois, j'ai réécrit une procédure stockée basée sur un curseur à l'aide de T-SQL. La table ne contenait que 100 000 enregistrements. La procédure stockée d'origine a pris 40 minutes, mais la nouvelle procédure stockée n'a pris que 10 secondes. Ici, je pense que vous devriez pouvoir voir ce que fait un programmeur incompétent ! ! !
On peut parfois écrire un petit programme pour récupérer et traiter les données et mettre à jour la base de données, ce qui est parfois plus efficace. N'oubliez pas : T-SQL ne peut rien faire concernant les boucles.
Permettez-moi de vous rappeler encore une fois : il n'y a aucun avantage à utiliser des curseurs. Je n'ai jamais vu quoi que ce soit de fait efficacement avec des curseurs, à l'exception du travail DBA.
3. Standardisez vos tableaux de données
Pourquoi ne pas normaliser la base de données ? Il y a probablement deux excuses : des raisons de performance et une pure paresse. Quant au deuxième point, il faudra tôt ou tard le payer. Et concernant les performances, vous n'avez pas besoin d'optimiser quelque chose qui n'est pas du tout lent. Je vois souvent des programmeurs "dénormaliser" une base de données parce que "la conception originale était trop lente", mais le résultat est souvent qu'ils ralentissent le système. Le SGBD est conçu pour gérer des bases de données canoniques, alors n'oubliez pas : concevez la base de données en fonction des exigences de la canonisation.
4. N'utilisez pas SELECT *
Ce n’est pas facile à faire, comme je le sais très bien, car je le fais moi-même tout le temps. Cependant, si vous spécifiez les colonnes dont vous avez besoin dans SELECT, cela apportera les avantages suivants :
1 Réduisez la consommation de mémoire et la bande passante du réseau
2 Vous pouvez obtenir une conception plus sécurisée
3 Donnez à l'optimiseur de requêtes une chance de lire toutes les colonnes requises de l'index
Page 2 : Comprenez ce que vous allez faire de vos données
Créer un index robuste pour votre base de données est une bonne chose. Mais faire cela est tout simplement un art. Chaque fois que vous ajoutez un index à une table, SELECT sera plus rapide, mais INSERT et DELETE seront nettement plus lents car la création et la maintenance de l'index nécessitent beaucoup de travail supplémentaire. Évidemment, la clé de la question ici est : quel type d’opération souhaitez-vous effectuer sur cette table. Ce problème n'est pas facile à comprendre, surtout lorsqu'il s'agit de DELETE et UPDATE, car ces instructions contiennent souvent des commandes SELECT dans la partie WHERE.
6. Ne créez pas d'index sur la colonne "Gender"
Tout d’abord, il faut comprendre comment les index accélèrent l’accès à une table. Vous pouvez considérer les index comme un moyen de diviser une table en fonction de certains critères. Si vous créez un index sur une colonne comme « sexe », vous divisez simplement le tableau en deux parties : masculine et féminine. Vous avez affaire à une table contenant 1 000 000 d'enregistrements. Quelle est la signification de cette division ? N'oubliez pas : la maintenance des index prend du temps. Lorsque vous concevez l'index, veuillez suivre cette règle : disposez les colonnes du plus au moins en fonction du nombre de contenus différents que la colonne peut contenir, tels que : nom + province + sexe.
7. Utiliser les transactions
Veuillez utiliser les transactions, en particulier lorsque les requêtes prennent du temps. Si quelque chose ne va pas avec votre système, cela vous sauvera la vie. Généralement, les programmeurs ayant une certaine expérience comprendront que vous rencontrez souvent des situations imprévisibles qui entraîneront le blocage de la procédure stockée.
8. Méfiez-vous des impasses
Accédez à vos tables dans un certain ordre. Si vous verrouillez d'abord la table A, puis la table B, elles doivent être verrouillées dans cet ordre dans toutes les procédures stockées. Si vous verrouillez (accidentellement) d'abord la table B, puis verrouillez la table A dans une procédure stockée, cela peut provoquer un blocage. Si la séquence de verrouillage n’est pas conçue en détail à l’avance, un blocage n’est pas facile à détecter.
Une question fréquemment posée est la suivante : Comment puis-je ajouter rapidement 100 000 enregistrements à une ComboBox ? Ce n’est pas correct et vous ne pouvez ni n’avez besoin de le faire. C'est très simple. Si votre utilisateur doit parcourir 100 000 enregistrements pour trouver l'enregistrement dont il a besoin, il vous maudira certainement. Ici, vous avez besoin d'une meilleure interface utilisateur et vous ne devez pas afficher plus de 100 ou 200 enregistrements à vos utilisateurs.
Par rapport aux curseurs côté serveur, les curseurs côté client peuvent réduire la surcharge du serveur et du réseau ainsi que le temps de verrouillage.
11. Utiliser la requête de paramètres
Parfois, je vois des questions comme celle-ci sur le forum technique CSDN : "SELECT * FROM aWHEREa.id='A'B, une exception se produit en raison d'une requête avec guillemet simple, que dois-je faire ?", et la réponse courante est : utilisez deux Des guillemets simples au lieu de guillemets simples. C'est faux. Cela traite les symptômes plutôt que la cause première, car vous rencontrerez également de tels problèmes avec d'autres personnages, sans compter que cela provoquera de graves bugs. De plus, cela empêchera également le système de mise en mémoire tampon de SQL Server de fonctionner comme il le devrait. En utilisant la requête paramétrée, tous ces problèmes disparaissent.
12. Utilisez de grandes bases de données lors du codage de programmes
La base de données de test utilisée par les programmeurs en développement ne contient généralement pas une grande quantité de données, mais l'utilisateur final dispose souvent d'une grande quantité de données. Notre approche habituelle est erronée, et la raison est très simple : les disques durs ne sont pas très chers actuellement, mais pourquoi les problèmes de performances ne sont-ils détectés que lorsqu'ils sont irréversibles ?
13. N'utilisez pas INSERT pour importer de grandes quantités de données
S'il vous plaît, ne faites pas cela à moins que cela ne soit absolument nécessaire. Utilisez UTS ou BCP pour obtenir flexibilité et rapidité d’un seul coup.
14. Faites attention aux problèmes de délai d'attente
Lors de l'interrogation de la base de données, la valeur par défaut de la base de données générale est relativement petite, par exemple 15 secondes ou 30 secondes. Certaines requêtes prennent plus de temps à s'exécuter, en particulier lorsque la quantité de données dans la base de données continue d'augmenter.
Page 3 : N'ignorez pas le problème de la modification du même enregistrement en même temps
15. N'ignorez pas le problème de la modification du même enregistrement en même temps
Parfois, deux utilisateurs modifieront le même enregistrement en même temps, de cette façon, si ce dernier modificateur modifie les opérations du modificateur précédent, certaines mises à jour seront perdues. Gérer cette situation n'est pas difficile : créez un champ d'horodatage, vérifiez-le avant d'écrire, fusionnez les modifications si cela est autorisé et avertissez l'utilisateur en cas de conflit.
16. Lors de l'insertion d'enregistrements dans la table détaillée, n'exécutez pas SELECT MAX(ID) dans la table principale
Il s'agit d'une erreur courante qui provoque des erreurs lorsque deux utilisateurs insèrent des données en même temps. Vous pouvez utiliser SCOPE_IDENTITY, IDENT_CURRENT et IDENTITY. Si possible, n'utilisez pas IDENTITY car cela peut causer des problèmes en présence de déclencheurs (voir discussion ici).
17. Évitez de définir des colonnes comme NULLable
Si possible, vous devez éviter de rendre les colonnes NULLables. Le système allouera un octet supplémentaire pour chaque ligne de la colonne NULLable, ce qui entraînera une surcharge du système lors de l'interrogation. De plus, rendre les colonnes NULLables complique le codage car ces colonnes doivent être vérifiées à chaque accès.
Je ne dis pas que les valeurs NULL sont une source de problèmes, même si certaines personnes le pensent. Je pense que rendre une colonne NULLable peut parfois bien fonctionner si des "données nulles" sont autorisées dans vos règles métier, mais utiliser NULLable dans une situation comme celle ci-dessous pose problème.
NomClient1
AdresseClient1
ClientEmail1
NomClient2
AdresseClient2
ClientEmail3
NomClient1
AdresseClient2
ClientEmail3
Si cela se produit, vous devez normaliser votre table.
18. Essayez de ne pas utiliser le type de données TEXT
N'utilisez pas TEXT sauf si vous traitez un très grand ensemble de données. Parce qu'il n'est pas facile à interroger, qu'il est lent et qu'il gaspillera beaucoup d'espace s'il n'est pas utilisé correctement. En général, VARCHAR peut mieux gérer vos données.
19. Essayez de ne pas utiliser de tables temporaires
Essayez de ne pas utiliser de tables temporaires, sauf si vous y êtes absolument obligé. Généralement, les sous-requêtes peuvent être utilisées à la place des tables temporaires. L'utilisation de tables temporaires entraînera une surcharge du système, et si vous programmez avec COM+, cela vous posera également beaucoup de problèmes, car COM+ utilise un pool de connexions à la base de données et la table temporaire existe du début à la fin. SQL Server propose des alternatives, telles que le type de données Table.
20. Apprenez à analyser et à interroger
SQL Server Query Analyzer est votre meilleur ami, grâce auquel vous pouvez comprendre comment les requêtes et les index affectent les performances.
21. Utiliser l'intégrité référentielle
La définition des clés primaires, des contraintes uniques et des clés étrangères peut faire gagner beaucoup de temps.