Discussion :

[Sindel]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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,

[Antoun]

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

[Sindel]

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

c_branche_status >= 2 = 752

c_branche_news_nb > 0 = 778

[Antoun]

sur combien de lignes au total ?

[Sindel]

1 607 lignes

[Antoun]

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.