Discussion :

[omelhor]

Bonjour,

Voilà, j'essaye actuellement d'optimise mes requêtes sql
J'ai table avec 100 000 enregistrements

Actuellement j'utilise cette requête :

Code :

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

1
2
3
4
5
 
SELECT SQL_NO_CACHE title,author,timestamp,url,contents,image  FROM newsindex 
WHERE timestamp < CURRENT_TIMESTAMP() 
AND author NOT IN ('auteur1','auteur2','auteur3','auteur4','auteur15','auteur16') 
ORDER BY `timestamp` DESC LIMIT 0,120";

Ne vaudrait'il pas mieux que j'enlève le "SQL_NO_CACHE" ? En sachant que cette table évolue toutes les 5 minutes

Merci beaucoup pour vos conseils

[JVelon]

Bonjour,

Il n'y a pas que la table newsindex qui évolue toutes les 5 minutes,
il y a aussi la variable CURRENT_TIMESTAMP() !

Aussi, dans votre cas, le paramètre SQL_NO_CACHE est justifié.

Notez que dans la pratique, l'utilité du cache est fonction d'une part de la fréquence de modification de la ou des tables, d'autre part de la fréquence d'utilisation de la requête. Si la table est modifiée plus souvent que la requête n'est utilisée, le paramètre SQL_NO_CACHE est justifié.

Pour optimiser le cache, si vous avez accès à la configuration MySQL, on peut aussi utiliser les variables serveurs query_cache_limit et query_cache_size.

[everest31]

un petite précision sur ta clause WHERE

Ce que je comprends c'est que tu veux tous les enregistrements plus ancienne que le timestamp au moment de la requete et que donc tu as dans ta table des enregistrement qui ont un timestamp en avance (donc dans le futur).

Si ce n'est pas le cas ta clause where ne sert a rien et permettra d'alléger la requête.

de plus je te conseille de tester la fonction EXPLAIN de MySQL pour voir comment MySQL gère ta requete par rapport à ta table et l'indexation de tes champs.

Pour cela il te suffit de faire la commande suivante dan sl'interpreteur MySQL:

Code :

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

1
2
3
4
5
 
EXPLAIN SELECT title,author,timestamp,url,contents,image  FROM newsindex 
WHERE timestamp < CURRENT_TIMESTAMP() 
AND author NOT IN ('auteur1','auteur2','auteur3','auteur4','auteur15','auteur16') 
ORDER BY `timestamp` DESC LIMIT 0,120";

[omelhor]

Bonjour,

Je viens de tester le "EXPLAIN"; en retour j'ai eu ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
id	=> 1
select_type	=> SIMPLE
table	=> tableA
type	=> range
possible_keys	=> idx_timestamp
key	=> idx_timestamp
key_len	=> 9
ref	=> NULL
rows	=> 99479
Extra => Using where

Y a-il une interprétation particulière a en tirer ?

A noter que la table est modifié environ toutes les 3 minutes. De plus environ 900 lignes sont ajoutées par jour.
A noter aussi qu'elle est consultée environ 250 000 mil fois par jour
Dans ce cas est-ce que cela vaut la peine de laisser le "SQL_NO_CACHE" ?

Merci beaucoup

[everest31]

Pour savoir si le SQL_NO_CACHE vaut le coup ou pas pour ma part je raisonne dans ces termes (certes c'est pas parfait et apres rien ne vaut un peu de monitoring pour affiner):

1jour = 86400 secondes
si on prends en compte que globalement le max de requetes se fait sur une période de 18heures sur 24 ca donne:
1jour = 64800

Ensuite tu dis 900 lignes par jour ca donne donc:
900/64800 = 0.013 lignes par secondes d'ajoutée

et en requete:
250000/64800 = 3.8 requetes a la seconde

Donc le SQL_NO_CACHE te dessert dans ce cas de figure si tes chiffres sont bons.
Il faudrait aussi savoir combien d'enregistrements sont retournés par cette requête et globalement combien de ces enregistrements sont modifiés toutes les 3 minutes.

Concernant l'explain pour moi ca me parait bon compte tenu de ta requete.

[omelhor]

Pour savoir si le SQL_NO_CACHE vaut le coup ou pas pour ma part je raisonne dans ces termes (certes c'est pas parfait et apres rien ne vaut un peu de monitoring pour affiner):

1jour = 86400 secondes
si on prends en compte que globalement le max de requetes se fait sur une période de 18heures sur 24 ca donne:
1jour = 64800

Ensuite tu dis 900 lignes par jour ca donne donc:
900/64800 = 0.013 lignes par secondes d'ajoutée

et en requete:
250000/64800 = 3.8 requetes a la seconde

Donc le SQL_NO_CACHE te dessert dans ce cas de figure si tes chiffres sont bons.
Il faudrait aussi savoir combien d'enregistrements sont retournés par cette requête et globalement combien de ces enregistrements sont modifiés toutes les 3 minutes.

Concernant l'explain pour moi ca me parait bon compte tenu de ta requete.

Environ 90 000 enregistrements sont retourné par la requête
Et environ 50 enregistrement de modifié toutes les 3 minutes

Quand pense tu ?

Merci beaucoup