Astuces de Webmaster

Optimiser mySQL :

• Identifiez-vous en root sur le Shell du serveur considéré
• Pour optimiser MySQL, on va s’intéresser principalement au fichier /etc/mysql/my.cnf (généralement ainsi situé, notamment sur les distributions Debian, mais n’hésitez pas à faire un # locate my.cnf pour identifier la localisation de ce fichier et vérifier s’il n’y a pas de doublon)
• nano /etc/mysql/my.cnf (éditons la configuration)


[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 16K
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 64K
# pour utiliser moins de mémoire, si on n'utilise pas Berkeley DB on ajoute cette ligne
skip-bdb
# idem si on n'utilise pas InnoDB
skip-innodb
# de la même façon, si on n'utilise pas InnoDB, on peut commenter les lignes suivantes
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# Vous pouvez définir .._buffer_pool_size entre 50 et 80 %
# de la RAM mais attention à ce que l'utilisation globale de RAM par MySQL ne soit pas trop important (à suivre)
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Définissez .._log_file_size à 25% du buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Décommentez la ligne suivante si vous n'êtes pas familier avec SQL
#safe-updates
[isamchk]
key_buffer = 8M
sort_buffer_size = 8M
[myisamchk]
key_buffer = 8M
sort_buffer_size = 8M
[mysqlhotcopy]
interactive-timeout

Quelques paramètres qui nécessitent attention

query_cache_size

MySQL fournit une fonctionnalité qui peut s’avérer très pratique : un cache de requêtes. Lorsqu’une même requête est exécutée plusieurs fois, et retourne les mêmes résultats à chaque fois, MySQL peut mettre en cache le résultat, ce qui décharge assez le serveur.

key_buffer

La valeur de key_buffer_size est la taille du buffer utilisé pour les index. Plus il y a de mémoire tampon, et plus rapidement la commande SQL se termine et un résultat sera retourné. La règle de base est de régler le key_buffer_size à au moins un quart, mais pas plus de la moitié de la quantité totale de mémoire sur le serveur. Idéalement, il sera assez grand pour contenir tous les index (la taille totale de tous les fichiers .MYI sur le serveur).

table_cache

La valeur par défaut est 64. Chaque fois que MySQL accède à une table, il la place dans le cache. Si le système accède à de nombreuses tables, il est plus efficace d’avoir ces tables dans le cache. MySQL, étant multi-thread, peut exécuter de nombreuses requêtes sur une table au même moment, et chacune de ces requête va ouvrir une connexion avec la table. Examinez la valeur de open_tables aux heures de pointe. Si vous trouvez qu’il reste à la même valeur que la valeur de votre table_cache, puis que le nombre de opened_tables commence à augmenter rapidement, il faut augmenter la taille du table_cache si vous avez suffisamment de mémoire disponible.

sort_buffer

Le sort_buffer est très utile pour accélérer les opérations myisamchk (c’est pourquoi il est défini beaucoup plus haut dans les fichiers de configuration par défaut), mais il peut aussi être utile lors de l’exécution quotidienne un grand nombre de classements (fonctions comme sort(),…).

thread_cache

Si vous avez un serveur surchargé à force de recevoir un grand nombre de connexions rapides, définissez votre thread_cache suffisamment haut pour que la valeur threads_created de SHOW STATUS (commande SQL) cesse d’augmenter. Cela devrait décharger un peu le CPU.

Autres optimisations MySQL

Bien souvent, c’est sur les jointures que se jouent les lenteurs. Utilisez les jointures à bon escient, vérifiez que pour chaque clé utilisée dans les jointures, il existe bien un index sur ce champ clé, sinon créez-le tout de suite et ça fera une grande différence.

Les chiffres pèsent moins lourd dans les index que les lettres, par conséquent, préférez les clés numériques pour vos jointures de grosses tables pour éviter de trop surcharger vos index.

Apache

Le principal problème avec Apache est la quantité de RAM qu’il utilise. Nous allons voir comment baisser la quantité de RAM utilisée par Apache.

• Charger moins de modules
• Faire moins de demandes simultanées
• Recycler les processus Apache
• Utiliser les KeepAlive, mais pas pour trop longtemps
• Réduire vos timeout
• Créer moins de logs
• ne pas résoudre pas les Hostname
• N’utilisez pas les .htaccess

Se connecter en SSH à un SGBD MySQL lorsque l’on est connecté en SSH

mysql -u UTILISATEUR -p

Une invite vous demande alors de taper le mot de passe. Si vous ne vous trompez pas, le prompteur est précédé de mysql> dorénavant pour signifier que vous êtes en invite de commande MySQL.

Sélectionner une base de données

(vous pouvez également la passer en paramètre dans la ligne de commande plus haut mais cette méthode permet davantage d’utilisations).

mysql> USE NOMBDD

Ce qui devrait vous renvoyer « Database changed »
doc

Faire des requêtes

Contrairement à PHPMyAdmin et compagnie, vous devez absolument terminer vos requêtes par un point virgule. Si vous ne le faites pas et que vous faites entrer, l’invite vous proposera de compléter votre requête jusqu’à ce que vous terminiez votre requête par un point virgule et que vous validiez.

Exécuter une liste de requêtes MySQL

Il suffit d’exécuter une commande du type

mysql -u[nomUtilisateur] -p [nomBaseDeDonnees] < "/chemin/vers/fichier_contenant_requetes.txt"

L’invite de commande vous demandera votre mot de passe puit affichera de nouveau le prompteur si tout se passe bien Evidemment, chaque requête doit être terminée par un point virgule.

Pour exporter les résultats d’une requête vers un fichier texte ou autre

Il ne faut pas être connecté sur le serveur MySQL : si vous êtes connecté, tapez la commande « exit; » pour vous retrouver sur le shell standard puis tapez cette commande :

mysql -u[nomUtilisateur] -p [nomBaseDeDonnees] < /tmp/sql.sql > /tmp/outfile.txt;

ou si vous êtes déjà dans l’invite MySQL

SELECT * FROM table WHERE 1 INTO OUTFILE ‘/tmp/testRequeteExport.sql’;

Voir la doc

Pour exporter une base vers un fichier

Il ne faut pas être connecté sur le serveur MySQL : si vous êtes connecté, tapez la commande « exit; » pour vous retrouver sur le shell standard puis tapez cette commande :

mysqldump -u[nomUtilisateur] -p [nomBaseDeDonnees] > /tmp/export_nomBaseDeDonnees.sql;

un prompt vous demandera le mot de passe de l’utilisateur en question

Pour exporter une table vers un fichier

Il ne faut pas être connecté sur le serveur MySQL : si vous êtes connecté, tapez la commande « exit; » pour vous retrouver sur le shell standard puis tapez cette commande :

mysqldump -u[nomUtilisateur] -p [nomBaseDeDonnees] [nomTable] > /tmp/export_nomBaseDeDonneesEtTable.sql;

un prompt vous demandera le mot de passe de l’utilisateur en question

MySQL est une des bases de données les plus utilisées sur Linux aujourd’hui, et une des problématiques les plus récurrentes est d’exporter sa base pour une raison ou une autre (exports sur d’autres serveurs, sauvegardes,…)

Une bonne commande pour faire cela est mysqldump, Pour faire cela, vous devez utiliser le shell (via putty par exemple) pour vous connecter sur votre serveur dédié ou sur votre poste de travail sous linux. Si vous êtes sur un serveur mutualisé, il faut que vous voyez avec votre hébergeur, pourquoi pas dans votre interface d’administration si vous en avez une.

MySQLDump prépare le script pour (re-)créer les tables et le contenu de celles-ci, prêt à être importé plus tard.

La commande au plus simple :

mysqldump -u [nomUtilisateur] -p [motDePasse] -B [nomBDD] > [fichierSauvegarde].dump

Si vous ne saisissez pas le mot de passe mais laissez -p il vous demandera de donner le mot de passe. Si vous souhaitez éviter de dévoiler le mot de passe dans l’historique, c’est mieux.

Vous pouvez également ajouter une option pour optimiser la requête.

mysqldump –opt -u [nomUtilisateur] -p [nomBDD] > [fichierSauvegarde].dump

Ceci permettra de supprimer les tables (DROP) avant qu’elles ne soient recréées puis remplies de leur contenu.

Pour des raisons évidentes de taille de base de données, il est parfois bien de compresser (gzipper) le fichier extrait :

mysqldump –opt -u [nomUtilisateur] -p [nomBDD] | gzip > [fichierSauvegarde].dump.gz

Le jour où vous souhaitez réimporter votre base, il suffit d’inverser la flèche. (Attention à dézipper le fichier au préalable – gunzip – s’il était gzippé)

mysql [nomBDD] < [fichierSauvegarde].dump

Pour savoir où sont les fichiers : commande pwd pour voir où vous êtes

La documentation Man de MysqlDump avec toutes les options :

http://www.manpagez.com/man/1/mysqldump/

Je viens de tomber sur un petit recueil d’astuces pour optimiser ses requêtes et sa base de données MySQL que j’aimerais partager avec vous.

Tout est ici : http://www.lephpfacile.com/manuel-mysql/mysql-optimization.php#tips

- vérifier les index / créés vs qui devraient exister
- types de tables (MyISAM,…)
- éviter les varchar et blob pour ce qui est régulièrement modifié
- pas forcément utile de scinder les grosses tables en plus petites
-…

Une petite check-list à se faire de temps en temps !

Le principe est simple : pour une montée linéaire du nombre de requêtes sur une table, le temps de réponse monte exponentiellement…

A partir de ce simple constat, vous avez compris qu’il est préférable de partitionner vos données soit en faisant plusieurs bases de données, soit en faisant plusieurs tables.

Tous les poids lourds des données utilisent cette méthode : le sharding.

Après cette petite introduction, voici quelques liens :

http://decrypt.ysance.com/2009/05/sharding-partitionnement-optimisation-acces-aux-donnees/
http://www.codefutures.com/database-sharding/
http://highscalability.com/unorthodox-approach-database-design-coming-shard
http://www.pythian.com/news/500/database-sharding-and-the-end-of-raid/

Fonction de MySQL injustement ignorée, FROM_UNIXTIME nous permet d’insérer en base un temps UNIX, et permet une sortie de date au format souhaité :

Source : http://dev.mysql.com/doc/refman/5.0/fr/date-and-time-functions.html

FROM_UNIXTIME(unix_timestamp)

Retourne une représentation de l’argument unix_timestamp sous la forme ‘YYYY-MM-DD HH:MM:SS’ ou YYYYMMDDHHMMSS, suivant si la fonction est utilisé dans un contexte numérique ou de chaîne.

mysql> SELECT FROM_UNIXTIME(875996580);
-> ’1997-10-04 22:23:00′
mysql> SELECT FROM_UNIXTIME(875996580) + 0;
-> 19971004222300

Si format est donné, le résultat est formaté en fonction de la chaîne format. format peut contenir les mêmes options de format que celles utilisées par DATE_FORMAT() :

mysql> SELECT FROM_UNIXTIME(UNIX_TIMESTAMP(),
-> ‘%Y %D %M %h:%i:%s %x’);
-> ’2003 6th August 06:22:58 2003′

Une page qui m’a servi pas plus tard qu’aujourd’hui, et dont je recommande la (re-)lecture à tous tant elle est pratique :
http://www.vulgarisation-informatique.com/optimiser-mysql.php

L’idée est d’aller chercher les requêtes les plus lourdes que vous avez (si vous avez un serveur dédié, allez fouiller dans le fichier slow-query.log qui enregistre toutes les requêtes durant plus de 5 secondes), de faire un « EXPLAIN [votre requête] » et point par point de voir où il manque des index,… de colmater les brèches en quelque sorte..

Bonne lecture,

Je vous invite à lire cette documentation qui permet d’optimiser les requêtes complexes pour des sites à fort volume :

http://www.ecoms.fr/cours/sgbdoptimisation.pdf [PDF]