La query cache de MySQL joue un rôle important dans la performance de plusieurs sites Web.  Elle a pour avantage d’être  transparente, c’est-à-dire que la ou les applications qui s’en servent n’ont pas besoin d’être modifiées.

J’ai recu la semaine passée la question suivante (je résume):

Je souhaite utiliser une cache pour le menu de mon site afin de le rendre plus performant. Puisque le contenu du menu ne change pratiquement jamais, est-il plus avantageux d’utiliser APC Cache que la Query Cache de MySQL puisque la communication s’effectue selon un schéma comme:

php -> cache_apc (ram)
php -> mysql -> query_cache (ram)

Je souhaite réduire au minimum les requêtes SQL exécutées.

Personnellement, j’utiliserais la cache de MySQL. Tout d’abord, il faut savoir qu’il y a une énorme différence entre les 2 caches.

MySQL Query Cache est …

Depuis quelques années, beaucoup de storages engines ont vue le jour pour répondre à des besoins que les storages engines fournis avec MySQL ne font pas bien, voir pas du tout. Selon moi, la majorité d’entre eux sont des projets qui risquent mourir dans un proche avenir. Toujours selon moi, pour que les projets gratuits et opensource demeurent longtemps, il faut qu’ils jouissent d’une certaine popularité, ce que la majorité des storages engines ne possèdent pas. De plus, ils doivent être en mesure de prouver qu’ils sont sans faille; on ne peut se permettre de perdre des données à cause d’un engine immature.

Malgré tout, je crois en un storage engine non officiel: Percona-XtraDB. Il est basé sur le populaire engine InnoDB, mais offre de meilleures performances tout en demeurant 100% compatible à ce que InnoDB peut accomplir. On peut donc remplacer …

On m’a soumis un problème il y a quelques semaines (désolé du délai, c’est l’été pour tout le monde hein.. ) à propos d’importation CSV qui était terriblement lente. J’ai reçu très peu d’information, donc voici des tests que j’ai effectués afin qu’il puissent être utilisés comme point de référence pour des comparaisons. Voici la problématique telle qu’on me l’a soumise

Pour un simple fichier CSV d’environ 1000 lignes (quelques Mo), j’ai largement le temps soit de manger, soit de faire une sieste, … pour une base de données MyISAM. Si j’utilise une base de données InnoDB, celle dont j’ai besoin, plus d’une journée. Je me base uniquement sur un seul utilisateur. A terme, j’aurai des To de données à gérer.

La Machine de tests:

Une VM avec 512 Mo de RAM avec un mauvais IO puisque d’autres VM roulent sur le même serveur. Voici un bout de la config que j’ai utilisé …

J’oublie parfois à quel point les tables temporaires peuvent être pratiques. On tente de sortir des rapports avec des tables qui ne sont pas prévues pour ça. On écrit des requêtes inimaginables et souvent très lentes. Résultat: on perd notre temps.

La solution: les tables temporaires ! Ce n’est pas très coûteux et drôlement pratique. Au lieu de prendre 25 minutes à écrire “une” requête qui prend un temps énorme à s’exécuter, prenez 10 minutes pour écrire 2-3 requêtes simples qui utilisent des tables temporaires et sortez le même résultat en quelques secondes!

Et si c’est efficace, performant (surtout performant) et récurrent, pourquoi ne pas transformer ces tables temporaires en view ?

Mysql offre la possibilité d’afficher à l’utilisateur le plan d’exécution pour une requête données. Pour cela, il suffit de précéder la requête à analyser de l’instruction EXPLAIN.

Ainsi utilisé, MySql affiche en résultat à l’utilisateur un tableau permettant de détailler comment l’optimiseur de requête va exécuter celle-ci. C’est ce qu’on appelle le plan d’exécution. Le tableau affiché en résultat peu contenir de 1 à plusieurs lignes.

Dans le cas d’une requête simple, ce tableau contiendra une ligne.

Dans le cas d’une requête contenant deux instructions SELECT associées avec la clause UNION, le tableau contiendra trois lignes :

• une ligne pour chaque exécution de l’instruction SELECT,
• une ligne pour le résultat de l’instruction UNION

Le tableau affiché contient les colonnes suivantes :

• …

Le but de cet article est d’optimiser une simple requête  (SELECT avg(Population) FROM city GROUP BY CountryCode) et surtout de comprendre comment l’optimiseur procède, en étudiant les résultats donnés par les variables qui permettent de surveiller le serveur MySQL.

Le schéma utilisé est le schéma world téléchargeable ici

Voici la structure de la table city:

SHOW CREATE TABLE city\G
*************************** 1. row ***************************
Table: city
Create Table: CREATE TABLE city (
ID int(11) NOT NULL AUTO_INCREMENT,
Name char(35) NOT NULL DEFAULT ”,
CountryCode char(3) NOT NULL DEFAULT ”,
District char(20) NOT NULL DEFAULT ”,
Population int(11) NOT NULL DEFAULT ‘0′,
PRIMARY KEY (ID)
) ENGINE=MyISAM …

Il est possible d’influencer l’optimiseur pour qu’il choisisse d’utiliser ou de ne pas utiliser un index particulier. Les clauses à placer dans votre requête SELECT sont les suivantes:

USE INDEX : utilise l’index passé en argument (MySQL ne l’utilisera pas si l’index est plus couteux qu’un full table scan)

FORCE INDEX : utilise l’index passé en argument (MySQL ne l’utilisera pas …s’il ne peut pas l’utiliser )

IGNORE INDEX : n’utilise pas l’index passé en argument

La plus part du temps, il se débrouille trés bien sans indications, mais parfois…

Dans cet exemple, j’utilise une table rental_daz inspirée de la table rental de la base de donnée sakila, voici sa structure:

12:14 daz$sakila> SHOW …

Dans les nouveautés de MySQL 5.1, il y a l’activation / désactivation des logs sur demande. J’adore ce feature. Pour moi, c’est un outil de debug. Je m’en sers pour trouver des problèmes de performance ou de transactions qui sont souvent complexes à identifier dans une application avec une grosse architecture.

Le principe est simple: dans un environnement isolé, c’est-à-dire un environnement où vous savez que vous êtes le seul à travailler, accédez à l’interface problématique de votre application. Activez les logs avec la commande:

SET GLOBAL general_log = 1;

Lancez ensuite l’opération problématique. Lorsque terminé, désactivez de suite les logs:

SET GLOBAL general_log = 0;

Le log est maintenant rempli de toutes les requêtes effectuées durant l’opération.  C’est là que commence l’analyse. …

Un ami me demandait aujourd’hui si une application qu’il utilise à son travail pourrait être plus performante si les tables étaient Innodb plutôt que MyISAM ? Oui. Non. Peut-être. Il n’y a pas de réponse à cette question; il y beaucoup trop de facteurs à considérer.

Peter Zaitsev a publié hier un article sur le sujet. Comme il indique, il faut d’abord s’interroger pour savoir “pourquoi” les tables sont MyISAM à la base. Le sont-ils pour une raison particulière ou parce qu’elles utilisent le storage engine par défaut de MySQL ?

Les 2 storages engines possèdent des avantages différents qui les rendent aussi performant l’un que l’autre, dépendamment de l’utilisation qu’on en fait. Pour répondre adéquatement à mon ami, il aurait fallu que je connaisse quel genre de requêtes son …

J’ai appris l’autre jour que iWeb Technologies, la compagnie pour laquelle je travaille, était un miroir de MySQL. Je trouve ça bien que iWeb fasse la promotion de solutions gratuites et opensource. Nous avons une bande passante de 43Gbps en ce moment, ce qui nous permet d’être miroir de plusieurs autres solutions tel que

• Debian
• CentOS
• Ubuntu
• Fedora
• Kernel.org
• MySQL
• Apache
• GNU
• Cpanel

Bref, plusieurs logiciels au coeur du développement Web “gratuit”. Toutes ces applications sont largement utilisées dans l’entreprise. C’est une belle manière de leur dire merci.