MasterClass présenté par François Martin le 03/07/2018 à la communauté SkillValue.

1. SQL MASTERCLASS :
COMMENT AVOIR DE BONNES PERFORMANCES AVEC SQL SERVER
François MARTIN
3 juillet 2018
francois.martin@scaling

2. DÉFINIR « DE BONNES PERFORMANCES »
• Environnement OLTP, BI ou mixte ?
• Informatique industrielle ou de gestion ?
• Combien d’utilisateurs, pour quelle volumétrie et avec quelle
croissance ?
• …

3. PERFORMANCE OLTP (informatique de
gestion)
• SQL Server n’est pas une « couche de persistance » abstraite
• SQL Server est un SGBDR très complexe et redoutablement puissant
• Mais SQL Server ne sait faire que ce qu’on lui demande
• SQL Server ne peut pas « inventer » des traitements performants
• Les DBAs doivent bien sur comprendre en profondeur SQL Server
• Les développeurs aussi !

4. ARCHITECTU
RE SQL
SERVER
• Plus qu’une “couche de
persistance”, SQL Server est
un veritable OS !
(extrait de https://social.msdn.microsoft.com/forums/sqlserver)

5. Qu’est-ce que l’Optimiseur de requête ?
• C’est le composant interne de SQL Server qui analyse les
requêtes SQL puis établit les plans d’exécution.
• La différence entre un bon et un mauvais plan d’exécution peut
se traduire par des variations de performance d’un facteur
1000 ou plus !
• Pour produire de bons plans d’exécutions il faut:
• Ecrire du « bon » code Transact/SQL
• Disposer de « bons » indexes et de statistiques de distribution à jour

6. (Extrait de : http://www.sqlrelease.com/query-execution-flow-architecture-sql-server)
Comment fonctionne le traitement
d’une requête SQL ?
- 1°) Parser. Analyse syntaxique et
sémantique de la requête.
- 2°) Algebrizer. Produit un arbre binaire
correspondant à un premier niveau de plan
d’exécution en logique relationnelle, littéral
et sans optimisation.
- 3°) Query Optimizer. Analyse de l’arbre
fourni par l’Algebrizer; produit plusieurs
plans alternatifs optimisés, par étapes
successives.
- 4°) Query Executor. Exécution de la requête
selon le meilleur plan fourni par
l’optimiseur.

7. Plan d’exécution
L’optimisation d’un tel plan consiste à évaluer le plus rapidement possible le plus grand nomb
de plans (d’arbres) afin de trouver le meilleur (le plus court chemin).

8. Comment fonctionne l’optimiseur ?
• L’optimiseur commence par vérifier s’il existe dans le cache un plan
d’exécution pour un cas identique ou similaire, et s’il existe il
l’utilise.
• Si aucun plan adéquat n’est présent dans le cache, l’optimiseur
produit un premier plan « trivial ». Si le coût estimé de ce plan est
négligeable alors il est utilisé.
• Sinon commence une phase de simplification du plan (réductions,
factorisations, transformations élémentaires, …) et d’optimisation
sémantique.
• Si le coût estimé du nouveau plan produit est négligeable il est
utilisé.
• Sinon commence le travail bien plus lourd et complexe

9. Optimisation sémantique
• SQL Server va tirer parti des contraintes définies dans le modèle
de données.
• Les Primary Key, Foreign Key, Constraints diverses (check,
unique, between, …) seront utilisés par l’optimiseur pour
simplifier le plan, notamment lors des jointures, et détecter les
situations impossibles qui contreviennent aux contraintes.

10. Ex:
• select * from PERSON
where CHILDREN_COUNT < 0
• En étudiant le plan d’exécution on voit que le coût d’exécution de la requête
est 1,80094 :

11. Ex:
• Si à présent on ajoute la contrainte suivante :
• alter table PERSON
add constraint CS_CHILDREN_COUNT CHECK (CHILDREN_COUNT >= 0)
• Alors le coût d’exécution de la requête devient 0,0000012 (voisin de zéro) :

12. Optimisation statistique
• La véritable optimisation commence après l’étape sémantique
et consiste à trouver le plan d’exécution le plus court parmi
une quantité combinatoire de plans possible : c’est le classique
problème du plus court chemin de la théorie des graphes
(https://fr.wikipedia.org/wiki/Théorie_des_graphes).
• Pour trouver le plan d’exécution le plus court, l’optimiseur a
besoin de chiffres détaillés sur le nombre de lignes dans les
tables, la densité de valeurs dans les colonnes utilisées comme
critère de recherches ou apparaissant dans une jointure, …

13. Exemple:
• Considérons 3 tables:
- Metiers : 100 lignes
- Entreprises : 3 500 000 lignes
- Contrats : 8 000 000 lignes
• Soit une requête SQL recherchant le chiffre d’affaire des contrats d’assurances des entreprises de transport de plus
de 1000 salariés.
- Si pour résoudre cette requête SQL Server effectue une jointure dans cet ordre :
• Contrats -> Entreprises -> Metiers,
alors les performances seront catastrophiques.
• Pour chacun des 8M de contrats on vérifie si l’entreprise à moins de 1000 salariés puis pour chaque
entreprise on vérifie s’il s’agit bien du bon métier (transport). Pour simplifier il faut environ 24 millions
d’I/Os logiques pour ce traitement.

14. Exemple:
- Si pour résoudre cette requête SQL Server effectue une jointure dans cet ordre :
• Metiers -> Entreprises -> Contrats,
alors les performances seront bien meilleures.
• En effet on considère un unique métier (transport) pour déterminer les entreprises concernées, puis on
applique un filtre sur le nombre d’employés et on accède aux contrats. Pour simplifier il faut moins de 100k
I/Os logiques pour ce traitement (comparés à 24M).
• Enfin, on peut encore faire mieux si l’on dispose de statistiques sur la densité des valeurs de colonnes. On saura en
effet qu’il y a moins de 500 entreprises de plus de 1000 salariés alors qu’il y a environ 100 000 entreprises de
transports.
• Entreprises -> Metiers, puis -> Contrats,
alors les performances seront bien meilleures.
• En effet on considère les 500 entreprises de plus de 1000 salariés puis on restreint aux sociétés de transport
et on accède aux contrats (moins de 1 000 I/Os logiques comparés à 24 000 000)

15. Les statistiques de distribution sont essentielles
RANGE_HI_KEY : Valeur (haute) de la clé considérée
RANGE_ROWS : Nb de lignes ayant une valeur de clé comprise entre celle-ci et la précédente
DISTINCT_RANGE :Nb de valeurs de clés distinctes entre celle-ci et la précédente
EQ_ROWS : Nb de lignes ayant exactement cette valeur de clé
AVG_RANGE : RANGE / DISTINCT_RANGE (lorsque DISTINCT_RANGE est > 0). C’est la
moyenne de lignes par clés dans cette plage de valeurs.
dbcc show_statistics (BILLPAYMENTREQUEST, PK_BILLPAYMENTREQUEST);

16. Les statistiques sont établies sur la première colonne
uniquement !
dbcc show_statistics (BILLPAYMENTREQUEST, IDX_BILLPAYMENTREQUEST_ID);

17. Cas réel (vu aujourd’hui même !)

18. Cas réel (vu aujourd’hui même !)

19. Cas réel (vu aujourd’hui même !)

20. Cas réel (vu aujourd’hui même !)

21. Cas réel (vu aujourd’hui même !)

22. Avec le temps SQL Server crée automatiquement des
statistiques qui lui sont utiles

23. Réécriture de requêtes
L’optimiseur de SQL Server n’est qu’un algorithme et bien souvent, il ne fera pas aussi bien qu’un
- Pensez à utiliser toutes les possibilités de Transact-SQL : CTE, Window Functions, …
- Evitez l’utilisation de fonctions sur des colonnes (comme « UPPER(name) = ‘MARTIN’ qui eng
Dans ce cas on préfèrera utiliser une collation CI pour ignorer la casse…
- On pourra si indispensable utiliser des « Hints » (FORCE ORDER, OPTIMIZE FOR UNKOWN, …)

24. Pire qu’une requête lente: une architecture
logicielle lente
• Règle N°1:
• Pensez le design de la base de données en termes de performance
• Règle N°2:
• Minimisez le trafic entre les programmes et SQL Server (round-trips)
• Règle N°3:
• Utilisez les transactions les plus courtes possibles
• Règle N°4:
• Ayez les bons indexes (défragmentés) et les bonnes statistiques (à jours et même sur les petites tables).
• Règle N°5:
• Utilisez des procédures stockées
• Règle N°0:
• Pas de clans : les DBA et développeurs doivent travailler main dans la main et penser ensemble aux
performances !

25. Pire qu’une requête lente: une architecture
logicielle lente
• Règle N°1:
• Pensez le design de la base de données en termes de performance
• Pensez à dénormaliser lorsque nécessaire.
• Vous pouvez par exemple déplacer les colonnes rarement utilisées vers des tables
secondaires
• Suffisamment d’indexes… mais pas trop !
• Des Primary Key et Foreign Key pertinentes et conçues pour la performance
• Archivez les données peu utilisées

26. Pire qu’une requête lente: une architecture
logicielle lente
• Règle N°2:
• Minimisez le trafic entre les programmes et SQL Server (round-trips)
• Attention notamment à certains ORM (Object Relationnal
Mapping) qui ont tendance à générer des millions de requêtes.
• Beaucoup de développeurs « pensent séquentiellement ». SQL
Server repose sur une logique ensembliste; les deux approches
sont TRES différentes.

27. Pire qu’une requête lente: une architecture
logicielle lente
• Règle N°3:
• Utilisez les transactions les plus courtes possibles
• Plus une transaction dure longtemps, plus la probabilité de gêne
d’autres transactions augmente (blocages ou même deadlocks).
• Attention aux « phénomènes de résonnance » où des blocages
s’amplifient mutuellement jusqu’à l’effondrement du système.
• Planifiez les batchs avec soin, si possible en dehors des périodes de
production.

28. Pire qu’une requête lente: une architecture
logicielle lente
• Règle N°4:
• Ayez les bons indexes (défragmentés) et les bonnes statistiques (à jours et
même sur les petites tables).
• Pensez à vérifier l’usage des indexes avec
sys.dm_db_index_usage_stats !
• Essayez d’avoir un index cluster sur chaque table (le bon index
cluster, pensez aux ”Range Scans” et divers ORDER BY pour le choisir)

29. Pire qu’une requête lente: une architecture
logicielle lente
• Règle N°5:
• Utilisez des procédures stockées
• Les PS permettent notamment de:
• Augmenter la maintenabilité du code
• Diminuer les « round-trips » (échanges clients-serveur)
• Maintenir le cache d’exécution du code SQL en bon état

30. Enfin, pensez à l’infrastructure en termes
de performance
• Séparez la BI de la Production si possible
• Always On Availability Groups (pour ceux qui ont la chance d’avoir l’édition
Enterprise)
• Sinon la Réplication Transactionnelle est très efficace en édition Standard !
• Ayez « suffisamment » du puissance CPU, I/O et RAM
• Evitez les disques lents (Nearline SAS, …) ou les baies partagées et non
gérées
• Attention à la contention sur les Logs, sur TempDB,…
• Mais pensez aussi au fait qu’aucune infrastructure ne pourra
rattraper un mauvais design de base de données ou une mauvaise