La société Oracle publie un livre blanc présentant une série de benchs comparant les performances en lecture/écriture et en lecture seule des moteurs de stockages InnoDB et MyISAM sur MySQL 5.5. Les résultats affichés indiquent des performances largement supérieures pour InnoDB sur des architectures multi-coeur alors que MyISAM reste à performance constante quel que soit [...]

La dernière version de XtraDB, le moteur de stockage proposé par Percona, dispose d’une fonctionnalité plutôt pertinente avec MySQL : La sauvegarde du cache InnoDB (InnoDB Buffer Pool)

Sauvegarder le cache, oui, mais pour quoi faire ?

Vous devez effectivement comprendre l’intérêt de la chose si vous vous êtes déjà frotté à l’administration d’un MySQL mais je dois vous avouer qu’en abordant le sujet pendant la pose café, tout le monde n’était pas forcement convaincu.

En effet, la mise en œuvre d’une telle fonctionnalité soulève une autre question : Pourquoi redémarrer MySQL ?

Effectivement, le véritable intérêt de cette sauvegarde est de pouvoir couper son MySQL sans perdre les informations stockées dans le cache. Intérêt évidemment compris de tous dans le cas d’un crash du serveur MySQL.

Dans les faits, XtraDB permet de sauvegarder et restaurer le cache même si il …

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 …

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 …

La clause, AUTO_INCREMENT, permet à MySQL de générer un entier unique pour tout nouvel enregistrement d’une table. Cette clause ne peut se mettre que sur les champs de type entier, indexé et non nul. Elle est donc souvent utilisée comme clé primaire.

Cependant, sont comportement n’est pas tout à fait identique sur une table MyISAM et sur une table InnoDB.

mysql> CREATE TABLE table_myisam (id INT AUTO_INCREMENT PRIMARY KEY) engine=MyISAM;

mysql> SHOW CREATE TABLE table_myisam;

CREATE TABLE `table_myisam` (

`id` int(11) NOT NULL AUTO_INCREMENT,

PRIMARY KEY (`id`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1

mysql> INSERT INTO table_myisam (id) VALUES (NULL),(NULL),(NULL),(100);

Query OK, 4 rows affected (0.02 sec)

Records: 4 Duplicates: 0 Warnings: 0

mysql> SELECT …

Est-il mauvais de stocker des fichiers dans MySQL ? Il n’y a pas de bonne ou mauvaise réponse à cette question. Tout dépend de vos besoins. Personnellement, je préfère stocker les fichiers à l’extérieur de la base de données pour les raisons suivantes:

• Le filesystem va mieux cacher les fichiers
• Le serveur MySQL va avoir plus de facilité à cacher les autres données
• Le débit de donnée du serveur va être moins élevé
• Il est plus facile de réorganiser et maintenir les fichiers
• Le tablespace demeure petit (si vous devez utiliser InnoDB)

Une bonne approche est de stocker un pointeur vers les fichiers sur le filesystem plutôt que le binaire du fichier directement dans la BD. Il y a cependant des avantages à les stocker dans la base de données:

• Toutes les données sont centralisées à une place pour les backups
• C’est plus …

Je me suis déjà fait avoir 2 fois par cette option. Si vous avez des tables InnoDB avec un gros load d’écriture (insert, update), il est généralement recommandé d’avoir un innodb_log_file_size assez élevé. Mais soyez vigilant: plus la grosseur du log file est élévée, plus le temps de recovery est long dans le cas d’un crash.

Mais peu importe. Là ou je veux en venir, c’est sur la manière de modifier cette option. InnoDB est un engine capricieux et innodb_log_file_size est l’un de ses caprices. Les logs jouent un rôle très important dans plusieurs concepts d’InnoDB. Il y stock un tas d’information comme le schema de certains .frm et d’autres metadata. Le problème est qu’on ne peut pas simplement modifier la grosseur du log dans le my.cnf et repartir le serveur. En fait oui, c’est possible et le serveur ne fera pas d’erreur. Mais aucune table InnoDB ne sera utilisable.

La manière …