Optimiser ses requêtes

Programme (1 heure)

1) Méthode de mesure 

• Démo sur un projet type (liste + recherche + stats)
• Mesurer avant / après (chronométrage + répétabilité)
• Cas “ça rame en prod mais pas en dev” : volumes & plans différents
• Règles de base : dataset réaliste, exécutions multiples, éviter le “premier run”

Livrable : une checklist de mesure utilisable sur tes écrans WINDEV/WEBDEV.

2) Requêtes SQL “WLangage friendly” 

• Utiliser une Source de données + SQL (lisible & maintenable)
• Paramétrer (éviter concat SQL, stabilité des perfs)
• Réutiliser la même requête (préparer / exécuter plusieurs fois)
• Parcours efficace : lire uniquement ce qui est utile

Exécution SQL en code via HExécuteRequêteSQL / HExécuteRequête (selon le cas).

3) Les pièges HFSQL qui coûtent cher  

• SELECT * et colonnes inutiles (I/O + réseau + mémoire)
• Filtres non indexables (fonctions sur rubrique, conversions, calculs)
• LIKE '%...%' : pourquoi ça “force” souvent un parcours coûteux
• Tri sans index adapté (ORDER BY sur colonne non indexée)
• Jointures “explosives” : duplication de lignes & agrégations lentes
• Pagination naïve : OFFSET élevé = lenteur exponentielle

4) Clés & index : simples vs composés 

Ici on voit quand mettre un index, sur quel(s) champ(s), et pourquoi. (Cas WINDEV/WEBDEV : listes filtrées, tables, combos, exports)

• Index simple : 1 champ → filtre fréquent (ex. ID client, statut, date)
• Index composé : plusieurs champs → WHERE + ORDER BY / critères combinés

• Ordre des colonnes (règle pratique) :

  • D’abord les champs très filtrants (forte sélectivité)
  • Puis ceux utilisés pour trier / regrouper
  • Objectif : éviter tri et parcours inutiles
• Quand éviter : champs à faible sélectivité (booléens), index jamais utilisés
• Coût : plus d’index = inserts/updates plus lents (et maintenance)
• Cas “clé composée obligatoire” : multi-tenant (societe_id + …), historiques (id + date), lignes (doc_id + num_ligne)

Bonus : approches HFSQL (définir les clés dans l’analyse + règles de vérification en prod).

5) Requête et beaucoup de données - pagination 

• Liste paginée : filtre + tri → index adapté
• Recherche : multi-critères (sans concat et sans full scan inutile)
• Stats : GROUP BY + agrégations + limitation des données

Chaque cas : requête initiale → diagnostic → index / refactor → mesure.

5) Recherche sémantique + HFSQL 

Objectif : ajouter une recherche “intelligente” (par sens, pas par mots-clés) sur une table (ex. Tickets, Interventions, Articles, FAQ) tout en gardant des performances maîtrisées côté HFSQL.

A) Mise en situation (2 min)

• On part d’une recherche classique : LIKE '%...%' (souvent lente et peu pertinente)
• Problème : synonymes, fautes, formulations différentes (ex. “ne démarre plus” vs “écran noir”)
• Solution : recherche sémantique via embeddings + score de similarité

B) Dataset & structure HFSQL (2 min)

• Table T_Documents : ID, Titre, Contenu, DateMaj, Type
• Table T_Embeddings : DocumentID, Modele, Dimension, Vecteur

• Index recommandés :

  • Clé unique sur T_Embeddings(DocumentID, Modele) (clé composée)
  • Index sur T_Documents(Type, DateMaj) si tu filtres par type + tri

Pourquoi une clé composée ? Un document peut avoir plusieurs vecteurs (par modèle / version), et on veut retrouver vite “le bon”.

7) Conclusion : checklist & plan d’action 

• Checklist “requête lente” (quoi regarder en premier)
• Plan d’action : mesurer → indexer → simplifier → re-mesurer
• Conseils prod : maintenance / optimisation planifiée côté HFSQL C/S