10.16 Comment faire tourner MySQL à pleine vitesse?

Commencez par tester votre installation ! Vous pouvez prendre n'importe quel programme de la suite de test MySQL (normalement fournie dans le dossier ``sql-bench'') et la modifier selon vos besoin. Vous pourrez ainsi essayer différentes solutions, et trouver celle qui est le plus rapide :@:

• Démarrez mysqld avec les options adéquates. Plus de mémoire accélère MySQL, si vous en avez.. 10.1 Optimisation des valeurs du serveur.
• Créez des index pour rendre vos sélections rapides. 10.4 Utilisation des index.
• Optimisez vos types de colonnes pour qu'ils soient aussi efficient que possible. Par exemple, déclarez les colonnes NOT NULL si possible. 10.12 Comment constituer une table pour qu'elle soit petite et rapide?.
• MySQL a deux niveaux de verrouillage :@: un verrouillage interne, un verrouillage externe. Le verrouillage interne s'assure que les modification / lecture d'informations sont atomiques et ne s'exécutent pas de manière concurente. Le verrouillage externe permet d'avoir plusieurs serveurs MySQL qyu utilisent les mêmes données, mais aussi d'utiliser isamchk pour vérifier les tables sans arrêter le serveur mysqld. L'option --skip-locking désactive le verrouillage externe entre deux requête SQL. Cela accélère les traitements mais il y a des inconvénients :
  • Vous devez ABSOLUMENT exécuter mysqladmin flush-tables avec de vérifier et réparer des tables avec isamchk. (isamchk -d nom_table est toujours autorisé, car c'est un simple affichage d'informations).
  • Il est impossible d'exécuter deux serveurs MySQL sur les mêmes données, car il y a un risque d'accès concurent.

L'option --skip-locking est mise par défaut lors de la compilation avec MIT-pthreads, car flock()n'est pas supporté par MIT-pthreads sur toutes les plate-formes. Le seul ca où il est impossible d'utiliser --skip-locking est lorsque vous avez plusieurs SERVEUR MySQL (pas les clients) avec les mêmes données (ou bien exécutez isamchk sur une table sans avoir vidé les tables de la mémoire). Vous pouvez toujours utiliser use LOCK TABLES / UNLOCK TABLES même si vous avec mis l'option --skip-locking

• Si les modifications posent des problèmes, vous pouvez les reportez puis les regrouper pour une exécution ultérieure. Les modifications multiples sont beaucoup plus rapides que des modifications uniques.
• Sous FreeBSD, si le problème vient des MIT-pthreads, la mise à jour vers la version FreeBSD 3.0 (ou plus récent) devrait résoudre les problèmes.. Cette mise à jour rend possible l'utilisation des sockets Unix (avec FreeBSD, c'est beaucoup plus rapide que TCP/IP avec MIT-pthreads) et le package de threads est bien mieux intégré.
• La vérification de droits sur une table au niveau des colonnes dégrade sérieusement les performances.

Si votre problème porte sur une fonction particulière de MySQL, vous pouvez toujours la chronométrer avec le client MySQL:@:

mysql> select benchmark(1000000,1+1);
+------------------------+
| benchmark(1000000,1+1) |
+------------------------+
| 0 |
+------------------------+
1 row in set (0.32 sec)

L'exemple ci dessus montre que MySQL peut exécuter plus de 1,000,000 de fois l'expressions en 0.32 seconde sur un simple PentiumII 400MHz.

Toutes les fonctions MySQL sont très optimisées ; mais il peut y avoir des exceptions, et l'utilitaire benchmark(loop_count,expression) est un bon outil pour étudier votre problème.