Les requêtes SQL les plus inutiles (et ce qu'il faut faire à la place)

Elles s'exécutent. Elles renvoient des données. Mais elles sont inutiles. Voici ce qu'il ne faut pas écrire en SQL - et ce qu'il faut faire à la place.

Certaines requêtes SQL s'exécutent parfaitement, mais cela ne signifie pas qu'elles sont utiles.

Dans cet article, nous allons passer en revue des exemples réels de requêtes SQL valides, d'apparence inoffensive, mais totalement inutiles. Elles gaspillent des ressources, cachent des informations ou ajoutent simplement du bruit. Pour chacune d'entre elles, vous verrez ce qui ne va pas et comment écrire une alternative plus intelligente.

Vous voulez vous entraîner tout de suite à rédiger de meilleures requêtes ? Essayez la pisteLa pratique du SQL sur LearnSQL.fr - elle est conçue pour vous aider à transformer la théorie en compétence, avec 12 cours et plus de 1000 exercices interactifs.

Nettoyons les déchets et écrivons des requêtes qui permettent réellement d'accomplir le travail.

1. Sélectionner tout ce qui n'a pas de raison d'être

La requête :

SELECT * 
FROM orders;

Pourquoi elle est inutile : elle extrait des données inutiles, ralentit les requêtes et alourdit la base de données.

Que faire à la place : ne spécifier que les colonnes nécessaires pour améliorer les performances.

Meilleure requête :

SELECT order_id, customer_id, total_amount
FROM orders;

2. Tout compter sans filtrer

La requête :




SELECT COUNT(*) 
FROM orders;

Pourquoi elle est inutile : elle renvoie souvent des informations trompeuses si elle n'est pas filtrée.

Que faire à la place : utiliser les conditions WHERE ou GROUP BY pour une meilleure précision.

Meilleure requête :




SELECT COUNT(*) 
FROM orders 
WHERE status = 'completed';

3. Commander par défaut quand l'ordre n'a pas d'importance

La requête :

SELECT total_amount 
FROM orders 
ORDER BY customer_id;

Pourquoi elle est inutile : ajoute du temps de traitement sans bénéficier de l'analyse.

Ce qu'il faut faire à la place : utiliser ORDER BY intentionnellement, par exemple pour le reporting ou la visualisation.

Meilleure requête : ne pas utiliser ORDER BY à moins que cela ne soit nécessaire ;

SELECT total_amount 
FROM orders;

4. Ordre sans clause LIMIT

Cette question est similaire à la précédente.

La requête :

SELECT order_id, customer_id, total_amount 
FROM orders 
ORDER BY created_at DESC;

Pourquoi c'est inutile : le tri de grands ensembles de données sans contraintes est inefficace.

Ce qu'il faut faire à la place : si possible, utiliser LIMIT ou TOP.

Meilleure requête :

SELECT order_id, customer_id, total_amount 
FROM orders 
ORDER BY created_at 
DESC LIMIT 10;

5. Regroupement sans étiquettes significatives

La requête :

SELECT customer_id, COUNT(*) 
FROM orders 
GROUP BY customer_id;

Pourquoi elle est inutile : Les identifiants seuls ne fournissent pas de contexte - les résultats sont difficiles à interpréter et ne permettent pas d'agir.

Ce qu'il faut faire à la place : s'assurer d'inclure un libellé significatif tel que le nom ou l'adresse électronique.

Meilleure requête :

SELECT o.customer_id, c.email, COUNT(*) AS total_orders 
FROM orders o 
JOIN customers c 
ON o.customer_id = c.id 
GROUP BY o.customer_id, c.email;

6. Utiliser HAVING au lieu de WHERE pour filtrer les lignes

La requête :

SELECT order_id, customer_id, total_amount 
FROM orders 
HAVING total_amount > 100;

Pourquoi c'est inutile : HAVING est conçu pour le filtrage agrégé, pas pour le filtrage des lignes. Bien que cela fonctionne techniquement, cela empêchera le lecteur de la requête de comprendre votre intention.

Ce qu'il faut faire à la place : utiliser WHERE avant l'agrégation.

Meilleure requête :

SELECT order_id, customer_id, total_amount 
FROM orders 
WHERE total_amount > 100;

7. Filtrer sur des colonnes calculées sans indexation

La requête :

SELECT order_id, customer_id, total_amount 
FROM orders 
WHERE YEAR(created_at) = 2023;

Pourquoi elle est inutile : empêche l'utilisation d'index, ce qui provoque des balayages complets de la table.

Ce qu'il faut faire à la place : utiliser le filtrage basé sur les plages pour exploiter les index.

Meilleure requête :

SELECT order_id, customer_id, total_amount 
FROM orders 
WHERE created_at >= '2023-01-01' AND created_at < '2024-01-01';

8. Utiliser des sous-requêtes au lieu de jointures

La requête :

SELECT order_id, customer_id, total_amount  
FROM orders  
WHERE customer_id IN (SELECT customer_id FROM blacklisted_customers);

Pourquoi elle est inutile : peut conduire à des performances lentes par rapport à JOINs.

Ce qu'il faut faire à la place : utiliser une INNER JOIN ou LEFT JOIN.

Meilleure requête :


SELECT o.order_id, o.customer_id, o.total_amount  
FROM orders o  
JOIN blacklisted_customers b ON o.customer_id = b.customer_id;

9. Auto-jonction au lieu d'utiliser Fonctions de fenêtrage

La requête :




SELECT
  o1.customer_id,
  o1.order_id,
COUNT(*) AS row_num  
FROM orders o1
JOIN orders o2
  ON o1.customer_id = o2.customer_id
  AND o1.order_date >= o2.order_date
GROUP BY o1.customer_id, o1.order_id;

Pourquoi c'est inutile : cause une complexité et une duplication inutiles.

Ce qu'il faut faire à la place : utiliser les fonctions de fenêtre pke ROW_NUMBER(), RANK(), ou LAG().

Une meilleure requête :




SELECT 
  customer_id, 
  order_id,  
  ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date) AS row_num  
FROM orders;

Écrire du SQL plus intelligent, pas seulement du SQL valide

Ce n'est pas parce qu'une requête s'exécute qu'elle est utile. En évitant ces pièges courants, vous rendrez votre SQL plus rapide, plus propre et beaucoup plus utile.

Si vous souhaitez continuer à pratiquer la bonne façon d'écrire des requêtes, consultez la pisteLa pratique du SQL sur LearnSQL.fr. Elle regorge d'exercices pratiques qui vous aideront à affiner vos compétences par la pratique, et pas seulement par la lecture.