Différence entre Clustered et Non-Clustered Index ?

Index Seek vs Index Scan ?

CTE vs Temp Table ?

ROW_NUMBER vs RANK vs DENSE_RANK ?

Que sont les Deadlocks ?

Comment optimiser une requête lente ?

ACID ?

Isolation Levels ?

Pourquoi éviter SELECT * ?

Comment trouver le 2e ou 3e salaire le plus élevé ?

Différence EXISTS vs IN ?

Comment analyser un Execution Plan ?

1. Différence entre Clustered et Non-Clustered Index

Clustered Index

Les données de la table sont physiquement triées selon l'index.


Table Orders

1
2
3
4
5

L'ordre du stockage correspond à l'index.

Une seule fois par table.

Avantages

Très rapide pour les recherches par plage


WHERE OrderDate BETWEEN ...

Non-Clustered Index

Structure séparée contenant :


Valeur indexée
    |
    +--> Pointeur vers la ligne

Exemple :


CREATE INDEX IX_CustomerId
ON Orders(CustomerId)

Plusieurs par table.

Réponse entretien

Le Clustered Index définit l'ordre physique des données dans la table et il n'en existe qu'un seul. Le Non-Clustered Index est une structure séparée contenant des pointeurs vers les données et une table peut en posséder plusieurs.

2. Index Seek vs Index Scan

Index Seek

SQL Server va directement à la valeur recherchée.


SELECT *
FROM Orders
WHERE Id = 100


Index Seek

Complexité proche :


O(log n)

Très performant.

Index Scan

SQL Server parcourt tout l'index.


SELECT *
FROM Orders
WHERE YEAR(OrderDate)=2026


Index Scan


Table Scan

Plus coûteux.

Réponse entretien

Index Seek signifie que SQL Server utilise efficacement l'index pour accéder directement aux lignes recherchées. Index Scan signifie qu'il parcourt une grande partie ou la totalité de l'index.

3. CTE vs Temp Table

CTE


WITH Sales AS
(
   SELECT *
   FROM Orders
)
SELECT *
FROM Sales

Caractéristiques :


Temporaire
Non matérialisée
Lisibilité
Requêtes récursives

Temp Table


SELECT *
INTO #Orders
FROM Orders


CREATE TABLE #Orders (...)

Caractéristiques :


Stockée dans tempdb
Peut être indexée
Réutilisable plusieurs fois

Réponse entretien

Une CTE améliore la lisibilité et est généralement utilisée dans une seule requête. Une Temp Table est physiquement stockée dans tempdb et devient intéressante lorsqu'on doit réutiliser les données plusieurs fois ou créer des index intermédiaires.

4. ROW_NUMBER vs RANK vs DENSE_RANK

Données :

ROW_NUMBER


ROW_NUMBER()

Résultat :

Toujours unique.

RANK


RANK()

Résultat :

Trou dans la numérotation.

DENSE_RANK


DENSE_RANK()

Résultat :

Pas de trou.

Réponse entretien

ROW_NUMBER attribue un numéro unique à chaque ligne. RANK gère les ex-aequo mais laisse des trous. DENSE_RANK gère les ex-aequo sans laisser de trous.

5. Que sont les Deadlocks ?

Transaction A :


Lock TableA
Attend TableB

Transaction B :


Lock TableB
Attend TableA

Résultat :


Deadlock

SQL Server choisit une victime :


Deadlock Victim

et annule sa transaction.

Prévention


Même ordre d'accès aux tables
Transactions courtes
Index adaptés
Retry automatique

Réponse entretien

Un deadlock survient lorsque deux transactions se bloquent mutuellement en attendant des ressources détenues par l'autre. SQL Server détecte la situation et annule l'une des transactions.

6. Comment optimiser une requête lente ?

Checklist classique :

1. Execution Plan

Chercher :


Table Scan
Index Scan
Sort coûteux
Hash Match coûteux

2. Vérifier les index


WHERE
JOIN
ORDER BY
GROUP BY

3. Éviter


SELECT *

4. Réduire les données


TOP
Pagination

5. Vérifier statistiques


UPDATE STATISTICS

Réponse entretien

Je commence toujours par analyser l'Execution Plan afin d'identifier les scans, tris ou jointures coûteuses. Ensuite je vérifie les index, les statistiques et le volume de données traité.

7. ACID

Atomicity

Tout ou rien.


Commit ou Rollback

Consistency

Les règles métier restent valides.

Isolation

Les transactions ne se perturbent pas.

Durability

Après Commit :


Les données survivent à un crash

Réponse entretien

ACID garantit la fiabilité des transactions : Atomicité, Cohérence, Isolation et Durabilité.

8. Isolation Levels

Read Uncommitted


Dirty Reads possibles

Read Committed

Défaut SQL Server.


Pas de Dirty Read

Repeatable Read

Empêche la modification des lignes lues.

Serializable

Isolation maximale.

Snapshot

Très utilisé.


Versioning
Moins de blocages

Résumé


Read Uncommitted < Read Committed < Repeatable Read < Serializable

9. Pourquoi éviter SELECT * ?

Mauvais :


SELECT *
FROM Customers

Problèmes :


Lecture inutile
Plus d'I/O
Plus de réseau
Moins d'utilisation d'index couvrants
Maintenance compliquée

Préférer :


SELECT Id, Name
FROM Customers

Réponse entretien

SELECT * augmente les I/O, le trafic réseau et empêche parfois SQL Server d'utiliser des index couvrants. Je sélectionne uniquement les colonnes nécessaires.

10. Trouver le 2e ou 3e salaire le plus élevé

Avec DENSE_RANK


WITH Ranked AS
(
    SELECT
        Salary,
        DENSE_RANK()
        OVER(ORDER BY Salary DESC) AS Rnk
    FROM Employees
)
SELECT *
FROM Ranked
WHERE Rnk = 2

2e salaire.


WHERE Rnk = 3

3e salaire.

11. EXISTS vs IN

IN


SELECT *
FROM Orders
WHERE CustomerId IN
(
   SELECT Id
   FROM Customers
)

EXISTS


SELECT *
FROM Orders o
WHERE EXISTS
(
   SELECT 1
   FROM Customers c
   WHERE c.Id = o.CustomerId
)

Différence

EXISTS


S'arrête dès qu'il trouve une correspondance


Peut nécessiter davantage de traitement

sur gros ensembles.

Réponse entretien

EXISTS est souvent plus performant sur de gros volumes car SQL Server s'arrête dès qu'une correspondance est trouvée. IN est généralement plus lisible pour les petites listes.

12. Comment analyser un Execution Plan ?

Les opérateurs à surveiller :

Opérateur	Bon/Mauvais
Index Seek	✅ Bon
Clustered Index Seek	✅ Bon
Index Scan	⚠️ Moyen
Table Scan	❌ Mauvais
Nested Loop	✅ Souvent bon
Hash Match	⚠️ Peut être coûteux
Sort	⚠️ Coûteux
Key Lookup	⚠️ À surveiller

Méthode d'analyse

Activer Actual Execution Plan.
Identifier l'opérateur le plus coûteux.
Chercher :


Table Scan
Index Scan
Sort
Hash Match
Key Lookup

Vérifier les index.
Contrôler le nombre de lignes estimées vs réelles.

Réponse entretien

J'analyse d'abord l'Execution Plan réel, je repère les opérateurs les plus coûteux, puis je vérifie la présence de scans, de key lookups et la cohérence entre les lignes estimées et réelles. Cela permet d'identifier rapidement les problèmes d'indexation ou de cardinalité.

vendredi 12 juin 2026

SQL - 2

1. Différence entre Clustered et Non-Clustered Index

Clustered Index

Avantages

Non-Clustered Index

Réponse entretien

2. Index Seek vs Index Scan

Index Seek

Index Scan

Réponse entretien

3. CTE vs Temp Table

CTE

Temp Table

Réponse entretien

4. ROW_NUMBER vs RANK vs DENSE_RANK

ROW_NUMBER

RANK

DENSE_RANK

Réponse entretien

5. Que sont les Deadlocks ?

Prévention

Réponse entretien

6. Comment optimiser une requête lente ?

1. Execution Plan

2. Vérifier les index

3. Éviter

4. Réduire les données

5. Vérifier statistiques

Réponse entretien

7. ACID

Atomicity

Consistency

Isolation

Durability

Réponse entretien

8. Isolation Levels

Read Uncommitted

Read Committed

Repeatable Read

Serializable

Snapshot

Résumé

9. Pourquoi éviter SELECT * ?

Réponse entretien

10. Trouver le 2e ou 3e salaire le plus élevé

Avec DENSE_RANK

11. EXISTS vs IN

IN

EXISTS

Différence

Réponse entretien

12. Comment analyser un Execution Plan ?

Méthode d'analyse

Réponse entretien

Aucun commentaire:

Enregistrer un commentaire