Optimisation de requête sous SQL Server

Je rejoins Waldar sur l'index .. Votre critère n'est pas assez discriminant mais je pense que vous vous en êtes vite rendu compte.

De plus comme vous remontez un nombre important de lignes vous ne pourrez pas couper aux opérations de hash dans vos jointures car c'est la seule méthode efficace lors que de grandes quantités de données sont remontées.

Peut être gagnerez vous à créer une vue indexée dans votre cas si aucune autre optimisation n'est possible dans votre requête.

++

Citation:

---

Je rejoins Waldar sur l'index .. Votre critère n'est pas assez discriminant mais je pense que vous vous en êtes vite rendu compte.

---

Et non couvrant... ce qui obligerait le moteur à faire une recherche de clé sur l'index cluster pour retrouver ses petits (colonnes utilisées dans les INNER JOIN notamment).
C'est de l'ordre du détail mais EDITEUR_TF1_FR_ID est'il NULLABLE?

En effet vous faites un <> en lieu et place d'un =1...

Vu que vous avez peu de prédicat... une partition ou une vue indexée pourrait en effet s'imposer...


Reste à déterminer la différence de temps d’exécution entre les deux requêtes...
Dans les faits ces deux requêtes vous renvoient'elles le même nombre de lignes?
Si oui SQL SERVER semble ne pas s'y attendre dans les plans de requêtes.

Bonjour,

De ce que je viens de collecter, voici la liste des colonnes de la table TF_COMPTE participant aux jointures :

- AGE_ID : pas trop sélectif
- PROFESSION_ID : devrait être assez sélectif
- CIVILITE_ID : pas sélectif
- SEXE_ID : comme un bit : pas sélectif
- PRESENCE_ENFANT_ID : probablement pas sélectif
- ACTIVITE_DE_CONNEXION_SUR_SITE_ID : aucune idée
- TRANCHE_ANCIENNETE_ID : probablement pas sélectif
- ACHAT_VAD_ID : aucune idée
- POSSEDE_IPHONE_ID : comme un bit : pas sélectif

Ensuite :

Code:

---

TF1BDDCiblage.Contact.TF_COMPTE.EDITEUR_TF1_FR_ID<>0

---

pour un bit, si la colonne n'est pas NULLable, mettre = 1 !
Dans tous les cas peut-être qu'un index sur la colonne la plus sélective (c'est à dire celle qui contient le plus de valeurs distinctes) filtré sur EDITEUR_TF1_FR_ID IS NULL OR EDITEUR_TF1_FR_ID = 1 devrait aider.

Voyez pour cela le billet que je viens de publier ;)

@++ ;)

Citation:

---

filtré sur EDITEUR_TF1_FR_ID IS NULL OR EDITEUR_TF1_FR_ID = 1 devrait aider.

---

Sauf erreur de ma part le compilateur ne l'utilisera pas avec un <>, il faudra le forcer avec un hints...

Pas si le prédicat de la requête est le même que celui de l'index filtré.

Mais on peut déjà faire un premier test avec un index non-flitré ;)

@++ ;)

Je n'ai pas de valeur nulle dans cette colonne.
J'ai modifié ma condition en =1 et créer un index non cluster dessus.
Le plan d'exécution l'ignore toujours.
Idem pour l'index filtré avec la condition =1
J'ai forcé le passage par l'index avec un hint, mais pas d'amélioration des temps de réponse:-(
Une autre idée?

Avec mes remerciements,
Pitchoonet

Personnellement je ne pense pas qu'un index ici sera performant vu le peu de sélectivité de votre prédicat. Avoir la méthode préconisée par Elsuket pour l'index filtré mais je n'y crois pas ...

++

Citation:

---

Envoyé par elsuket

De ce que je viens de collecter, voici la liste des colonnes de la table TF_COMPTE participant aux jointures :

- AGE_ID : pas trop sélectif
- PROFESSION_ID : devrait être assez sélectif
- CIVILITE_ID : pas sélectif
- SEXE_ID : comme un bit : pas sélectif
- PRESENCE_ENFANT_ID : probablement pas sélectif
- ACTIVITE_DE_CONNEXION_SUR_SITE_ID : aucune idée
- TRANCHE_ANCIENNETE_ID : probablement pas sélectif
- ACHAT_VAD_ID : aucune idée
- POSSEDE_IPHONE_ID : comme un bit : pas sélectif

---

Je saute dans le topic et me pose la question suivante:
Est ce que tous les champs ID ci-dessus referencent des tables de dimension ?
Si c'est le cas, est ce qu'on peut voir la structure de celles-ci ?

Citation:

---

Je n'ai pas de valeur nulle dans cette colonne.

---

NULL n'est pas une valeur, c'est un marqueur qui signifie l'absence de valeur.
D'ailleurs si l'on exécute :

Code:

---

1 2 3 4

IF NULL = NULL PRINT 'OK' ELSE PRINT 'KO'

---

On obtient KO, quel que soit l'opérateur arithmétique.
Ce qui prouve bien que NULL n'est pas une valeur.

Ensuite le fait de n'avoir aucune ligne pour laquelle cette colonne n'est pas à NULL ne signifie pas nécessairement que la colonne n'est pas NULLable.

Pour en être certain :

Code:

---

1 2 3 4 5

SELECT C.is_nullable FROM sys.columns AS C INNER JOIN sys.tables AS T ON C.object_id = T.object_id WHERE T.name = 'maTable' AND C.name = 'maColonne'

---

Citation:

---

J'ai modifié ma condition en =1 et créer un index non cluster dessus.
Le plan d'exécution l'ignore toujours.

---

Cela n'a aucun intérêt puisqu'un tel index a une sélectivité très faible ...
Donc il est normal que SQL Server l'ait ignoré.

Citation:

---

Idem pour l'index filtré avec la condition =1

---

Quelle est la définition de l'index que vous avez créé ?

Citation:

---

J'ai forcé le passage par l'index avec un hint, mais pas d'amélioration des temps de réponse:-(

---

Et de l'activité disque (SET STATISTICS IO ON avant la requête) ?

Citation:

---

Une autre idée ?

---

Pouvez-vous exécuter la requête de mon billet pour la table TF_COMPTE et poster le résultat dans un fichier Excel ?

Il vous faut vectoriser les valeurs en créant un index multi-colonne de sorte qu'il soit aussi sélectif que possible.

@++ ;)

Bonjour,
Je n'arrive pas à exécuter votre billet.
Il me semble qu'il manque la déclaration de la variable @table_name.
D'autre part, dans la première requête il y a une autre variable non déclarée :
@statistic_name
Est-ce qu'il faut la remplacer par @stat_name?

Avec mes remerciements,
Pitchoonet