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.

[Sindel]

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 ?

[CinePhil]

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 !

[Sindel]

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

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

Code :

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

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)

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

[Antoun]

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