Entre mes voyages, mes présentations et la modération des questions et réponses, je parle à beaucoup de gens d'une grande variété de problèmes de performances de SQL Server. Récemment, j'ai eu quelques interactions où les gens croient des choses qui sont soit totalement incorrectes, soit correctes uniquement dans un ensemble très restreint de cas d'utilisation. Pourtant, leur conviction que ces choses sont universellement vraies est troublante.
Alors, j'ai pensé que je commencerais une nouvelle série pour aider à apaiser certains de ces mythes. Pas pour montrer du doigt les gens et prouver qu'ils ont tort, mais pour arrêter la propagation. Lorsqu'ils font ces déclarations générales sur leur lieu de travail, sur Twitter ou sur des forums, s'ils ne sont pas contrôlés, ils peuvent "enseigner" des utilisateurs impressionnables ou moins expérimentés.
Notez que je n'ai pas l'intention de prouver que ces choses ne sont jamais vrai, car certains peuvent certainement être vrais dans des scénarios isolés ou artificiels . Mon but est simplement de démontrer au moins un cas où ce n'est pas vrai; avec un peu de chance, cela pourra commencer à changer ces mentalités tenaces.
Voici quelques-uns des "faits" qui m'ont été rapportés récemment, sans ordre particulier :
- "Un index clusterisé est toujours meilleur qu'un index non clusterisé"
- "Dynamic SQL a ralenti ma requête"
- "PIVOT est plus rapide que SUM(CASE)"
- "Les valeurs NULL causent toujours de terribles problèmes de performances"
- "Les plans d'exécution sont inutiles sauf pour les index manquants"
- "NOLOCK est bien parce que beaucoup de gens l'utilisent"
- "Le surdimensionnement des colonnes varchar/nvarchar est correct"
Au fur et à mesure que j'écris chaque article, je mettrai à jour cette page en liant l'élément correspondant dans la liste ci-dessus.
Avez-vous des mythes sur les performances qui circulent comme des faits absolus, mais vous soupçonnez (ou savez peut-être même) qu'ils ne sont pas toujours vrais ? Faites-le moi savoir dans les commentaires ci-dessous, sur Twitter ou à [email protected].
