On a parfois la mauvaise habitude de faire des SELECT * FROM table; Mon astuce de la semaine va tenter d’expliquer pourquoi il faudrait toujours énumérer les champs qu’on veut sélectionner, même s’il s’agit de la table au complet.

Il y a 3 raisons majeures pour lesquelles il ne faudrait JAMAIS faire de SELECT * FROM dans les requêtes d’une application:

• La description de la table par le biais de la requête est perdue
• Les changements de champs
• La grosseur des champs

Description de la table

Les Q.A vont être d’accord avec moi là-dessus, il n’y a rien de mieux qu’un code avec des noms de variables et de fonctions bien choisis. Et lorsque c’est pas suffisamment explicite, les programmeurs doivent ajouter des commentaires pour aider à la compréhension du code. Les requêtes SQL ne doivent pas faire exceptions à cette règle. Supposons que vous devez …

Il y a plusieurs moyens d’évaluer l’efficacité de la Query Cache. On peut se satisfaire de connaitre le nombre de hit à la cache versus le nombre de SELECT. La commande SHOW STATUS nous donne tout ce qu’on a besoin de savoir: Qcache_hits/(Com_select+Qcache_hits) ( notez que nous devons additionner Com_Select et Qcache_Hits car Com_Select n’est pas incrémenté lorsque le résultat est retourné par la cache).

Il y a certaines questions à se demander si vous obtenez un bas pourcentage. Quel genre de requêtes sont stockées en cache ? Est-ce que la cache crée une charge supplémentaire qui en vaut la peine ? On ne peut malheureusement pas savoir quelles requêtes sont dans la cache, mais on peut connaitre une partie de la surchage créé en calculant le taux d’invalidation des requêtes: (Com_insert+Com_delete+Com_update+Com_replace)/Qcache_hits

La variable Qcache_lowmem_prunes indique le …

Il n?existe pas d?autres moyen magique de sélectionner des enregistrements aléatoirement. Il y a seulement ORDER BY RAND(). Cependant, ORDER BY RAND() est un performance killer lorsque la table possède plusieurs milliés d?enregistrements.Prenons le cas où on veut afficher 10 enregistrements aléatoirement et que cette requête va être exécutée excessivement souvent par l?application. La table utilisée pour les tests est une table avec 500000 enregistrements.

Pour commencer, voyons voir comment MySQL réagis avec une requête qui ordonne sur la clef primaire avec une limite de 10 enregistrements:

1. SELECT SQL_NO_CACHE *
2. FROM tableA
3. ORDER BY id LIMIT 10;
4. // 0.00 sec

On s?y attendait, c?est tellement rapide que le client Mysql n?arrive pas à être assez précis pour dire le temps que ca a pris. Maintenant, une requête qui ordonne par RAND() avec une limite de 10 …