Requête simple n'utilisant pas les index correctement

Bonjour,

J'essaye de corriger toutes mes requêtes n'utilisant pas d'index (log_queries_not_using_indexes)

Et je buche actuellement sur cette requête très simple.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

# Query_time: 0 Lock_time: 0 Rows_sent: 688 Rows_examined: 2295 SELECT c_branche_link , c_branche_id , c_branche_nom FROM t_branche WHERE c_branche_status >= 2 AND c_branche_news_nb > 0 ORDER BY c_branche_id ASC;

---

les champs c_branche_status et c_branche_news_nb sont bien indexés et pourtant ne sont pas utilisés :

id = 1
select_type = SIMPLE
table = t_branche
type = ALL
possible_keys = c_branche_news_nb,c_branche_status
key = NULL
key_len = NULL
ref = NULL
rows = 1607
Extra = Using where; Using filesort

Si quelqu'un à une idée ?

Merci,

Quelle proportion de lignes de ta table vérifie c_branche_status >= 2 d'une part, c_branche_news_nb > 0 d'autre part ?

Alors voila c'est à peu près similaire :

c_branche_status >= 2 = 752

c_branche_news_nb > 0 = 778

sur combien de lignes au total ?

1 607 lignes

Un index efficace est un index qui offre une bonne sélectivité. Or, tes deux conditions ont une sélectivité de l'ordre de 45%. L'optimiseur de MySQL considère qu'au-dessus de 30%, l'index n'est pas intéressant... Ce en quoi il a parfaitement raison : lire l'index et aller chercher 45% des lignes dans la table à partir des infos de l'index prendrait plus de temps que d'ignorer l'index, parcourir 100% de la table et ne garder que les 45% de lignes intéressantes.

Dit autrement, l'index sert à trouver une aiguille dans une botte de foin, mais pas à séparer la botte en un tas de longues pailles et un tas de courtes pailles.

Ok j'ai bien comprit, merci pour cette grande clarté :)

Du coup comment faire pour que cette requête ne ressorte pas dans les logs des query n'utilisant pas d'index ? (ceci afin d'optimiser plus finement mon fichier my.cnf)

J'ajoute des fausses données pour déséquilibrer la balance ? :cfou:

Dans ton cas, c'est le SGBD qui décide qu'utiliser l'index n'est pas rentable. Ta requête est optimisée, la structure de la table semble l'être également donc il n'y a rien d'autre à faire.
Et surtout pas ajouter de fausses données ! 8O

On ma proposé une autre astuce, utiliser le FORCE INDEX.

Le FORCE INDEX marche parfaitement (contrairement au USE INDEX).

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SELECT c_branche_link , c_branche_id , c_branche_nom FROM t_branche FORCE INDEX (c_branche_status) WHERE c_branche_status >= 2 AND c_branche_news_nb > 0 ORDER BY c_branche_id ASC

---

La requête est exécuté exactement à la même vitesse (0,0013s), donc c'est parfait :)

J'ai au passage réorganiser ma table sur c_branche_id et mis la requête de réorganisation en cron (les mise à jour de cette table sont peu fréquentes)

Citation:

---

ALTER TABLE t_branche ORDER BY c_branche_id

---

Ce qui m'a permis d'enlever le ORDER BY en fin de requête pour gagner 0,0010s et descendre a 0,0003s d'exécution.

Et voila plus de trace de la requête dans les logs, je vais pouvoir passer à la suivante.

Merci pour votre aide :)

L'objectif d'une application n'est pas de créer des logs propres...