Manuel de référence MySQL 5.0

Tous les programmes MySQL prennent des options différentes. Toutefois, tous les programmes MySQL disposent de l'option --help qui vous aidera à connaître la liste complète des différentes options. Par exemple, essayez mysql --help.

Vous pouvez modifier toutes les valeurs par défaut des programmes en les plaçant dans le fichier de configuration. Section 4.3.2, « Fichier d'options my.cnf »4.3.2. Fichier d'options my.cnf.

Voici la liste des programmes côté serveur de MySQL.

• mysqld

  Le démon SQL (c'est-à-dire, le serveur MySQL). Pour utiliser les programmes clients, ce programme doit fonctionner, car les clients viendront se connecter dessus. Voir Section 5.2, « Configuration de MySQL »5.2. Configuration de MySQL.

• mysqld-max

  Une version du serveur qui inclut des fonctionnalités supplémentaires. Voir Section 5.1.2, « mysqld-max, la version étendue du serveur mysqld »5.1.2. mysqld-max, la version étendue du serveur mysqld.

• mysqld_safe

  Un script de démarrage du serveur. mysqld_safe tente de démarrer mysqld-max s'il existe, et sinon mysqld. Voir Section 5.1.3, « safe_mysqld, le script père de mysqld »5.1.3. safe_mysqld, le script père de mysqld.

• mysql.server

  Un script de démarrage du serveur. Ce script est utilisé sur les systèmes qui ont un dossier contenant des services système. Il invoque mysqld_safe pour démarrer le serveur MySQL. Voir Section 5.1.4, « Le script de démarrage mysql.server »5.1.4. Le script de démarrage mysql.server.

• mysqld_multi

  Un script de démarrage qui peut lancer ou arrêter différentes instances du serveur, installées sur le système. Voir Section 5.1.5, « mysqld_multi, un programme pour gérer plusieurs serveurs MySQL »5.1.5. mysqld_multi, un programme pour gérer plusieurs serveurs MySQL.

• mysql_install_db

  Crée les tables de droits MySQL, avec les droits par défaut. Il est généralement exécuté une fois, lors de la première installation de MySQL.

• mysql_fix_privilege_tables

  Ce script est utilisé après une mise à jour de MySQL, pour mettre à jour les tables de droits, et les adapter aux nouvelles versions de MySQL.

Il y a plusieurs autres utilitaires qui fonctionnent du côté du serveur.

• myisamchk

  Un utilitaire pour décrire, vérifier, optimiser et réparer les tables MyISAM. myisamchk est décrit dans Section 5.7.3, « Utilisation de myisamchk pour la maintenance des tables et leur recouvrement »5.7.3. Utilisation de myisamchk pour la maintenance des tables et leur recouvrement.

• make_binary_distribution

  Ce programme crée une version compilée de MySQL. Le résultat peut être envoyé par FTP à /pub/mysql/Incoming sur support.mysql.com pour aider les autres utilisateurs MySQL.

• mysqlbug

  Le script de rapport de bogues de MySQL. Il peut être utilisé pour envoyer un rapport de bogues à MySQL. Vous pouvez aussi aller sur http://bugs.mysql.com/ pour remplir un formulaire en ligne.

Le serveur MySQL-Max est une version du serveur mysqld qui a été compilée avec des fonctionnalités supplémentaires.

La distribution à utiliser dépend de votre plate-forme.

• Sous Windows, les distributions binaires MySQL incluent le serveur standard (mysqld.exe) et le serveur MySQL-Max (mysqld-max.exe), alors il n'y a pas de téléchargement spécial à faire. Utilisez simplement la distribution Windows habituelle, disponible sur http://dev.mysql.com/downloads/mysql-4.0.html. Voir Section 2.2.1, « Installer MySQL sous Windows »2.2.1. Installer MySQL sous Windows.

• Sous Linux, si vous installez une distribution RPM, utilisez le RPM MySQL-server standard pour installer le serveur mysqld. Puis, utilisez le RPM MySQL-Max pour installer le serveur mysqld-max. Le RPM MySQL-Max suppose que vous avez déjà installé le serveur régulier RPM. Voyez Section 2.2.12, « Installer MySQL sous Linux »2.2.12. Installer MySQL sous Linux pour plus d'informations sur les paquets Linux RPM.

• Toutes les autres distributions de MySQL-Max contiennent un serveur unique, appelé mysqld, mais qui inclut les fonctionnalités supplémentaires.

Vous pouvez trouver les distributions binaires sur le site web de MySQL AB, sur http://dev.mysql.com/downloads/mysql-4.0.html.

MySQL AB compile le serveur MySQL-Max avec les options de configure suivantes.

• --with-server-suffix=-max

  Cette option ajoute le suffixe -max à la chaîne de version de mysqld.

• --with-innodb

  Cette option active le support du moteur InnoDB. MySQL-Max inclut toujours le support d'InnoDB, mais cette option est nécessaire pour MySQL 3.23. Depuis MySQL 4, InnoDB est inclus par défaut dans les distributions binaires, alors il n'est pas nécessaire d'utiliser MySQL-Max pour ça.

• --with-bdb

  Cette option active le support du moteur de table Berkeley DB (BDB).

• CFLAGS=-DUSE_SYMDIR

  Cette option active le support des liens symboliques sous Windows.

Les distributions binaires de MySQL-Max sont disponibles pour ceux qui souhaitent installer une version précompilée. Si vous voulez compiler MySQL-Max depuis les sources, vous pouvez le faire et choisir les fonctionnalités que vous souhaitez au moment de la compilation.

Le serveur MySQL-Max inclut le moteur de stockage BerkeleyDB (BDB) lorsque c'est possible, mais toutes les plates-formes ne supportent pas BDB. La table suivante montre quelles plates-formes permettent à MySQL-Max d'inclure BDB :

Pour connaître les moteurs de stockage que votre serveur supporte, utilisez la commande suivante :

mysql> SHOW ENGINES;

Avant MySQL 4.1.2, SHOW ENGINES est indisponible. Utilisez la commande suivante et vérifiez la valeur de la variable pour le moteur de tables qui vous intéresse :

mysql> SHOW VARIABLES LIKE 'have_%';
+------------------+----------+
| Variable_name    | Value    |
+------------------+----------+
| have_bdb         | NO       |
| have_crypt       | YES      |
| have_innodb      | YES      |
| have_isam        | NO       |
| have_raid        | NO       |
| have_symlink     | DISABLED |
| have_openssl     | NO       |
| have_query_cache | YES      |
+------------------+----------+

La signification des valeurs est :

La valeur NO signifie que le serveur a été compilé sans le support, et que la fonctionnalité ne peut pas être activée durant l'exécution.

La valeur de DISABLED apparait soit parce que le serveur a été lancé sans l'option qui active cette fonctionnalité, soit si toutes les options nécessaires ne sont pas disponibles. Dans ce dernier cas, le fichier d'erreurs host_name.err devrait contenir la raison indiquant pourquoi l'option a été désactivée.

Une situation dans laquelle vous pouvez voir DISABLED survient en version MySQL 3.23, lorsque le moteur InnoDB est compilé. En MySQL 3.23, vous devez fournir au moins l'option innodb_data_file_path à l'exécution pour configurer l'espace de tables InnoDB. Sans cette option, InnoDB se désactive. Voir Section 15.3, « InnoDB avec MySQL version 3.23 »15.3. InnoDB avec MySQL version 3.23. Vous pouvez spécifier les options de configuration pour les tables BDB, mais BDB ne se désactivera pas de lui-même si vous les oubliez. Voir Section 14.4.3, « Options de démarrage BDB »14.4.3. Options de démarrage BDB.

Vous pouvez aussi rencontrer la valeur de DISABLED pour InnoDB, BDB, ou ISAM si le serveur a été compilé pour les supporter, mais également les options de démarrage --skip-innodb, --skip-bdb ou --skip-isam à l'exécution.

Depuis la version 3.23, tous les serveurs MySQL supportent les tables MyISAM, car le moteur MyISAM est le moteur par défaut.

safe_mysqld est la méthode recommandée pour démarrer un démon mysqld sous Unix. safe_mysqld ajoute des fonctionnalités de sécurité telles que le redémarrage automatique lorsqu'une erreur survient et l'enregistrement d'informations d'exécution dans un fichier de logs.

Note : avant MySQL 4.0, mysqld_safe s'appelait safe_mysqld. Pour préserver la compatibilité ascendante, la distribution binaire MySQL propose un lien symbolique de safe_mysqld vers mysqld_safe.

Par défaut, mysqld_safe essaie de lancer l'exécutable appelé mysqld-max s'il existe, ou mysqld sinon. Cela a des implications.

• Sous Linux, le RPM MySQL-Max dépend de mysqld_safe. Le RPM installe un exécutable appelé mysqld-max, qui fait que mysqld_safe va automatiquement utiliser l'exécutable installé.

• Si vous installez la distribution MySQL-Max qui inclut un serveur appelé mysqld-max, puis que vous le mettez à jour avec une version non max, mysqld_safe va essayer d'utiliser l'ancien serveur mysqld-max. Si vous faites une telle mise à jour, supprimez manuellement l'ancien serveur mysqld-max pour vous assurer que mysqld_safe utilise le nouveau mysqld.

Pour remplacer le comportement par défaut et spécifier explicitement le serveur que vous voulez utiliser, spécifiez l'option --mysqld ou --mysqld-version avec mysqld_safe.

De nombreuses options de mysqld_safe sont identiques aux options de mysqld. Voir Section 5.2.1, « Options de ligne de commande de mysqld »5.2.1. Options de ligne de commande de mysqld.

Toutes les options spécifiées avec mysqld_safe en ligne de commande sont passées à mysqld. Si vous voulez utiliser des options qui sont spécifiques à mysqld_safe et que mysqld ne les supporte pas, ne les spécifiez pas en ligne de commande. Au lieu de cela, listez-les dans le groupe [mysqld_safe] du fichier d'options. Voir Section 4.3.2, « Fichier d'options my.cnf »4.3.2. Fichier d'options my.cnf.

mysqld_safe lit toutes les options des groupes [mysqld], [server] et [mysqld_safe] dans le fichier d'options. Pour assurer la compatibilité ascendante, il lit aussi le groupe [safe_mysqld]. Vous devriez renommer ces sections [mysqld_safe] lorsque vous passez à MySQL 4.0 ou plus récent.

safe_mysqld supporte les options suivantes.

• --basedir=path

  Le chemin jusqu'à l'installation de MySQL.

• --core-file-size=#

  Taille du fichier core que mysqld doit être capable de créer. Il est passé à ulimit -c.

• --datadir=path

  Le chemin jusqu'au dossier de données.

• --defaults-extra-file=path

  Le nom du fichier d'options à lire en plus des fichiers habituels.

• --defaults-file=path

  Le nom d'un fichier d'options qui doit être lu à la place du fichier d'options habituel.

• --err-log=path

  L'ancienne option --log-error, à utiliser avant MySQL 4.0.

• --ledir=path

  Le chemin jusqu'au dossier contenant le dossier mysqld. Utilisez cette option pour indiquer explicitement le lieu du serveur.

• --log-error=path

  Écrit le fichier d'erreurs dans le fichier ci-dessus. Voir Section 5.9.1, « Le log d'erreurs »5.9.1. Le log d'erreurs.

• --mysqld=prog_name

  Le nom du programme serveur (dans le dossier ledir) que vous voulez lancer. Cette option est nécessaire si vous utilisez une distribution binaire MySQL, mais que les données sont hors du dossier d'installation.

• --mysqld-version=suffix

  Cette option est similaire à l'option --mysqld, mais vous spécifiez uniquement le suffixe du nom du programme. Le nom de base sera alors mysqld. Par exemple, si vous utilisez --mysqld-version=max, mysqld_safe va lancer le programme mysqld-max dans le dossier ledir. Si l'argument de --mysqld-version est vide, mysqld_safe utilise mysqld dans le dossier ledir.

• --nice=priority

  Utilise le programme nice pour donner la priorité du serveur. Cette option a été ajoutée en MySQL 4.0.14.

• --no-defaults

  Ne lit aucun fichier d'options.

• --open-files-limit=count

  Le nombre de fichiers que mysqld ouvre au maximum. La valeur de l'option est passée à ulimit -n. Notez que vous devez lancer mysqld_safe en tant que root pour que cela fonctionne correctement.

• --pid-file=path

  Le chemin jusqu'au fichier d'identifiant de processus.

• --port=port_num

  Le numéro de port à utiliser pour attendre les connexions TCP/IP.

• --socket=path

  Le fichier de socket Unix pour les connexions locales.

• --timezone=zone

  Configure la variable d'environnement TZ. Consultez votre documentation système pour connaître le format légal des fuseaux horaires.

• --user={user_name | user_id}

  Lance le serveur mysqld sous le nom d'utilisateur user_name ou avec l'utilisateur d'identifiant numérique ID user_id. (« Utilisateur » dans ce contexte représente le compte système, et non pas les utilisateurs des tables de droits MySQL).

Le script safe_mysqld a été écrit pour qu'il soit capable de démarrer le serveur qui a été installé à partir des sources ou de la version binaire, même si l'installation de MySQL est légèrement exotique. Voir Section 2.1.5, « Dispositions d'installation »2.1.5. Dispositions d'installation. safe_mysqld suppose que les conditions suivantes sont remplies :

• le serveur et les bases de données sont placés dans un dossier relativement au dossier d'où safe_mysqld est appelé. safe_mysqld cherche dans les sous-dossiers bin et data (pour les distributions binaires) et, libexec et var (pour les distributions source). Cette condition doit être remplie si vous exécutez safe_mysqld depuis votre dossier d'installation MySQL (par exemple, /usr/local/mysql pour une distribution binaire) ;

• si le serveur et les bases de données ne peuvent être trouvés dans le dossier de travail, safe_mysqld essaie de les trouver en utilisant leur chemin absolu. Les chemins typiquement étudiés sont /usr/local/libexec et /usr/local/var. Les chemins réels sont déterminés lorsque la distribution est compilée, et safe_mysqld a alors aussi été généré. Ils doivent être corrects si MySQL a été installé dans un dossier standard.

Comme safe_mysqld essaie de trouver le serveur et les bases dans un dossier situé dans le dossier de travail, vous pouvez installer la version binaire de MySQL n'importe où, du moment que vous démarrez le script safe_mysqld dans le dossier d'installation de MySQL :

shell> cd mysql_installation_directory
shell> bin/safe_mysqld &

Si safe_mysqld échoue, même s'il est appelé depuis le dossier d'installation, vous pouvez le modifier pour qu'il reconnaisse le chemin que vous utilisez jusqu'à mysqld. Notez que si vous faites évoluer votre installation de MySQL, votre version de safe_mysqld sera écrasée, et vous devrez la rééditer.

Normalement, vous ne devez pas éditer le script mysqld_safe. Au lieu de cela, configurez mysqld_safe en utilisant les options de ligne de commande, ou les options de la section [mysqld_safe] du fichier d'options my.cnf. Dans de rares cas, il sera peut-être nécessaire d'éditer mysqld_safe pour faire fonctionner correctement le serveur. Cependant, si vous faites cela, mysqld_safe risque d'être écrasé lors de la prochaine mise à jour de MySQL : faites-en une sauvegarde avant d'installer.

Sous NetWare, mysqld_safe est un NetWare Loadable Module (NLM) qui est un port du script Unix original. Il fait ceci :

1. Effectue des vérifications système et des options ;

2. Lance la vérification des tables MyISAM et ISAM ;

3. Affiche un écran de présence de MySQL ;

4. Lance mysqld, le surveille et le relance s'il s'arrête sur une erreur ;

5. Envoie les messages de mysqld dans le fichier host_name.err dans le dossier de données ;

6. Envoie les affichages de mysqld_safe dans le fichier host_name.safe dans le dossier de données.

Les distributions MySQL sous Unix incluent un script appelé mysql.server. Il peut être utilisé pour lancer et arrêter les services. Il est aussi utilisé par le script de démarrage de Max OS X.

mysql.server est placé dans le dossier support-files sous le dossier d'installation de MYSQL, ou dans le dossier de source.

Si vous utilisez le paquet RPM pour Linux (MySQL-server-VERSION.rpm), le script mysql.server sera déjà installé dans le dossier /etc/init.d sous le nom de mysql. Vous n'avez pas besoin de l'installer manuellement. Voyez Section 2.2.12, « Installer MySQL sous Linux »2.2.12. Installer MySQL sous Linux pour plus d'informations sur les paquets MySQL RPM Linux.

Certains éditeurs fournissent des paquets RPM qui installent un script de démarrage sous le nom de mysqld.

Si vous installez MySQL depuis une distribution source, ou en utilisant une distribution binaire qui n'installe pas automatiquement le fichier mysql.server, vous pouvez l'installer manuellement. Les instructions sont fournies dans la section Section 2.5.2.2, « Lancer et arrêter MySQL automatiquement »2.5.2.2. Lancer et arrêter MySQL automatiquement.

mysql.server lit les options dans les sections [mysql.server] et [mysqld] du fichier de configuration. Pour la compatibilité ascendante, il lit aussi la section [mysql_server], même si vous devrez la renommer en [mysql.server] lorsque vous commencerez à utiliser MySQL 4.0.

mysqld_multi sert à gérer plusieurs serveurs mysqld qui utilisent différentes sockets Unix et ports TCP/IP.

Le programme va rechercher les groupes nommés [mysqld#] dans le fichier my.cnf (ou le fichier appelé --config-file=...), où # peut être n'importe quel nombre positif, supérieur ou égal à 1. Ce nombre est appelé le numéro de groupe d'options. Les numéros de groupe permettent de distinguer un groupe d'options d'un autre, et sont utilisés comme argument du script mysqld_multi pour spécifier quel serveur vous voulez démarrer, arrêter ou examiner. Les options listées dans ces groupes doivent être les mêmes que celles que vous utiliseriez dans une section dédiée au démon [mysqld]. Voyez, par exemple, Section 2.5.2.2, « Lancer et arrêter MySQL automatiquement »2.5.2.2. Lancer et arrêter MySQL automatiquement. Cependant, pour mysqld_multi, vous devez vous assurer que chaque groupe contient des valeurs pour les options telles que port, socket, etc., qui seront utilisées par chaque processus mysqld. Pour plus d'informations sur les options de chaque serveur dans un environnement à serveurs multiples, voyez la section Section 5.10, « Faire fonctionner plusieurs serveurs MySQL sur la même machine »5.10. Faire fonctionner plusieurs serveurs MySQL sur la même machine.

mysqld_multi est utilisé avec la syntaxe suivante :

shell> mysqld_multi [options] {start|stop|report} [GNR[,GNR]...]

start, stop et report indiquent le type d'opération que vous voulez faire. Vous pouvez faire une opération sur un serveur unique ou plusieurs serveurs, en fonction de la liste GNR qui suit le nom de l'opération. S'il n'y a pas de liste, mysqld_multi effectue l'opération sur tous les serveurs du fichier d'options.

Chaque GNR représente un numéro de groupe d'options. Vous pouvez démarrer, arrêter ou examiner n'importe quel numéro de groupe d'options, ou même plusieurs d'entre eux en même temps. Par exemple, le groupe GNR pour le groupe appelé [mysqld17] est 17. Pour spécifier un intervalle de nombres, séparez le premier et le dernier numéro par un tiret. La valeur GNR 10-13 représente les groupes de [mysqld10] à [mysqld13]. Les groupes multiples ou les intervalles de groupes peuvent être spécifiés en ligne de commande, séparés par des virgules. Il ne doit pas y avoir d'espace blanc entre deux éléments de la liste : tout ce qui sera après un espace sera ignoré.

Cette commande lance un serveur unique, avec le groupe d'options [mysqld17] :

shell> mysqld_multi start 17

Cette commande arrête plusieurs serveurs, en utilisant les groupes d'options [mysql8] et [mysqld10] à [mysqld13] :

shell> mysqld_multi start 8,10-13

Pour afficher un exemple de configurations, utilisez cette commande :

shell> mysqld_multi --example

Les valeurs de numéro de groupe d'options peuvent être une liste de valeurs séparées par une virgule ou un tiret. Dans ce dernier cas, tous les numéros de groupe d'options situés entre les deux numéros seront alors affectés. Sans numéro de groupe d'options spécifié, tous les numéros de groupes du fichier d'options sont affectés. Notez que vous ne devez pas avoir d'espace dans la liste des numéros de groupe d'options. Tout ce qui est placé au-delà de l'espace sera ignoré.

mysqld_multi supporte les options suivantes.

• --config-file=name

  Un fichier de configuration alternatif. Note : cela ne va pas modifier les options de ce programme ([mysqld_multi]), mais uniquement les groupes [mysqld#]. Sans cette option, tout sera lu dans le fichier d'options traditionnel my.cnf. Cette option n'affecte pas la façon avec laquelle mysqld_multi lit ses options, qui sont toujours prises dans le groupe [mysqld_multi] du fichier my.cnf habituel.

• --example

  Affiche un exemple de fichier de configuration.

• --help

  Affiche l'aide et quitte.

• --log=name

  Fichier de log. Le chemin complet et le nom du fichier sont nécessaires.

• --mysqladmin=prog_name

  L'exécutable mysqladmin à utiliser lors de l'arrêt du serveur.

• --mysqld=prog_name

  L'exécutable mysqld à utiliser. Notez que vous pouvez donner cette option à safe_mysqld. Ces options sont passées à mysqld. Assurez-vous que vous avez bien mysqld dans votre variable d'environnement PATH ou corrigez safe_mysqld.

• --no-log

  Affiche les données d'historique à l'écran plutôt que dans le fichier de logs. Par défaut, le fichier de logs est activé.

• --password=password

  Le mot de passe de l'utilisateur mysqladmin.

• --tcp-ip

  Connexion au serveur MySQL via le port TCP/IP au lieu du socket Unix. Cela affecte l'arrêt et le rapport. Si le fichier de socket manque, le serveur peut continuer de tourner, mais il n'est plus accessible que par port TCP/IP. Par défaut, les connexions sont faites avec les sockets Unix.

• --user=user_name

  L'utilisateur MySQL pour mysqladmin.

• --version

  Affiche le numéro de version et quitte.

Quelques notes pour mysqld_multi.

• Assurez-vous que l'utilisateur MySQL, qui stoppe les services mysqld (e.g en utilisant la commande mysqladmin), a les mêmes nom d'utilisateur et mot de passe pour tous les dossiers de données utilisés. Et assurez-vous que cet utilisateur a bien les droits de SHUTDOWN ! Si vous avez de nombreux dossiers de données et de nombreuses bases mysql avec différents mots de passe pour le serveur root MySQL, vous souhaiterez peut-être créer un utilisateur commun multi_admin à chaque base, avec le même mot de passe (voir ci-dessous). Voici comment faire :

   

  Sélectionnez

  shell> mysql -u root -S /tmp/mysql.sock -proot_password -e
  "GRANT SHUTDOWN ON *.* TO multi_admin@localhost IDENTIFIED BY 'multipass'"

  Voir Section 5.5.2, « Comment fonctionne le système de droits »5.5.2. Comment fonctionne le système de droits. Vous devrez utiliser la même commande pour chaque serveur mysqld qui fonctionne : changez simplement la socket, -S=...).

• pid-file est très important, si vous utilisez safe_mysqld pour démarrer mysqld (e.g., --mysqld=safe_mysqld). Chaque mysqld doit avoir son propre fichier pid-file. L'avantage d'utiliser safe_mysqld au lieu de mysqld est que safe_mysqld « surveille » tous les processus mysqld et les redémarrera si un processus mysqld s'arrête suite à la réception d'un signal kill -9, ou pour toute autre raison comme une erreur de segmentation (que MySQL ne devrait jamais faire, bien sûr !). Notez bien que le script safe_mysqld vous imposera peut-être d'être démarré depuis un dossier spécial. Cela signifie que vous devrez probablement utiliser la commande shell cd jusqu'à un certain dossier avant de pouvoir exécuter mysqld_multi. Si vous avez des problèmes pour démarrer, voyez le script safe_mysqld. Vérifiez notamment ces lignes :

   

  Sélectionnez

  ----------------------------------------------------------------
  MY_PWD=`pwd`
  # Check if we are starting this relative (for the binary release)
  if test -d $MY_PWD/data/mysql -a -f ./share/mysql/english/errmsg.sys -a \
   -x ./bin/mysqld
  ----------------------------------------------------------------

  Voir Section 5.1.3, « safe_mysqld, le script père de mysqld »5.1.3. safe_mysqld, le script père de mysqld. Le test ci-dessus devrait fonctionner, ou bien vous rencontrerez probablement des problèmes.

• Le fichier de socket et le port TCP/IP doivent être différents pour chaque mysqld.

• Vous pouvez utiliser l'option --user de mysqld, mais afin de faire cela, vous devez exécuter le script mysqld_multi en tant que root Unix. Placer cette option dans le fichier de configuration ne changera rien : vous obtiendrez une alerte, si vous n'êtes pas le superutilisateur, et les démons mysqld seront démarrés avec vos droits Unix.

• Important : assurez-vous bien que le fichier de données et le fichier de pid-file sont accessibles en lecture et écriture (et exécution pour le dernier) à l'utilisateur Unix qui lance les processus mysqld. N'utilisez pas le compte root Unix pour cela, à moins que vous ne sachiez ce que vous faites.

• Très important : assurez-vous de bien comprendre la signification des options que vous passez à mysqlds et pourquoi vous avez besoin de plusieurs processus mysqld. Méfiez-vous des pièges des serveurs multiples mysqld dans le même dossier de données. Utilisez des dossiers de données à moins que vous ne sachiez ce que vous faites. Démarrer plusieurs serveurs mysqlds dans le même dossier ne vous donnera aucun gain de performance dans un système threadé. Voir Section 5.10, « Faire fonctionner plusieurs serveurs MySQL sur la même machine »5.10. Faire fonctionner plusieurs serveurs MySQL sur la même machine.

Voici un exemple de fichier de configuration fourni par mysqld_multi.

# This file should probably be in your home dir (~/.my.cnf) or /etc/my.cnf
# Version 2.1 by Jani Tolonen

[mysqld_multi]
mysqld     = /usr/local/bin/safe_mysqld
mysqladmin = /usr/local/bin/mysqladmin
user       = multi_admin
password   = multipass

[mysqld2]
socket     = /tmp/mysql.sock2
port       = 3307
pid-file   = /usr/local/mysql/var2/hostname.pid2
datadir    = /usr/local/mysql/var2
language   = /usr/local/share/mysql/english
user       = john

[mysqld3]
socket     = /tmp/mysql.sock3
port       = 3308
pid-file   = /usr/local/mysql/var3/hostname.pid3
datadir    = /usr/local/mysql/var3
language   = /usr/local/share/mysql/swedish
user       = monty

[mysqld4]
socket     = /tmp/mysql.sock4
port       = 3309
pid-file   = /usr/local/mysql/var4/hostname.pid4
datadir    = /usr/local/mysql/var4
language   = /usr/local/share/mysql/estonia
user       = tonu

[mysqld6]
socket     = /tmp/mysql.sock6
port       = 3311
pid-file   = /usr/local/mysql/var6/hostname.pid6
datadir    = /usr/local/mysql/var6
language   = /usr/local/share/mysql/japanese
user       = jani

Voir Section 4.3.2, « Fichier d'options my.cnf »4.3.2. Fichier d'options my.cnf.

Lorsque vous démarrez le serveur mysqld, vous pouvez spécifier les options de programme en utilisant les méthodes décrites dans la section Section 4.3, « Spécifier des options aux programmes »4.3. Spécifier des options aux programmes. Les méthodes les plus courantes sont celles du fichier d'options et celles de la ligne de commande. Cependant, dans la plupart des cas, vous devrez vous assurer que le serveur utilise toujours les mêmes options à chaque redémarrage : il est recommandé de les mettre dans le fichier d'options. Voir Section 4.3.2, « Fichier d'options my.cnf »4.3.2. Fichier d'options my.cnf.

mysqld et mysqld.server lisent les options des groupes mysqld et server. mysqld_safe lit les options des groupes mysqld, server, mysqld_safe et safe_mysqld. Un serveur MySQL intégré lit généralement les options dans les groupes server, embedded et xxxxx_SERVER, où xxxxx est le nom de l'application.

mysqld accepte de nombreuses options de ligne de commande. Pour une liste complète, utilisez la commande mysqld --help. Avant MySQL 4.1.1, --help affiche un message d'aide complet. Depuis 4.1.1, il affiche un bref message. Pour voir la liste complète, utilisez mysqld --verbose --help.

La liste suivante montre les options de serveur les plus courantes. Les options supplémentaires sont détaillées ailleurs.

• Options qui affectent la sécurité : voir Section 5.4.3, « Options de démarrage qui concernent la sécurité »5.4.3. Options de démarrage qui concernent la sécurité.

• Options liées à SSL : voir Section 5.6.7.5, « Options SSL en ligne de commande »5.6.7.5. Options SSL en ligne de commande.

• Options de contrôle des logs binaires : voir Section 5.9.4, « Le log binaire »5.9.4. Le log binaire.

• Options de réplication : voir Section 6.8, « Options de démarrage de la réplication »6.8. Options de démarrage de la réplication.

• Options spécifiques à un moteur de table particulier : voir Section 14.1.1, « Options de démarrage MyISAM »14.1.1. Options de démarrage MyISAM, Section 14.4.3, « Options de démarrage BDB »14.4.3. Options de démarrage BDB, Section 15.5, « Options de démarrage InnoDB »15.5. Options de démarrage InnoDB.

Vous pouvez aussi modifier les valeurs des variables système en utilisant le nom de l'option comme variable système, tel que décrit ultérieurement.

• --help, -?

  Affiche l'aide courte et termine le programme. Avant MySQL 4.1.1, --help affiche un message d'aide complet. Depuis 4.1.1, il affiche un bref message. Pour voir la liste complète, utilisez mysqld --verbose --help.

• --allow-suspicious-udfs

  Cette option contrôle le fait que les fonctions utilisateur qui disposent d'un seul symbole xxx puissent être chargées. Par défaut, cette option est désactivée, et seules les UDF qui ont au moins un symbole auxiliaire peuvent être chargées. Cela évite de charger des fonctions issues d'un objet partagé qui ne serait pas une fonction utilisateur légitime. Cette option a été ajoutée en MySQL 4.0.24, 4.1.10a et 5.0.3. Voir Section 27.2.3.6, « Précautions à prendre avec les fonctions utilisateur »27.2.3.6. Précautions à prendre avec les fonctions utilisateur.

• --ansi

  Utilise la syntaxe ANSI SQL au lieu de la syntaxe MySQL. Voir Section 1.5.3, « Exécuter MySQL en mode ANSI »1.5.3. Exécuter MySQL en mode ANSI. Pour un contrôle plus précis sur le mode SQL serveur, utilisez l'option --sql-mode.

• --basedir=path, -b path

  Chemin jusqu'au dossier d'installation. Tous les chemins sont généralement relatifs à celui-ci.

• --big-tables

  Autorise la sauvegarde de grands résultats dans des fichiers temporaires. Cela résout le problème des erreurs « table full », mais ralentit les requêtes alors que des tables en mémoire suffiraient. Depuis la version 3.23.2, MySQL est capable de résoudre automatiquement ce problème en utilisant de la mémoire pour toutes les tables temporaires de petite taille, et en passant sur le disque au besoin.

• --bind-address=IP

  L'adresse IP à utiliser.

• --console

  Écrit les messages d'erreur du log d'erreur sur la sortie standard, même si --log-error est spécifiée. Sous Windows, mysqld ne ferme pas l'écran de console si cette option est utilisée.

• --character-sets-dir=path

  Dossier contenant les jeux de caractères. Voir Section 5.8.1, « Le jeu de caractères utilisé pour les données et le stockage »5.8.1. Le jeu de caractères utilisé pour les données et le stockage.

• --chroot=path

  Met le démon mysqld en environnement chroot au démarrage. Recommandé pour la sécurité depuis MySQL 4.0. (MySQL 3.23 n'est pas capable de fournir un encadrement chroot() qui soit 100 % étanche). Cela limite les commandes LOAD DATA INFILE et SELECT ... INTO OUTFILE.

• --core-file

  Écrire le fichier core lorsque mysqld s'arrête inopinément. Pour certains fichiers, vous devez aussi spécifier --core-file-size à safe_mysqld. Voir Section 5.1.3, « safe_mysqld, le script père de mysqld »5.1.3. safe_mysqld, le script père de mysqld. Notez que sur certains systèmes, comme Solaris, vous n'aurez pas de fichier de core si vous avez aussi utilisé l'option --user.

• --datadir=path, -h path

  Chemin jusqu'au dossier de données.

• --debug[=debug_options], -# [debug_options]

  Si MySQL est configuré avec --with-debug, vous pouvez utiliser cette option pour obtenir un fichier de trace de ce que mysqld fait. Voir Section D.1.2, « Créer un fichier de traçage »D.1.2. Créer un fichier de traçage.

• --default-character-set=charset

  Spécifie le jeu de caractères par défaut. Voir Section 5.8.1, « Le jeu de caractères utilisé pour les données et le stockage »5.8.1. Le jeu de caractères utilisé pour les données et le stockage.

• --default-collation=collation

  Spécifie la collation par défaut. Cette option est disponible depuis MySQL 4.1.1. Voir Section 5.8.1, « Le jeu de caractères utilisé pour les données et le stockage »5.8.1. Le jeu de caractères utilisé pour les données et le stockage.

• --default-storage-engine=type

  Cette option est un synonyme de --default-table-type. Cette option est disponible depuis MySQL 4.1.2.

• --default-table-type=type

  Spécifie le type de table par défaut. Voir Chapitre 14, Moteurs de tables MySQL et types de tableChapitre 14. Moteurs de tables MySQL et types de table.

• --delay-key-write[= OFF | ON | ALL]

  Comment l'option DELAYED KEYS doit être utilisée. Les écritures différées font que les buffers de clés ne sont pas écrits entre deux écritures pour les tables MyISAM. OFF désactive les écritures différées. ON active les écritures différées pour les tables qui ont été créées avec l'option DELAYED KEYS. ALL active les écritures différées pour les tables MyISAM. Cette option est disponible depuis MySQL 4.0.3. Voir Section 7.5.2, « Réglage des paramètres du serveur »7.5.2. Réglage des paramètres du serveur. Voir Section 14.1.1, « Options de démarrage MyISAM »14.1.1. Options de démarrage MyISAM.

  Note : si vous avez donné la valeur de ALL à cette option, vous ne devez pas utiliser les tables MyISAM depuis un autre programme (comme myisamchk) lorsque la table est utilisée. En faisant cela, vous obtiendrez une corruption d'index.

• --delay-key-write-for-all-tables

  Ancienne forme de --delay-key-write=ALL à utiliser sur les versions antérieures à la version 4.0.3. Depuis la version 4.0.3, utilisez --delay-key-write.

• --des-key-file=file_name

  Lit les clés par défaut utilisées par DES_ENCRYPT() et DES_DECRYPT() dans ce fichier.

• --enable-named-pipe

  Active le support des pipes nommés (seulement sur NT/Win2000/XP). Cette option ne s'applique qu'aux systèmes Windows NT, 2000 et XP, et peut être utilisée avec les serveurs mysqld-nt et mysqld-max-nt qui supportent les pipes nommés.

• --exit-info, -T

  Cette option est la combinaison d'options que vous pouvez utiliser pour le débogage du serveur mysqld. Si vous ne savez pas ce que ça fait exactement, ne l'utilisez pas !

• --external-locking

  Active le verrouillage système. Notez que si vous utilisez cette option sur un système pour lequel lockd ne fonctionne pas (comme Linux), vous allez bloquer rapidement mysqld avec les verrous. Anciennement appelée --enable-locking.

  Note : si vous utilisez cette option pour activer des modifications de tables MyISAM depuis plusieurs processus MySQL, vous devez vous assurer de trois conditions :

  • vous n'utilisez pas de cache de requêtes pour les requêtes qui utilisent les tables sont modifiées par un autre processus ;

  • vous ne devez pas utiliser --delay-key-write=ALL ou DELAY_KEY_WRITE=1 sur des tables partagées.

  Le plus simple pour s'assurer de cela est de toujours utiliser l'option --external-locking avec --delay-key-write=OFF --query-cache-size=0.

  (Ceci n'est pas fait par défaut, car dans de nombreuses configurations, il est pratique de faire un mélange des options ci-dessus).

• --flush

  Écrit toutes les données sur le disque après chaque requête SQL. Normalement, MySQL fait des écritures sur le disque après chaque requête, et laisse le système d'exploitation assurer la synchronisation avec le disque. Voir Section A.4.2, « Que faire si MySQL plante constamment ? »A.4.2. Que faire si MySQL plante constamment ?.

• --init-file=file

  Lit les commandes SQL dans ce fichier au démarrage. Chaque commande doit être sur une ligne, et ne pas utiliser de commentaires.

• --language=lang_name, -L lang_name

  Spécifie la langue utilisée pour les messages d'erreur du client. Le chemin complet doit être utilisé. Voir Section 5.8.2, « Langue des messages d'erreurs »5.8.2. Langue des messages d'erreurs.

• --log[=file], -l [file]

  Enregistre les connexions et les requêtes dans ce fichier. Voir Section 5.9.2, « Le log général de requêtes »5.9.2. Le log général de requêtes. Si vous ne le faites pas, MySQL va utiliser host_name.log comme nom de fichier.

• --log-bin=[file]

  Enregistre toutes les requêtes qui modifient des données dans un log. Voir Section 5.9.4, « Le log binaire »5.9.4. Le log binaire. Ce log est utilisé pour la sauvegarde et la réplication. Si vous ne le faites pas, MySQL va utiliser host_name-bin comme nom de fichier.

• --log-bin-index[=file]

  Fichier d'index pour les noms de fichiers de log binaire. Voir Section 5.9.4, « Le log binaire »5.9.4. Le log binaire. Si vous ne le faites pas, MySQL va utiliser host_name-bin.index comme nom de fichier.

• --log-error[=file]

  Enregistre les messages d'erreur et les messages de démarrage dans ce fichier. Voir Section 5.9.1, « Le log d'erreurs »5.9.1. Le log d'erreurs. Si vous ne le faites pas, MySQL va utiliser host_name.err comme nom de fichier.

• --log-isam[=file]

  Enregistre toutes les modifications des tables ISAM/MyISAM dans ce fichier (uniquement nécessaire pour déboguer ISAM/MyISAM).

• --log-long-format

  Enregistre des informations supplémentaires dans les fichiers de log (log de modifications, log binaire de modifications, log de requêtes lentes, n'importe quel log en fait). Par exemple, le nom d'utilisateur et un timestamp sont enregistrés avec la requête. Si vous utilisez --log-slow-queries et --log-long-format, alors les requêtes qui n'utilisent pas d'index seront aussi enregistrées. Notez que --log-long-format est obsolète depuis la version 4.1, où --log-short-format a été introduite (le format de log long est la configuration par défaut en version 4.1). Notez aussi que depuis la version MySQL 4.1 l'option --log-queries-not-using-indexes est disponible pour enregistrer spécifiquement les requêtes qui n'utilisent pas d'index, dans le log de requêtes lentes.

• --log-queries-not-using-indexes

  Si vous utilisez cette option avec --log-slow-queries, alors les requêtes qui n'utilisent pas d'index seront aussi enregistrées dans le log de requêtes lentes. Cette option est disponible depuis MySQL 4.1. Voir Section 5.9.5, « Le log des requêtes lentes »5.9.5. Le log des requêtes lentes.

• --log-short-format

  Enregistre moins d'information dans les fichiers de log (log de modifications, log binaire de modifications, log de requêtes lentes, n'importe quel log en fait). Par exemple, les noms d'utilisateur et un timestamp ne seront pas enregistrés avec les requêtes. Cette option a été ajoutée en MySQL 4.1.

• --log-slow-queries[=file]

  Enregistre toutes les requêtes qui prennent plus de long_query_time secondes à s'exécuter. Notez que la quantité d'informations enregistrées par défaut a changé en MySQL 4.1. Voyez les options --log-long-format et --log-long-format pour plus de détails. Voir Section 5.9.5, « Le log des requêtes lentes »5.9.5. Le log des requêtes lentes.

• --log-update[=file]

  Enregistre les modifications de données dans le fichier file.# où # est un nombre unique, s'il n'est pas fourni. Voir Section 5.9.3, « Le log de modification »5.9.3. Le log de modification. Le log de modification est obsolète et supprimé en MySQL 5.0.0; vous devriez utiliser le log binaire à la place. (--log-bin). Voir Section 5.9.4, « Le log binaire »5.9.4. Le log binaire. Depuis la version 5.0.0, utiliser --log-update va simplement activer le log binaire. (Voir Section C.1.7, « Changements de la version 5.0.0 (22 décembre 2003 : Alpha) »C.1.7. Changements de la version 5.0.0 (22 décembre 2003 : Alpha)).

• --log-warnings, -W

  Affiche les alertes comme Aborted connection... dans le fichier d'erreur .err. Activer cette option est recommandé, par exemple, si vous utilisez la réplication : vous obtiendrez plus d'informations sur ce qui se passe, comme les erreurs de connexion réseau, ou les reconnexions. Cette option est activée par défaut depuis MySQL 4.1.2; pour la désactiver, utilisez --skip-log-warnings. Voir Section A.2.10, « Erreurs de communication / Connexion annulée »A.2.10. Erreurs de communication / Connexion annulée.

  Cette option s'appelait --warnings avant MySQL 4.0.

• --low-priority-updates

  Les opérations de modification de table (INSERT/DELETE/UPDATE) auront une priorité inférieure aux sélections. Cela peut être aussi fait via l'attribut {INSERT | REPLACE | UPDATE | DELETE} LOW_PRIORITY ... pour baisser la priorité d'une requête, ou avec SET LOW_PRIORITY_UPDATES=1 pour changer la priorité dans plus d'un thread. Voir Section 7.3.2, « Problème de verrouillage de tables »7.3.2. Problème de verrouillage de tables.

• --memlock

  Verrouille le processus mysqld en mémoire. Cela fonctionne si votre système supporte la fonction mlockall() (comme Solaris). Ceci peut être utile si vous avez des problèmes avec le système d'exploitation qui force mysqld à utiliser le swap sur le disque.

• --myisam-recover [=option[,option...]]]

  Cette option est la combinaison de DEFAULT, BACKUP, FORCE et QUICK. Vous pouvez aussi lui donner la valeur explicite de "" si vous voulez désactiver cette option. Si cette option est utilisée, mysqld va vérifier si la table est marquée comme corrompue à l'ouverture de chaque table (cette dernière option ne fonctionne que si vous utilisez l'option --skip-external-locking). Si c'est le cas, mysqld va essayer de vérifier la table. Si la table était corrompue, mysqld essaie alors de la réparer.

  L'option suivante va affecter la manière avec laquelle la réparation s'effectue.

  Option	Description
  DEFAULT	Identique à ne pas donner d'option à --myisam-recover.
  BACKUP	Si la table a été modifiée durant la réparation, sauver une copie du fichier table_name.MYD, sous le nom de table_name-datetime.BAK.
  FORCE	Exécute une réparation même si nous allons perdre une ou plusieurs lignes dans le fichier .MYD.
  QUICK	Ne vérifie pas les lignes dans la table s'il n'y a pas eu d'effacement.

  Avant que la table ne soit automatiquement réparée, MySQL va ajouter une note dans le fichier de logs d'erreurs. Si vous voulez être capable de restaurer la plupart des erreurs sans intervention de l'utilisateur, il vaut utiliser les options BACKUP,FORCE. Cela va forcer la réparation de la table, même si quelques lignes sont effacées, et conserve le vieux fichier de données comme sauvegarde, pour examen ultérieur.

  Cette option est disponible depuis MySQL 3.23.25.

• --new

  Depuis la version 4.0.12, l'option --new sert à dire au serveur d'adopter le comportement de la version 4.1 pour certains aspects, afin de simplifier la migration de 4.0 en 4.1.

  • TIMESTAMP est retourné sous forme de chaîne avec le format 'YYYY-MM-DD HH:MM:SS'. Voir Chapitre 11, Types de colonnesChapitre 11. Types de colonnes.

  Cette option peut vous aider à voir comment vos applications vont se comporter en MySQL 4.1, sans réellement changer de version.

• --pid-file=path

  Le chemin jusqu'au fichier de PID utilisé par safe_mysqld.

• --port=port_num, -P port_num

  Numéro de port utilisé pour attendre les connexions TCP/IP.

• --old-protocol, -o

  Utilise le protocole 3.20, pour la compatibilité avec de très vieux clients. Voir Section 2.6.6, « Passer de la version 3.20 à la version 3.21 »2.6.6. Passer de la version 3.20 à la version 3.21.

• --one-thread

  Utilise uniquement un thread (pour débogage sous Linux). Cette option est disponible uniquement si le serveur est compilé avec les options de débogage. Voir Section D.1, « Déboguer un serveur MySQL »D.1. Déboguer un serveur MySQL.

• --open-files-limit=count

  Pour changer le nombre de pointeurs de fichiers disponibles pour mysqld. Si cette option n'est pas configurée, ou qu'elle vaut 0, alors mysqld va utiliser cette valeur pour réserver ce nombre de pointeurs de fichiers, à utiliser avec setrlimit(). Si la valeur est 0 alors mysqld va réserver max_connections*5 ou max_connections + table_cache*2 (le plus grand des deux) pointeurs de fichiers. Il est recommandé d'augmenter cette valeur si mysqld émet des erreurs de type 'Too many open files'.

• --safe-mode

  Ignore certaines étapes d'optimisation.

• --safe-show-database

  Avec cette option, la commande SHOW DATABASES retourne uniquement les bases pour lesquelles l'utilisateur a des droits. Depuis la version 4.0.2, cette option est abandonnée, et ne fait plus rien (l'option est activée par défaut) car nous avons désormais le droit de SHOW DATABASES. Voir Section 13.5.1.3, « Syntaxe de GRANT et REVOKE »13.5.1.3. Syntaxe de GRANT et REVOKE.

• --safe-user-create

  Si cette option est activée, un utilisateur ne peut pas créer de nouveaux utilisateurs avec la commande GRANT si l'utilisateur n'a pas les droits de INSERT dans la table mysql.user ou dans aucune colonne de cette table.

• --secure-auth

  Interdit l'identification des comptes qui ont des mots de passe anciens (avant la version 4.1). Cette option est disponible depuis MySQL 4.1.1.

• --skip-bdb

  Désactive l'utilisation des tables BDB. Cela va économiser de la mémoire et accélérer le serveur un peu. N'utilisez pas cette option si vous avez besoin des tables BDB.

• --skip-concurrent-insert

  Désactive la possibilité de sélectionner et insérer en même temps dans les tables MyISAM (cela n'est utile que si vous pensez que vous avez trouvé un bogue dans cette fonctionnalité).

• --skip-delay-key-write

  Ignore l'option DELAY_KEY_WRITE de toutes les tables. Depuis MySQL 4.0.3, vous devez utiliser --delay-key-write=OFF à la place. Voir Section 7.5.2, « Réglage des paramètres du serveur »7.5.2. Réglage des paramètres du serveur.

• --skip-external-locking

  Ne pas utiliser le verrouillage du système. Pour utiliser les utilitaires isamchk ou myisamchk vous devez alors éteindre le système. Voir Section 1.2.3, « Jusqu'à quel point MySQL est il stable ? »1.2.3. Jusqu'à quel point MySQL est il stable ?. Notez qu'en MySQL version 3.23 vous pouvez utiliser la commande REPAIR et CHECK pour réparer ou vérifier des tables MyISAM. Cette option s'appelait auparavant --skip-locking.

• --skip-grant-tables

  Cette option force le serveur à ne pas utiliser le système de privilège du tout. Cela donne à tous l'accès complet à toutes les bases de données ! Vous pouvez demander à un serveur en exécution d'utiliser à nouveau les tables de droits en exécutant la commande mysqladmin flush-privileges ou mysqladmin reload).

• --skip-host-cache

  Ne pas utiliser le cache de noms de domaine pour une résolution des IP plus rapide, mais interroger le serveur DNS à chaque connexion. Voir Section 7.5.6, « Comment MySQL utilise le DNS »7.5.6. Comment MySQL utilise le DNS.

• --skip-innodb

  Désactive l'utilisation des tables InnoDB. Cela va économiser de la mémoire et accélérer le serveur un peu. N'utilisez pas cette option si vous avez besoin des tables InnoDB.

• --skip-isam

  Désactive l'utilisation des tables ISAM. Cela va économiser de la mémoire et accélérer le serveur un peu. Depuis MySQL 4.1, ISAM est désactivé par défaut, ce qui fait que cette option n'apparaît que si le serveur a été configuré avec le support N'utilisez pas cette option si vous avez besoin des tables ISAM.

• --skip-name-resolve

  Les noms d'hôtes ne sont pas résolus. Toutes les colonnes Host dans vos tables de droits doivent être des IP numériques ou le mot localhost. Voir Section 7.5.6, « Comment MySQL utilise le DNS »7.5.6. Comment MySQL utilise le DNS.

• --skip-networking

  Ne pas attendre les connexions TCP/IP du tout. Toutes les interactions du serveur mysqld seront faites avec les sockets Unix. Cette option est particulièrement recommandée pour les systèmes qui utilisent des requêtes locales. Voir Section 7.5.6, « Comment MySQL utilise le DNS »7.5.6. Comment MySQL utilise le DNS.

• --skip-new

  Ne pas utiliser les nouvelles routines qui sont possiblement erronées.

• --skip-symlink

  C'est l'ancienne forme de --skip-symbolic-links, à utiliser avant MySQL 4.0.13.

• --symbolic-links, --skip-symbolic-links

  Active ou désactive le support des liens symboliques. Cette option a différents effets sur Windows et sur Unix.

  • Sous Windows, activer les liens symboliques vous permet d'établir un lien symbolique vers une base de données, en créant un fichier directory.sym qui contient le chemin réel. Voir Section 7.6.1.3, « Utiliser des liens symboliques pour les bases de données sous Windows »7.6.1.3. Utiliser des liens symboliques pour les bases de données sous Windows.

  • Sous Unix, activer les liens symboliques signifie que vous pouvez mettre un fichier d'index MyISAM ou un autre fichier de données dans un autre dossier, avec les options INDEX DIRECTORY ou DATA DIRECTORY de la commande CREATE TABLE. Si vous effacez ou renommez la table, les fichiers qui sont des liens symboliques seront aussi effacés ou renommés. Voir Section 13.2.5, « Syntaxe de CREATE TABLE »13.2.5. Syntaxe de CREATE TABLE.

  Cette option est disponible depuis MySQL 4.0.13.

• --skip-show-database

  Si MySQL est configuré avec --with-debug=full, tous les programmes vérifieront la mémoire pour rechercher les écrasements de zone lors des allocations et libérations de mémoire. Comme ce test est lent, vous pouvez l'éviter, si vous n'avez pas besoin de tester la mémoire, en utilisant cette option.

• --skip-show-database

  Ne pas autoriser la commande SHOW DATABASES, à moins que l'utilisateur n'ait les droits de SHOW DATABASES. Depuis la version 4.0.2, vous n'avez plus besoin de cette option, car les droits pour ce faire sont distribués avec le droit de SHOW DATABASES.

• --skip-stack-trace

  Ne pas écrire les piles de traces. Cette option est pratique lorsque vous utilisez mysqld avec un débogueur. Sur certains systèmes, vous devez aussi utiliser cette option pour obtenir un fichier de core. Voir Section D.1, « Déboguer un serveur MySQL »D.1. Déboguer un serveur MySQL.

• --skip-thread-priority

  Désactive les priorités des threads pour améliorer la vitesse de réponse.

• --socket=path

  Sous Unix, le fichier de socket pour les connexions locales. (par défaut, /tmp/mysql.sock). Sous Windows, le nom du pipe à utiliser pour les connexions locales qui utilisent un pipe nommé (par défaut, MySQL).

• --sql-mode=value[,value[,value...]]

  Spécifie le mode SQL. Voir Section 5.2.2, « Le mode SQL du serveur »5.2.2. Le mode SQL du serveur. Cette option est disponible depuis 3.23.41.

• --temp-pool

  En utilisant cette option, vous allez réduire le jeu de noms qui sont utilisés lors de la création de fichiers temporaires, plutôt qu'un nom unique à chaque fois. Ceci est un palliatif au noyau Linux qui crée plusieurs fichiers nouveaux avec des noms différents. Avec l'ancien comportement, Linux semble « perdre de la mémoire », car ils sont alloués au cache d'entrées du dossier au lieu de celui du disque.

• --transaction-isolation=level

  Configure le niveau d'isolation des transactions. Le niveau peut être READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ ou SERIALIZABLE. Voir Section 13.4.6, « Syntaxe de SET TRANSACTION  »13.4.6. Syntaxe de SET TRANSACTION .

• --tmpdir=path, -t path

  Chemin vers les fichiers temporaires. Il peut s'avérer pratique si votre dossier par défaut /tmp réside dans une partition qui est trop petite pour absorber les tables temporaires. Depuis MySQL MySQL 4.1, cette option accepte différents chemins, qui sont utilisés en alternance. Les chemins doivent être séparés par des deux-points (':') sous Unix et des points-virgules (';') sous Windows. Il est possible de dire à tmpdir de pointer sur un système de fichiers en mémoire, hormis si le serveur MySQL est un esclave. Si c'est un esclave, il faut un système de fichiers permanents (pour la réplication des tables temporaires et des commandes LOAD DATA INFILE) survive a un redémarrage de la machine : un système de fichiers en mémoire tmpdir, qui est effacé au lancement de la machine n'est pas acceptable. Un disque est nécessaire pour tmpdir, dans ce contexte.

• --user={user_name | user_id}, -u {user_name | user_id}

  Exécute le démon mysqld avec l'utilisateur user_name ou userid (numérique). (« utilisateur » dans ce contexte fait référence à l'utilisateur du système d'exploitation, mais pas l'utilisateur MySQL, listé dans les tables de droits.)

  Cette option est obligatoire lorsque vous démarrez mysqld en tant que root. Le serveur va changer d'ID durant le lancement du serveur, pour utiliser un autre utilisateur que root. Voir Section 5.4, « Sécurité générale du serveur »5.4. Sécurité générale du serveur.

  Depuis MySQL 3.23.56 et 4.0.12: Pour éviter des trous de sécurité si un utilisateur ajoute --user=root dans un fichier my.cnf (et donc, faisant que le serveur fonctionne en tant qu'utilisateur système root), mysqld utilise uniquement la première option --user spécifiée, et produit une alerte s'il rencontre d'autres options --user. Les options des fichiers /etc/my.cnf et datadir/my.cnf sont traités avant les options de ligne de commande, et il est recommandé que vous ajoutiez l'option --user dans le fichier /etc/my.cnf puis spécifiez une valeur autre que root. L'option de /etc/my.cnf peut être placée avant toute autre option --user, ce qui assure que le serveur fonctionnera avec l'utilisateur autre que root, et qu'une alerte apparaîtra si une autre option --user est découverte.

• --version, -V

  Affiche les informations de version.

Vous pouvez assigner une valeur à une variable système en utilisant une option de la forme --nom_de_variable=valeur. Par exemple, --key_buffer_size=32M donne à la variable key_buffer_size la valeur de 32 Mo.

Notez que lorsque vous donnez une valeur à une variable, MySQL peut corriger automatiquement la valeur pour qu'elle reste dans un intervalle donné, ou peut ajuster la valeur à la valeur possible la plus proche.

Il est aussi possible de donner des valeurs aux variables avec la syntaxe --set-variable=var_name=value ou -O var_name=value. Notez que cette syntaxe est abandonnée depuis MySQL 4.0.

Vous pouvez trouver une description complète de toutes les variables dans la section Section 5.2.3, « Variables serveur système »5.2.3. Variables serveur système. La section sur le paramétrage du serveur inclut des détails sur l'optimisation. Voir Section 7.5.2, « Réglage des paramètres du serveur »7.5.2. Réglage des paramètres du serveur.

Vous pouvez changer la valeur de la plupart des variables système sur un serveur en fonctionnement avec la commande SET. Voir Section 13.5.2.8, « Syntaxe de SET »13.5.2.8. Syntaxe de SET.

Si vous voulez limiter la valeur maximale qu'une option recevra avec la commande SET, vous pouvez la définir en utilisant l'option --maximum-nom_de_variable en ligne de commande.

Le serveur MySQL peut fonctionner avec différents modes SQL, et, depuis MySQL 4.1, il peut appliquer ces modes au niveau de la connexion du client. Cela permet aux applications d'adapter le comportement du serveur en fonction de leurs attentes.

Le mode définit quelle syntaxe SQL MySQL doit supporter, et quels types de vérification il doit faire. Cela rend plus facile l'utilisation de MySQL dans différents environnements, et la connexion avec les autres serveurs de bases de données.

Vous pouvez donner un mode SQL par défaut au démarrage de mysqld avec l'option --sql-mode="modes". La valeur peut aussi être vide (--sql-mode="") si vous voulez la remettre à 0.

Depuis MySQL 4.1, vous pouvez aussi changer le mode après le démarrage en modifiant la variable sql_mode avec la commande SET [SESSION|GLOBAL] sql_mode='modes'. Modifier la variable GLOBAL affecte les opérations de tous les clients qui se connecteront. En modifiant la variable SESSION, cela n'affectera que le client courant.

modes est une liste de modes différents, séparés par des virgules (','). Vous pouvez lire le mode courant avec la commande SELECT @@sql_mode. La valeur par défaut est vide (pas de mode configuré).

• ANSI

  Change la syntaxe et le comportement pour être plus compatible avec le standard SQL. (Nouveau en MySQL 4.1.1.)

• STRICT_TRANS_TABLES

  Si une valeur n'a pas pu être insérée dans une table transactionnelle sans modification, la commande est annulée. Pour une table non transactionnelle, la commande est annulée si cela survient dans une ligne unique ou dans la première ligne d'une insertion multiple. Plus de détails seront donnés ultérieurement dans cette section. (Nouveau en MySQL 5.0.2.)

• TRADITIONAL

  MySQL se comporte comme un système SQL « traditionnel ». Une description simple est que ce mode « émet une erreur et non pas une alerte » lors de l'insertion d'une valeur incorrecte dans une colonne. Note : si vous utilisez un moteur de table non transactionnel, les commandes INSERT/UPDATE s'arrêteront dès que l'erreur est repérée, ce qui n'est pas forcément ce que vous voudrez. (Nouveau en MySQL 5.0.2.)

Lorsque cette documentation fait référence au mode strict, cela signifie qu'au moins un des modes STRICT_TRANS_TABLES ou STRICT_ALL_TABLES est activé.

La liste suivante présente les différents modes supportés :

• ALLOW_INVALID_DATES

  N'autorise pas la vérification totale des dates. Vérifie simplement que le mois est dans l'intervalle de 1 à 12, et que le jour est dans l'intervalle de de 1 à 31. C'est très pratique pour les applications Web où la date est obtenue de 3 champs différents, et que vous voulez stocker exactement la date saisie sans validation. Ce mode s'applique aux colonnes de type DATE et DATETIME. Il ne s'applique pas aux colonnes TIMESTAMP, qui demandent toujours une date valide.

  Ce mode est nouveau en MySQL 5.0.2. Avant 5.0.2, c'était le mode par défaut de gestion des dates. Depuis 5.0.2, activer le mode strict impose au serveur de vérifier la validité des dates, et non pas seulement les intervalles. Par exemple, '2004-04-31' est valide sans le mode strict, mais ne l'est plus avec le mode strict. Pour permettre ces valeurs malgré le mode strict, utilisez le mode ALLOW_INVALID_DATES.

• ANSI_QUOTES

  Traite '"' comme un délimiteur d'identifiant (comme le caractère MySQL '`') et non comme un délimiteur de chaînes. Vous pouvez toujours utiliser '`' pour délimiter les identifiants en mode ANSI. Avec ANSI_QUOTES activée, vous ne pouvez pas utiliser les guillemets doubles pour délimiter une chaîne de caractères, car ce sera uniquement interprété comme un identifiant. (Nouveau en MySQL 4.0.0.)

• ERROR_FOR_DIVISION_BY_ZERO

  Produit une erreur en mode strict et sinon une alerte, lorsque MySQL doit tenter une division par 0 ou un MOD(X,0)) durant une commande INSERT/ UPDATE. Si ce mode n'est pas activé, MySQL retourne simplement NULL pour les divisions par zéro. Si utilisé avec l'attribut IGNORE, MySQL génère une alerte pour les divisions par zéro, mais le résultat de l'opération sera NULL. (Nouveau en MySQL 5.0.2.)

• IGNORE_SPACE

  Permet les espaces entre le nom de la fonction et le caractère '('. Cela force les noms de fonctions à être traités comme des mots réservés. En conséquence, si vous voulez accéder aux bases, tables et colonnes dont le nom est un mot réservé, vous devez le mettre entre délimiteurs. Par exemple, comme la fonction USER() existe, le nom de la table user de la base mysql et la colonne User de cette table doivent être protégés :

   

  Sélectionnez

  SELECT "User" FROM mysql."user";

  (Nouveau en MySQL 4.0.0.)

• NO_AUTO_VALUE_ON_ZERO

  NO_AUTO_VALUE_ON_ZERO affecte la gestion des colonnes de type AUTO_INCREMENT. Normalement, vous générez le prochain numéro de séquence dans la colonne en insérant soit NULL soit 0 dedans. NO_AUTO_VALUE_ON_ZERO supprime ce comportement pour 0 pour que seule la valeur NULL génère le prochain numéro de séquence. Ce mode est utile si vous avez stocké la valeur 0 dans la colonne AUTO_INCREMENT de la table. Ce n'est pas recommandé. Par exemple, si vous voulez exporter une table avec mysqldump et que vous la rechargez, normalement MySQL va générer de nouveaux identifiants pour les lignes avec la valeur 0, ce qui entraînera une différence avec la table originale. En activant NO_AUTO_VALUE_ON_ZERO avant de recharger le fichier exporté, vous évitez de problème. Depuis MySQL 4.1.1, mysqldump va automatiquement inclure les commandes nécessaires dans l'export, pour activer NO_AUTO_VALUE_ON_ZERO. (Nouveau en MySQL 4.1.1.)

• NO_DIR_IN_CREATE

  Lors de la création d'une table, ignore les directives INDEX DIRECTORY et DATA DIRECTORY. Cette option est pratique sur un esclave de réplication. (Nouveau en MySQL 4.0.15.)

• NO_FIELD_OPTIONS

  N'affiche pas les options spécifiques à MySQL dans le résultat de SHOW CREATE TABLE. Ce mode est utilisé par mysqldump dans un souci de portabilité. (Nouveau en MySQL 4.1.1.)

• NO_KEY_OPTIONS

  N'affiche pas les options spécifiques à MySQL dans le résultat de SHOW CREATE TABLE. Ce mode est utilisé par mysqldump dans un souci de portabilité. (Nouveau en MySQL 4.1.1.)

• NO_TABLE_OPTIONS

  N'affiche pas les options de tables spécifiques à MySQL (comme ENGINE) dans le résultat de SHOW CREATE TABLE. Ce mode est utilisé par mysqldump dans un souci de portabilité. (Nouveau en MySQL 4.1.1.)

• NO_ZERO_DATE

  Ne permet pas l'utilisation de '0000-00-00' comme date valide. Vous pouvez toujours insérer des dates nulles avec l'option IGNORE. (Nouveau en MySQL 5.0.2.)

• NO_ZERO_IN_DATE

  N'accepte pas les dates où le mois ou le jour vaut 0. Si utilisé avec l'option IGNORE, la date '0000-00-00' sera insérée pour chaque date invalide. (Nouveau en MySQL 5.0.2.)

• NO_UNSIGNED_SUBTRACTION

  Dans les opérations de soustraction, ne marque pas le résultat UNSIGNED si un des opérandes est non signé. Notez que cela fait que UNSIGNED BIGINT n'est plus totalement utilisable dans tous les contextes. Voir Section 12.7, « Fonctions de transtypage »12.7. Fonctions de transtypage. (Nouveau en MySQL 4.0.2.)

• ONLY_FULL_GROUP_BY

  N'autorise pas les requêtes dont la clause GROUP BY fait référence à une colonne qui n'est pas sélectionnée. (Nouveau en MySQL 4.0.0.)

• PIPES_AS_CONCAT

  Traite || comme un opérateur de concaténation (identique à CONCAT()) au lieu d'être un synonyme de OR. (Nouveau en MySQL 4.0.0.)

• REAL_AS_FLOAT

  Traite le type REAL comme un synonyme FLOAT plutôt que comme un synonyme de DOUBLE. (Nouveau en MySQL 4.0.0.)

• STRICT_ALL_TABLES

  Active le mode strict pour tous les moteurs de stockage. Les valeurs invalides sont rejetées. Plus de détails suivent. (Nouveau en MySQL 5.0.2.)

• STRICT_TRANS_TABLES

  Active le mode strict pour tous les moteurs de stockage transactionnels. Les valeurs invalides sont rejetées. Plus de détails suivent. (Nouveau en MySQL 5.0.2.)

Lorsque le mode strict est activé, MySQL retourne une erreur si une valeur est invalide ou manquante (aucune valeur fournie pour la colonne, et la colonne n'a pas de valeur DEFAULT explicite dans sa définition). Pour les tables transactionnelles, cela arrive lorsque les modes STRICT_ALL_TABLES et STRICT_TRANS_TABLES sont activés. La commande est alors annulée. Pour les tables non transactionnelles, MySQL gère les valeurs invalides comme ceci :

si la commande insère ou modifie une seule ligne, l'erreur survient si la valeur est invalide ou manquante. La commande est annulée et la table reste intacte. Si la commande insère ou modifie plusieurs lignes, l'effet dépend de l'option stricte activée :

• pour le mode STRICT_ALL_TABLES, si une valeur est invalide ou manquante dans la première ligne, MySQL retourne une erreur et aucune ligne n'est modifiée. Si une valeur est invalide ou manquante à partir de la seconde ligne, MySQL retourne une erreur et ignore le reste des lignes. Cependant, dans ce cas, les premières lignes restent modifiées ou insérées. Cela signifie que vous risquez d'obtenir une opération partielle, ce qui n'est pas forcément souhaitable. Pour éviter cela, il est alors recommandé d'utiliser des commandes unilignes ;

• pour le mode STRICT_TRANS_TABLES, si une valeur est invalide ou manquante pour la première ligne, MySQL retourne une erreur et aucune ligne n'est modifiée. Pour les lignes suivantes, si une valeur est invalide, MySQL insère la valeur valide la plus proche. Si une valeur manque, MySQL insère explicitement la valeur par défaut pour ce type de données. Dans ce cas, MySQL génère une alerte, et continue le traitement.

Le mode strict interdit l'utilisation de dates invalides comme '2004-04-31'. Il n'interdit pas les dates avec des 0 comme 2004-04-00' ou encore les dates « zéro ». Pour les interdire, il faut activer les modes NO_ZERO_IN_DATE et NO_ZERO_DATE.

Si vous n'utilisez pas de mode strict, c'est-à-dire ni STRICT_TRANS_TABLES ni STRICT_ALL_TABLES, MySQL génère une alerte pour toutes les valeurs qui sont adaptées pour être insérées. Voir Section 13.5.3.19, « SHOW WARNINGS | ERRORS »13.5.3.19. SHOW WARNINGS | ERRORS.

Les modes suivants sont fournis comme raccourcis pour différentes combinaisons des valeurs précédentes. Tous les raccourcis sont disponibles depuis MySQL 4.1.1, hormisTRADITIONAL (5.0.2).

• ANSI

  équivaut à REAL_AS_FLOAT, PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, ONLY_FULL_GROUP_BY. Voir Section 1.5.3, « Exécuter MySQL en mode ANSI »1.5.3. Exécuter MySQL en mode ANSI.

• DB2

  équivaut à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

• MAXDB

  équivaut à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

• MSSQL

  équivaut à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

• MYSQL323

  équivaut à NO_FIELD_OPTIONS.

• MYSQL40

  équivaut à NO_FIELD_OPTIONS.

• ORACLE

  équivaut à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

• POSTGRESQL

  équivaut à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

• TRADITIONAL

  équivaut à STRICT_TRANS_TABLES, STRICT_ALL_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO.

Le serveur entretient de nombreuses variables système qui indiquent comment il est configuré. Toutes les variables ont des valeurs par défaut. Elles peuvent être configurées au lancement du serveur, avec les options de ligne de commande, ou bien durant l'exécution, avec la commande SET.

Depuis MySQL version 4.0.3, le serveur mysqld entretient deux types de variables. Les variables globales, qui affectent les opérations générales du serveur. Et les variables de session qui affectent les comportements individuels des connexions.

Lorsque mysqld démarre, toutes les variables globales sont initialisées à partir des arguments passés en ligne de commande et des fichiers de configuration. Vous pouvez changer ces valeurs avec la commande SET GLOBAL. Lorsqu'un nouveau thread est créé, les variables spécifiques aux threads sont initialisées à partir des variables globales et ne changeront pas même si vous utilisez la commande SET GLOBAL var_name. Pour changer une variable globale, vous devez avoir les droits de SUPER.

Le serveur entretient aussi un jeu de variables de session pour chaque client qui se connecte. Les variables de session du serveur sont initialisées au moment de la connexion, en utilisant les valeurs correspondantes des variables globales. Pour les variables de session qui sont dynamiques, le client peut les changer avec la commande SET SESSION var_name. Modifier une variable de session ne requiert aucun droit spécifique, mais le client ne modifiera le comportement du serveur que pour sa connexion, et non pour les connexions des autres.

Une modification de variable globale est visible par tous les clients qui accèdent aux variables globales. Cependant, elle n'affectera les connexions des clients que pour les nouvelles connexions. Les variables de sessions déjà en cours continueront à fonctionner avec la même configuration, jusqu'à leur déconnexion. Même le client qui a émis la commande SET GLOBAL ne verra aucun changement.

Lorsque vous modifiez une variable avec une option de démarrage, les valeurs de variables peuvent être spécifiées avec le suffixe K, M ou G, pour indiquer des kilooctets, des mégaoctets ou des gigaoctets. Par exemple, pour lancer le serveur avec une taille de buffer de clé de 16 Mo, vous pouvez utiliser :

mysqld --key_buffer_size=16M

Avant MySQL 4.0, vous deviez utiliser la syntaxe suivante :

mysqld --set-variable=key_buffer_size=16M

La lettre de suffixe peut être en majuscule ou en minuscule : 16M et 16m sont équivalents.

Durant l'exécution, utilisez la commande SET pour donner de nouvelles valeurs aux variables système. Dans ce contexte, les lettres de suffixes ne pourront pas être utilisées. Leur valeur peut être calculée avec l'expression suivante :

mysql> SET sort_buffer_size = 10 * 1024 * 1024;

Pour spécifier explicitement si vous voulez modifier une variable globale ou une variable de session, utilisez les options GLOBAL et SESSION :

mysql> SET GLOBAL sort_buffer_size = 10 * 1024 * 1024;
mysql> SET SESSION sort_buffer_size = 10 * 1024 * 1024;

Si cette option est omise, la variable de session sera modifiée.

Les variables qui peuvent être modifiées durant l'exécution sont listées dans la section Section 5.2.3.1, « Variables système dynamiques »5.2.3.1. Variables système dynamiques.

Si vous voulez restreindre le maximum possible d'une variable système, modifiée avec SET, vous pouvez spécifier ce maximum avec les options de la forme --maximum-var_name au lancement du serveur. Par exemple, pour éviter que la valeur de query_cache_size dépasse 32 Mo, utilisez l'option --maximum-query_cache_size=32M. Cette fonctionnalité est disponible depuis MySQL 4.0.2.

Vous pouvez découvrir les variables système et leur valeur avec la commande SHOW VARIABLES. Voyez Section 9.4, « Variables système »9.4. Variables système pour plus d'informations.

mysql> SHOW VARIABLES;
+---------------------------------+------------------------------+
| Variable_name                   | Value                        |
+---------------------------------+------------------------------|
| back_log                        | 50                           |
| basedir                         | /usr/local/mysql             |
| bdb_cache_size                  | 8388572                      |
| bdb_home                        | /usr/local/mysql             |
| bdb_log_buffer_size             | 32768                        |
| bdb_logdir                      |                              |
| bdb_max_lock                    | 10000                        |
| bdb_shared_data                 | OFF                          |
| bdb_tmpdir                      | /tmp/                        |
| bdb_version                     | Sleepycat Software: ...      |
| binlog_cache_size               | 32768                        |
| bulk_insert_buffer_size         | 8388608                      |
| character_set                   | latin1                       |
| character_sets                  | latin1 big5 czech euc_kr     |
| concurrent_insert               | ON                           |
| connect_timeout                 | 5                            |
| convert_character_set           |                              |
| datadir                         | /usr/local/mysql/data/       |
| default_week_format             | 0                            |
| delay_key_write                 | ON                           |
| delayed_insert_limit            | 100                          |
| delayed_insert_timeout          | 300                          |
| delayed_queue_size              | 1000                         |
| flush                           | OFF                          |
| flush_time                      | 0                            |
| ft_boolean_syntax               | + -><()~*:""&|               |
| ft_max_word_len                 | 84                           |
| ft_min_word_len                 | 4                            |
| ft_query_expansion_limit        | 20                           |
| ft_stopword_file                | (built-in)                   |
| have_bdb                        | YES                          |
| have_innodb                     | YES                          |
| have_isam                       | YES                          |
| have_openssl                    | YES                          |
| have_query_cache                | YES                          |
| have_raid                       | NO                           |
| have_symlink                    | DISABLED                     |
| init_file                       |                              |
| innodb_additional_mem_pool_size | 1048576                      |
| innodb_buffer_pool_size         | 8388608                      |
| innodb_data_file_path           | ibdata1:10M:autoextend       |
| innodb_data_home_dir            |                              |
| innodb_fast_shutdown            | ON                           |
| innodb_file_io_threads          | 4                            |
| innodb_flush_log_at_trx_commit  | 1                            |
| innodb_flush_method             |                              |
| innodb_force_recovery           | 0                            |
| innodb_lock_wait_timeout        | 50                           |
| innodb_log_arch_dir             |                              |
| innodb_log_archive              | OFF                          |
| innodb_log_buffer_size          | 1048576                      |
| innodb_log_file_size            | 5242880                      |
| innodb_log_files_in_group       | 2                            |
| innodb_log_group_home_dir       | ./                           |
| innodb_mirrored_log_groups      | 1                            |
| innodb_thread_concurrency       | 8                            |
| interactive_timeout             | 28800                        |
| join_buffer_size                | 131072                       |
| key_buffer_size                 | 16773120                     |
| key_cache_age_threshold         | 300                          |
| key_cache_block_size            | 1024                         |
| key_cache_division_limit        | 100                          |
| language                        | /usr/local/mysql/share/...   |
| large_files_support             | ON                           |
| local_infile                    | ON                           |
| locked_in_memory                | OFF                          |
| log                             | OFF                          |
| log_bin                         | OFF                          |
| log_slave_updates               | OFF                          |
| log_slow_queries                | OFF                          |
| log_update                      | OFF                          |
| log_warnings                    | OFF                          |
| long_query_time                 | 10                           |
| low_priority_updates            | OFF                          |
| lower_case_table_names          | 0                            |
| max_allowed_packet              | 1047552                      |
| max_binlog_cache_size           | 4294967295                   |
| max_binlog_size                 | 1073741824                   |
| max_connect_errors              | 10                           |
| max_connections                 | 100                          |
| max_delayed_threads             | 20                           |
| max_error_count                 | 64                           |
| max_heap_table_size             | 16777216                     |
| max_join_size                   | 4294967295                   |
| max_relay_log_size              | 0                            |
| max_sort_length                 | 1024                         |
| max_tmp_tables                  | 32                           |
| max_user_connections            | 0                            |
| max_write_lock_count            | 4294967295                   |
| myisam_max_extra_sort_file_size | 268435456                    |
| myisam_max_sort_file_size       | 2147483647                   |
| myisam_recover_options          | force                        |
| myisam_repair_threads           | 1                            |
| myisam_sort_buffer_size         | 8388608                      |
| net_buffer_length               | 16384                        |
| net_read_timeout                | 30                           |
| net_retry_count                 | 10                           |
| net_write_timeout               | 60                           |
| open_files_limit                | 1024                         |
| pid_file                        | /usr/local/mysql/name.pid    |
| port                            | 3306                         |
| protocol_version                | 10                           |
| query_cache_limit               | 1048576                      |
| query_cache_size                | 0                            |
| query_cache_type                | ON                           |
| read_buffer_size                | 131072                       |
| read_rnd_buffer_size            | 262144                       |
| rpl_recovery_rank               | 0                            |
| server_id                       | 0                            |
| skip_external_locking           | ON                           |
| skip_networking                 | OFF                          |
| skip_show_database              | OFF                          |
| slave_net_timeout               | 3600                         |
| slow_launch_time                | 2                            |
| socket                          | /tmp/mysql.sock              |
| sort_buffer_size                | 2097116                      |
| sql_mode                        |                              |
| table_cache                     | 64                           |
| table_type                      | MYISAM                       |
| thread_cache_size               | 3                            |
| thread_stack                    | 131072                       |
| timezone                        | EEST                         |
| tmp_table_size                  | 33554432                     |
| tmpdir                          | /tmp/:/mnt/hd2/tmp/          |
| tx_isolation                    | READ-COMMITTED               |
| version                         | 4.0.4-beta                   |
| wait_timeout                    | 28800                        |
+---------------------------------+------------------------------+

La plupart des variables système sont présentées ici. Les variables sans version sont présentes depuis MySQL 3.22. Les variables système InnoDB sont listées dans Section 15.5, « Options de démarrage InnoDB »15.5. Options de démarrage InnoDB.

Les valeurs pour les tailles de buffer, longueur et taille de pile sont données en octets, à moins que cela ne soit spécifié autrement.

Les informations sur le choix des valeurs de ces paramètres sont disponibles dans Section 7.5.2, « Réglage des paramètres du serveur »7.5.2. Réglage des paramètres du serveur.

• ansi_mode

  Vaut ON si mysqld a été démarré en mode --ansi. Voir Section 1.5.3, « Exécuter MySQL en mode ANSI »1.5.3. Exécuter MySQL en mode ANSI. Cette variable a été ajoutée en MySQL 3.23.6 et supprimée en 3.23.41. Voyez la description de sql_mode.

• back_log

  Le nombre de connexions sortantes que MySQL peut supporter. Cette valeur entre en jeu lorsque le thread principal MySQL reçoit de très nombreuses requêtes de connexion en très peu de temps. MySQL prend un peu de temps (même si c'est très peu de temps), pour vérifier la connexion et démarrer un nouveau thread. La valeur de back_log indique combien de requêtes seront mises en attente durant ce temps. Vous devrez augmenter ce nombre si vous voulez mettre en attente plus de requêtes durant une courte période de temps.

  En d'autres termes, cette valeur est la taille de la queue d'attente pour les connexions TCP/IP entrantes. Votre système d'exploitation a ses propres limites pour ce type de queue. La page du manuel Unix listen(2) doit contenir plus de détails. Vérifiez la documentation de votre OS pour connaître la valeur maximale de votre système. Si vous donnez une valeur à back_log qui est plus grande que celle que votre système supporte, cela restera sans effet.

• basedir

  Le dossier d'installation de MySQL. La valeur de l'option --basedir.

• bdb_cache_size

  Le buffer qui est alloué pour mettre en cache des lignes et des index pour les tables BDB. Si vous n'utilisez pas les tables BDB, vous devriez démarrer mysqld avec l'option --skip-bdb pour ne pas gaspiller de mémoire. Cette variable a été ajoutée en MySQL 3.23.14.

• bdb_home

  Le dossier de base des tables BDB. Cette valeur doit être la même que celle de la variable datadir. Cette variable a été ajoutée en MySQL 3.23.14.

• bdb_log_buffer_size

  Le buffer qui est alloué pour mettre en cache des lignes et des index pour les tables BDB. Si vous n'utilisez pas les tables BDB, vous devriez démarrer mysqld avec l'option --skip-bdb pour ne pas gaspiller de mémoire. Cette variable a été ajoutée en MySQL 3.23.31.

• bdb_logdir

  Le dossier où le moteur BDB écrit les fichiers de log. C'est la valeur de l'option --bdb-logdir. Cette variable a été ajoutée en MySQL 3.23.14.

• bdb_max_lock

  Le nombre maximum de verrous (par défaut 10 000) que vous pouvez activer simultanément dans une table BDB. Vous devriez augmenter cette valeur si vous obtenez des erreurs du type bdb: Lock table is out of available locks ou Got error 12 from ... lorsque vous avez de longues transactions ou que mysqld doit examiner de nombreuses lignes pour calculer la requête.

   

  Sélectionnez

  bdb: Lock table is out of available locks
  Got error 12 from ...

  Cette variable a été ajoutée en MySQL 3.23.29.

• bdb_shared_data

  Vaut ON si vous utilisez l'option --bdb-shared-data. Cette variable a été ajoutée en MySQL 3.23.29.

• bdb_tmpdir

  La valeur de l'option --bdb-tmpdir. Cette variable a été ajoutée en MySQL 3.23.14.

• bdb_version

  La version du moteur BDB. Cette variable a été ajoutée en MySQL 3.23.31.

• binlog_cache_size

  La taille du cache qui contient les requêtes SQL destinées au log binaire, durant une transaction. Un cache binaire est alloué à chaque client si le serveur supporte les moteurs transactionnels, et depuis MySQL 4.1.2, si le serveur a un log binaire activé (option --log-bin). Si vous utilisez souvent de grandes transactions multirequêtes, vous devez augmenter cette valeur pour améliorer les performances. Les variables Binlog_cache_use et Binlog_cache_disk_use sont aussi utiles pour optimiser la taille de cette variable. Cette variable a été ajoutée en MySQL 3.23.29. Voir Section 5.9.4, « Le log binaire »5.9.4. Le log binaire.

• bulk_insert_buffer_size

  MyISAM utilise un cache hiérarchisé pour les insertions de masse (c'est-à-dire INSERT ... SELECT, INSERT ... VALUES (...), (...), ..., et LOAD DATA INFILE). Cette variable limite la taille du cache en octets, par threads. Utiliser la valeur de 0 va désactiver cette optimisation. Note : ce cache est uniquement utilisé lorsque vous ajoutez des données dans une table non vide. Par défaut, cette option vaut 8 Mo. Cette variable a été ajoutée en MySQL 4.0.3. Cette variable s'appelait myisam_bulk_insert_tree_size.

• character_set

  Le jeu de caractères par défaut. Cette variable a été ajoutée en MySQL 3.23.3, puis retirée en MySQL 4.1.1 et remplacée par différentes variables character_set_xxx.

• character_set_client

  Le jeu de caractères pour les commandes du client. Cette variable a été ajoutée en MySQL 4.1.1.

• character_set_connection

  Le jeu de caractères utilisé pour les littéraux qui n'ont pas d'indication de jeu de caractères, pour certaines fonctions et pour les conversions de nombres vers une chaîne. Cette variable a été ajoutée en MySQL 4.1.1.

• character_set_database

  Le jeu de caractères par défaut pour les bases de données. Le serveur modifie cette variable à chaque fois que la base de données par défaut change. S'il n'y a pas de base de données par défaut, cette variable prend la valeur de character_set_server. Cette variable a été ajoutée en MySQL 4.1.1.

• character_set_results

  Le jeu de caractères utilisé pour retourner des résultats au client. Cette variable a été ajoutée en MySQL 4.1.1.

• character_set_server

  Le jeu de caractères par défaut pour le serveur. Cette variable a été ajoutée en MySQL 4.1.1.

• character_set_system

  Le jeu de caractères utilisé par le serveur pour stocker des identifiants. Cette valeur est toujours utf8. Cette variable a été ajoutée en MySQL 4.1.1.

• character_sets

  Les jeux de caractères supportés. Cette variable a été ajoutée en MySQL 3.23.15.

• collation_connection

  Cette variable a été ajoutée en MySQL 4.1.1.

• collation_database

  La collation utilisée par la base de données par défaut. Le serveur modifie cette variable à chaque fois que la base de données par défaut change. S'il n'y a pas de base de données par défaut, cette variable prend la valeur de collation_server. Cette variable a été ajoutée en MySQL 4.1.1.

• collation_server

  La collation par défaut du serveur. Cette variable a été ajoutée en MySQL 4.1.1.

• concurrent_insert

  Si cette option vaut ON, MySQL va vous permettre de réaliser des commandes INSERT sur les tables MyISAM en même temps que d'autres commandes SELECT seront exécutées. Vous pouvez désactiver cette option en démarrant mysqld avec l'option --safe or --skip-new. Cette variable a été ajoutée en MySQL 3.23.7.

• connect_timeout

  Le nombre de secondes d'attente d'un paquet de connexion avant de conclure avec une erreur Bad handshake.

• datadir

  Le dossier de données de MySQL. C'est la valeur de l'option --datadir.

• default_week_format

  Le mode par défaut pour la fonction WEEK(). Cette variable a été ajoutée en MySQL 4.0.14.

• delay_key_write

  Les options pour les tables MyISAM. Elles peuvent prendre l'une des valeurs suivantes :

  Option	Description
  OFF	DELAYED_KEY_WRITE est ignoré.
  ON	(Par défaut) MySQL va honorer l'option DELAY_KEY_WRITE de CREATE TABLE.
  ALL	Toutes les nouvelles tables ouvertes sont traitées comme si elles étaient créées avec l'option DELAY_KEY_WRITE.

  Si DELAY_KEY_WRITE est activé, cela signifie que le buffer de clés des tables ayant cette option ne sera pas écrit sur le disque dès la fin de la modification de la table, mais attendra que la table soit écrite. Cela accélère notablement les écritures des modifications, mais il faut penser à ajouter une vérification automatique des tables au démarrage avec --myisam-recover=BACKUP,FORCE. Voir aussi Section 5.2.1, « Options de ligne de commande de mysqld »5.2.1. Options de ligne de commande de mysqld et Section 14.1.1, « Options de démarrage MyISAM »14.1.1. Options de démarrage MyISAM.

  Notez que --external-locking n'offre aucune protection contre les corruptions d'index pour les tables qui utilisent les écritures retardées de clés.

  Cette variable a été ajoutée en MySQL 3.23.8.

• delayed_insert_limit

  Après avoir inséré delayed_insert_limit lignes, le gestionnaire de INSERT DELAYED va vérifiez s'il n'y a pas de commande SELECT en attente. Si c'est le cas, il va autoriser ces commandes avant de continuer.

• delayed_insert_timeout

  Combien de temps le thread INSERT DELAYED doit attendre les commandes INSERT avant de s'achever.

• delayed_queue_size

  Quelle taille de file (en lignes) doit être allouée pour gérer les commandes INSERT DELAYED. Si la file se remplit, tous les clients qui émettent des commandes INSERT DELAYED devront attendre un peu de place avant de pouvoir continuer.

• flush

  Cette option vaut ON si vous avez démarré MySQL avec l'option --flush. Cette variable a été ajoutée en MySQL 3.22.9.

• flush_time

  Si cette option a une valeur non nulle, toutes les flush_time secondes, toutes les tables seront fermées (pour libérez des ressources et synchroniser les index sur le disque). Nous ne recommandons cette option que sur les systèmes Windows 9x/Me, ou les systèmes qui ont très peu de ressources. Cette variable a été ajoutée en MySQL 3.22.18.

• ft_boolean_syntax

  Liste des opérateurs supportés par IN BOOLEAN MODE. Cette variable a été ajoutée en MySQL 4.0.1. Voir Section 12.6.1, « Booléens de recherches en texte intégral »12.6.1. Booléens de recherches en texte intégral.

  La valeur par défaut de cette variable est '+ -><()~*:""&|'. Les règles pour modifier cette valeur sont les suivantes :

  • la fonction de l'opérateur est déterminée par sa position dans la chaîne ;

  • la chaîne de remplacement doit faire 14 caractères ;

  • chaque caractère doit être ASCII, non alphanumérique ;

  • le premier ou le deuxième caractère doit être un espace ;

  • aucun doublon n'est autorisé, hormis les opérateurs guillemets aux positions 11 et 12. Ce deux caractères ne sont pas obligatoirement les mêmes, mais ce sont les deux seuls qui peuvent l'être ;

  • les positions 10, 13 et 14 (qui sont par défaut ':', '&' et '|') sont réservées pour une utilisation ultérieure.

• ft_max_word_len

  La taille maximale d'un mot à inclure dans un index FULLTEXT. Cette variable a été ajoutée en MySQL 4.0.0.

  Note : les index FULLTEXT doivent être reconstruits après chaque modification de cette variable. Utilisez REPAIR TABLE tbl_name QUICK.

• ft_min_word_len

  La taille minimale d'un mot à inclure dans un index FULLTEXT. Cette variable a été ajoutée en MySQL 4.0.0.

  Note  : les index FULLTEXT doivent être reconstruits après chaque modification de cette variable. Utilisez REPAIR TABLE tbl_name QUICK.

• ft_query_expansion_limit

  Le nombre de solutions générales à utiliser pour les extensions de recherche avec WITH QUERY EXPANSION. Cette variable a été ajoutée en MySQL 4.1.1.

• ft_stopword_file

  Un fichier dans lequel lire une liste de mots interdits pour les recherches en texte plein. Tous les mots du fichier seront utilisés : les commentaires ne sont pas respectés. Par défaut, des listes de mots interdits internes sont utilisées, telles que définies dans myisam/ft_static.c). En donnant à cette option la valeur d'une chaîne vide "", vous désactivez le filtre de mots interdits.

  Note  : les index FULLTEXT doivent être reconstruits après chaque modification de cette variable. Utilisez la commande REPAIR TABLE tbl_name QUICK. Cette variable a été ajoutée en MySQL 4.1.0.

• group_concat_max_len

  La taille maximale de la chaîne résultat de GROUP_CONCAT(). Cette variable a été ajoutée en MySQL 4.1.0.

• have_bdb

  YES si mysqld supporte les tables BDB. DISABLED si --skip-bdb a été utilisé. Cette variable a été ajoutée en MySQL 3.23.30.

• have_innodb

  YES si mysqld supporte les tables InnoDB. DISABLED si --skip-innodb a été utilisé. Cette variable a été ajoutée en MySQL 3.23.37.

• have_isam

  YES si mysqld supporte les tables ISAM. DISABLED si --skip-isam a été utilisé. Cette variable a été ajoutée en MySQL 3.23.30.

• have_raid

  YES si mysqld supporte les tables RAID. Cette variable a été ajoutée en MySQL 3.23.30.

• have_openssl

  YES si mysqld supporte le chiffrement SSL avec le protocole de communication client/serveur. Cette variable a été ajoutée en MySQL 3.23.43.

• init_connect

  Une chaîne à exécuter sur le serveur lors de chaque connexion. La chaîne est constituée d'une ou plusieurs commandes SQL. Pour spécifier une commande multiple, séparez les requêtes individuelles par des points-virgules. Cette variable a été ajoutée en MySQL version 4.1.2.

  Par exemple, chaque client commence par défaut avec le mode d'autovalidation activé. Il n'y a pas de variable globale à spécifier pour désactiver l'autovalidation, et init_connect peut servir à ça :

   

  Sélectionnez

  SET GLOBAL init_connect='SET AUTOCOMMIT=0';

  Cette variable peut aussi être configurée en ligne de commande ou dans un fichier d'options. Pour assigner la variable comme montré dans le fichier d'options, ajoutez ces lignes-ci :

   

  Sélectionnez

  [mysqld]
  init_connect='SET AUTOCOMMIT=0'

  Cette variable a été ajoutée en MySQL 4.1.2.

• init_file

  Le nom du fichier spécifié avec l'option --init-file lorsque vous démarrez le serveur. C'est un fichier qui contient les requêtes SQL que vous voulez voir exécutées dès le démarrage. Chaque commande doit être sur une seule ligne, et ne doit pas inclure de commentaires. Cette variable a été ajoutée en MySQL 3.23.2.

• init_slave

  Cette variable est similaire à init_connect, mais la chaîne doit être exécutée par l'esclave, à chaque démarrage du thread SQL. Le format de la chaîne est le même que pour la variable init_connect. Cette variable a été ajoutée en MySQL 4.1.2.

• innodb_xxx

  Les variables système de InnoDB sont listées dans Section 15.5, « Options de démarrage InnoDB »15.5. Options de démarrage InnoDB.

• interactive_timeout

  Le nombre de secondes durant lequel le serveur attend une activité de la part de la connexion avant de la fermer. Un client interactif est un client qui utilise l'option CLIENT_INTERACTIVE avec mysql_real_connect(). Voir aussi wait_timeout.

• join_buffer_size

  La taille du buffer qui est utilisée pour les jointures complètes (les jointures qui n'utilisent pas d'index). Ce buffer est alloué une fois pour chaque jointure entre deux tables. Augmentez cette valeur si vous voulez obtenir des jointures plus rapides, lorsque l'ajout d'index n'est pas possible. Normalement, le mieux est d'ajouter de bons index.

• key_buffer_size

  Les blocs d'index des tables MyISAM et ISAM sont mis en buffer et partagés par tous les threads. key_buffer_size est la taille du buffer utilisé. Le buffer de clés est aussi appelé le cache de clés.

  Augmentez cette valeur pour obtenir une meilleure gestion des index (pour les lectures et écritures multiples), autant que vous le pouvez : 64 Mo sur une machine de 256 Mo est une valeur répandue. Toutefois, si vous utilisez une valeur trop grande (par exemple, plus de 50 % de votre mémoire totale), votre système risque de commencer à utiliser sa mémoire swap, et devenir très lent. N'oubliez pas que MySQL ne met pas en cache les données lues, et il faut laisser le système d'exploitation respirer.

  Pour obtenir encore plus de vitesse lors de l'écriture de plusieurs lignes en même temps, utilisez LOCK TABLES. Voir Section 13.4.5, « Syntaxe de LOCK TABLES/UNLOCK TABLES »13.4.5. Syntaxe de LOCK TABLES/UNLOCK TABLES.

  Vous pouvez vérifier les performances du buffer de clés avec la commande SHOW STATUS et en examinant les variables Key_read_requests, Key_reads, Key_write_requests et Key_writes. Voir Section 13.5.3, « Syntaxe de SHOW »13.5.3. Syntaxe de SHOW.

  Le ratio Key_reads/Key_read_requests doit normalement être inférieur à 0.01. Le ratio Key_writes/Key_write_requests est généralement près de 1 si vous utilisez essentiellement des modifications et des effacements, mais il peut être plus petit si vous avez des modifications qui changent plusieurs lignes en même temps, ou si vous utilisez l'option DELAY_KEY_WRITE.

  La fraction du buffer de clés utilisée est déterminée avec la variable key_buffer_size en conjonction avec la variable Key_blocks_used et la taille de bloc de buffer. Depuis MySQL 4.1.1, la taille de bloc de buffer est disponible dans la variable serveur key_cache_block_size. La fraction utilisée du buffer est :

   

  Sélectionnez

  (Key_blocks_used * key_cache_block_size) / key_buffer_size

  Avant MySQL 4.1.1, les blocs du cache de clés étaient de 1024 octets, ce qui fait que la fraction utilisée était :

   

  Sélectionnez

  (Key_blocks_used * 1024) / key_buffer_size

  Voir Section 7.4.6, « Le cache de clés des tables MyISAM »7.4.6. Le cache de clé des tables MyISAM.

• key_cache_age_threshold

  Cette valeur contrôle le transit des buffers d'une sous-chaîne de cache de clés vers une autre, moins prioritaire. Les valeurs les plus basses accroissent la vitesse de transit. La valeur minimale est de 100. La valeur par défaut est 300. Cette variable a été ajoutée en MySQL 4.1.1. Voir Section 7.4.6, « Le cache de clés des tables MyISAM »7.4.6. Le cache de clés des tables MyISAM.

• key_cache_block_size

  La taille du bloc de cache de clés, en octets. La valeur par défaut est 1024. Cette variable a été ajoutée en MySQL 4.1.1. Voir Section 7.4.6, « Le cache de clés des tables MyISAM »7.4.6. Le cache de clés des tables MyISAM.

• key_cache_division_limit

  Le point de division entre la sous-chaîne prioritaire et la seconde sous-chaîne. Cette valeur est le pourcentage du buffer à utiliser pour la sous-chaîne secondaire. Les valeurs possibles vont de 1 à 100. La valeur par défaut est 100. Cette variable a été ajoutée en MySQL 4.1.1. Voir Section 7.4.6, « Le cache de clés des tables MyISAM »7.4.6. Le cache de clés des tables MyISAM.

• language

  La langue utilisée pour les messages d'erreurs.

• large_file_support

  Si mysqld a été compilé avec le support des grands fichiers. Cette variable a été ajoutée en MySQL 3.23.28.

• local_infile

  Si mysqld a été configuré avec le support de LOCAL pour les commandes LOAD DATA INFILE. Cette variable a été ajoutée en MySQL 4.0.3.

• locked_in_memory

  Si mysqld a été verrouillé en mémoire avec --memlock Cette variable a été ajoutée en MySQL 3.23.25.

• log

  Si le log de toutes les requêtes est activé. Voir Section 5.9.2, « Le log général de requêtes »5.9.2. Le log général de requêtes.

• log_bin

  Si le log binaire est activé. Cette variable a été ajoutée en MySQL 3.23.14. Voir Section 5.9.4, « Le log binaire »5.9.4. Le log binaire.

• log_slave_updates

  Si les modifications des esclaves doivent être enregistrées. Le log binaire doit être activé pour que cette option fonctionne. Cette variable a été ajoutée en MySQL 3.23.17. Voir Section 6.8, « Options de démarrage de la réplication »6.8. Options de démarrage de la réplication.

• log_slow_queries

  Indique si les requêtes lentes doivent être enregistrées. « Lente » est déterminé par la valeur de long_query_time. Cette variable a été ajoutée en MySQL 4.0.2. Voir Section 5.9.5, « Le log des requêtes lentes »5.9.5. Le log des requêtes lentes.

• log_update

  Si le log de modifications est activé. Cette variable a été ajoutée en MySQL 3.22.18. Notez que le log binaire est préférable au log de modifications, qui n'est plus disponible en MySQL 5.0. Voir Section 5.9.3, « Le log de modification »5.9.3. Le log de modification.

• long_query_time

  Si une requête prend plus de long_query_time secondes, le compteur de requêtes lentes Slow_queries sera incrémenté. Si vous utilisez l'option --log-slow-queries, ces requêtes seront enregistrées dans un historique de requêtes lentes. Cette durée est mesurée en temps réel, et non pas en temps processus, ce qui fait que les requêtes qui seraient juste sous la limite avec un système légèrement chargé, pourraient être au-dessus avec le même système, mais chargé. Voir Section 5.9.5, « Le log des requêtes lentes »5.9.5. Le log des requêtes lentes.

• low_priority_updates

  Si cette option vaut 1, toutes les requêtes INSERT, UPDATE, DELETE et LOCK TABLE WRITE attendent qu'il n'y ait plus de SELECT ou de LOCK TABLE READ en attente pour cette table. Cette variable s'appelait avant sql_low_priority_updates. Cette variable a été ajoutée en MySQL 3.22.5.

• lower_case_table_names

  Si cette option vaut 1, les noms de tables sont stockés en minuscules sur le disque, et les comparaisons de nom de tables seront insensibles à la casse. Depuis la version 4.0.2, cette option s'applique aussi aux noms de bases. Depuis la version 4.1.1 cette option s'applique aussi aux alias de table. Voir Section 9.2.2, « Sensibilité à la casse pour les noms »9.2.2. Sensibilité à la casse pour les noms.

  Vous ne devez pas mettre cette variable à 0 si vous utilisez MySQL sur un serveur qui n'a pas de sensibilité à la casse au niveau du système de fichiers (comme Windows ou Mac OS X). Nouveau en 4.0.18 : si cette variable vaut 0 est que le système de fichiers n'est pas sensible à la casse, MySQL va automatiquement donner la valeur de 2 à lower_case_table_names.

• max_allowed_packet

  La taille maximale d'un paquet.

  Le buffer de messages est initialisé avec net_buffer_length octets, mais peut grandir jusqu'à max_allowed_packet octets lorsque nécessaire. Cette valeur est par défaut petite, pour intercepter les gros paquets, probablement erronés.

  Vous devez augmenter cette valeur si vous utilisez de grandes colonnes BLOB. Cette valeur doit être aussi grande que le plus grand BLOB que vous utiliserez. Le protocole limite actuellement max_allowed_packet à 16 Mo en MySQL 3.23 et 1 Go en MySQL 4.0.

• max_binlog_cache_size

  Si une transaction multirequête requiert plus que cette quantité de mémoire, vous obtiendrez une erreur "Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage". Cette variable a été ajoutée en MySQL 3.23.29.

• max_binlog_size

  Disponible depuis la version 3.23.33. Si vous écrivez dans le log binaire (de réplication) et que cela dépasse la taille de max_binlog_size, une erreur sera indiquée. Vous ne pouvez pas donner à max_binlog_size une valeur inférieure à 1024 octets, ou plus grande que 1 Go. Cette variable a été ajoutée en MySQL 3.23.33.

  Notez bien si vous utilisez les transactions : une transaction est écrite en une seule fois dans le log binaire, et elle ne peut pas être répartie en plusieurs fichiers. Par conséquent, si vous avez de grandes transactions, vous verrez peut-être des fichiers de log plus grands que max_binlog_size.

  Si max_relay_log_size vaut 0, la valeur de max_binlog_size s'applique aussi aux logs de relais. max_relay_log_size a été ajoutée en MySQL 4.0.14.

• max_connect_errors

  S'il y a plus que max_connect_errors connexions interrompues depuis un même hôte, cet hôte sera bloqué dans ses prochaines tentatives de connexions. Vous pouvez débloquer un hôte avec la commande FLUSH HOSTS.

• max_connections

  Le nombre maximal de clients simultanés accepté. En augmentant cette valeur, vous augmentez le nombre de pointeurs de fichier que requiert mysqld. Voyez la section Section 7.4.8, « Quand MySQL ouvre et ferme les tables »7.4.8. Quand MySQL ouvre et ferme les tables pour des commentaires sur les pointeurs de fichiers. Voyez aussi la section Section A.2.6, « Erreur Too many connections  »A.2.6. Erreur Too many connections .

• max_delayed_threads

  Ne pas lancer plus que max_delayed_threads threads pour gérer les insertions INSERT DELAYED. Si vous essayez d'insérer des données dans une nouvelle table alors que tous les gestionnaires INSERT DELAYED sont utilisés, la ligne sera insérée comme si l'option DELAYED n'avait pas été spécifiée. Cette variable a été ajoutée en MySQL 3.23.0.

• max_error_count

  Le nombre maximum d'erreurs, alertes et messages de note à stocker pour afficher avec SHOW ERRORS ou SHOW WARNINGS. Cette variable a été ajoutée en MySQL 4.1.0.

• max_heap_table_size

  Ne pas autoriser la création de tables de type MEMORY (HEAP) plus grande que max_heap_table_size. La valeur de la variable est utilisée pour calculer la valeur maximale de MAX_ROWS pour la table MEMORY. Modifier cette variable n'a pas d'effet sur les tables existantes, à moins que la table ne soit recréée, avec une commande comme CREATE TABLE ou TRUNCATE TABLE, ou encore modifiée avec ALTER TABLE. Cette variable a été ajoutée en MySQL 3.23.0.

• max_insert_delayed_threads

  Cette variable est un synonyme de max_delayed_threads. Cette variable a été ajoutée en MySQL 4.0.19.

• max_join_size

  Les jointures qui liront probablement plus de max_join_size lignes, retourneront une erreur. Utilisez cette valeur si vos utilisateurs font des jointures avec de mauvaises clauses WHERE, qui prennent trop de temps, et retournent des millions de lignes.

  En donnant une valeur à cette variable qui est autre que DEFAULT remet la valeur de SQL_BIG_SELECTS à 0. Si vous modifiez à nouveau la valeur de SQL_BIG_SELECTS, la variable max_join_size sera ignorée.

  Si un résultat de requête est déjà dans le cache de requêtes, aucune limite de taille n'est vérifiée, car le résultat a déjà été compilé, et cela ne posera aucun problème au serveur pour l'envoyer à nouveau.

  Cette variable s'appelait précédemment sql_max_join_size.

• max_relay_log_size

  Disponible depuis la version 4.0.14. Si vous écrivez des données dans un log de relais et que leur taille dépasse la valeur donnée, le log de relais passe au fichier suivant. Cette variable vous permet de placer différentes contraintes de taille sur les logs binaires et de relais. Cependant, en donnant la valeur de 0 à cette valeur, MySQL utilisera max_binlog_size pour les deux logs, binaire et de relais. Vous devez donner à max_relay_log_size la valeur de 0 ou plus de 4096, et moins que 1 Go. Par défaut, c'est 0. Cette variable a été ajoutée en MySQL 4.0.14. Voir Section 6.3, « Détails d'implémentation de la réplication »6.3. Détails d'implémentation de la réplication.

• max_seeks_for_key

  La limite de recherches lors de recherches de lignes basées sur un index. L'optimiseur MySQL va supposer que lorsque vous recherchez des lignes dans une table en analysant les index, vous n'aller pas générer plus de ce nombre de recherches, indépendamment de la cardinalité de la clé. En donnant une valeur faible à cette variable (100 ?) vous pouvez forcer MySQL à préférer les scans d'index plutôt que les scans de tables. Cette variable a été ajoutée en MySQL 4.0.14.

• max_sort_length

  Le nombre d'octets à utiliser lors du tri des colonnes de type BLOB et TEXT. Seuls les max_sort_length octets de chaque valeur seront utilisés pour le tri. Le reste est ignoré.

• max_tmp_tables

  Cette option ne fait encore rien. Le nombre maximal de tables temporaires qu'un client peut garder ouvertes en même temps.

• max_user_connections

  Le nombre maximum de connexions actives pour un utilisateur particulier (0 = pas de limite). Cette variable a été ajoutée en MySQL 3.23.34.

• max_write_lock_count

  Après max_write_lock_count poses de verrou en écriture, autorise quelques verrous en lecture. Cette variable a été ajoutée en MySQL 3.23.7.

• myisam_data_pointer_size

  La taille par défaut du pointeur à utiliser avec CREATE TABLE pour les tables MyISAM lorsque qu'aucune option MAX_ROWS n'est spécifiée. Cette variable ne peut pas être inférieure à 2 ni supérieure à 8. La valeur par défaut est de 4. Cette variable a été ajoutée en MySQL 4.1.2. Voir Section A.2.11, « Erreur The table is full »A.2.11. Erreur The table is full.

• myisam_max_extra_sort_file_size

  Si un fichier temporaire est utilisé pour créer rapidement un fichier d'index pour une table MyISAM est plus grand que la valeur de cette variable, alors préfère la méthode du cache de clés. C'est surtout utilisé pour forcer les grands index à utiliser la méthode plus lente du cache de clés pour créer l'index. Cette variable a été ajoutée en MySQL 3.23.37. Note : la valeur donnée est en mégaoctets avant 4.0.3 et en octets après.

• myisam_max_sort_file_size

  La taille maximale du fichier temporaire que MySQL est autorisé à utiliser durant la recréation des fichiers d'index (avec REPAIR, ALTER TABLE ou LOAD DATA INFILE). Si la taille du fichier dépasse myisam_max_sort_file_size, l'index sera créé avec un cache de clés (plus lent). Cette variable a été ajoutée en MySQL 3.23.37. Note : ce paramètre est spécifié en mégaoctets avant la version 4.0.3 et en octets depuis.

• myisam_recover_options

  La valeur de l'option --myisam-recover. Cette variable a été ajoutée en MySQL 3.23.36.

• myisam_repair_threads

  Si cette valeur est plus grande que 1, les index des tables MyISAM durant un processus de Repair by sorting seront créés en parallèle : chaque index avec son propre thread. Note : les réparations multithreadées sont encore en développement, et en qualité alpha. Cette variable a été ajoutée en MySQL 4.0.13.

• myisam_sort_buffer_size

  Le buffer qui est alloué lors du tri d'index avec la commande REPAIR ou lors de la création d'index avec CREATE INDEX ou ALTER TABLE. Cette variable a été ajoutée en MySQL 3.23.16.

• named_pipe

  Sous Windows, indique si le serveur supporte les connexions via les pipes nommés. Cette variable a été ajoutée en MySQL 3.23.50.

• net_buffer_length

  Le buffer de communications est remis à zéro entre deux requêtes. Cela ne devrait pas être modifié, mais si vous avez très peu de mémoire, vous pouvez le remettre à la taille présumée de la requête (c'est-à-dire, la taille de la requête envoyée par le client. Si la requête dépasse cette taille, le buffer est automatiquement agrandi jusqu'à max_allowed_packet octets).

• net_read_timeout

  Nombre de secondes d'attente des dernières données, avant d'annuler la lecture. Notez que lorsque nous n'attendons pas de données d'une connexion, le délai d'expiration est donné par write_timeout. Voir aussi slave_net_timeout. Cette variable a été ajoutée en MySQL 3.23.20.

• net_retry_count

  Si une lecture sur un port de communication est interrompue, net_retry_count tentatives sont faites avant d'abandonner. Cette valeur doit être particulièrement grande pour FreeBSD, car les interruptions internes sont envoyées à tous les threads. Cette variable a été ajoutée en MySQL 3.23.7.

• net_write_timeout

  Nombre de secondes d'attente pour qu'un bloc soit envoyé à une connexion, avant d'annuler l'écriture. Voir aussi net_read_timeout. Cette variable a été ajoutée en MySQL 3.23.20.

• open_files_limit

  Si open_files_limit ne vaut pas 0, alors mysqld va utiliser cette valeur pour réserver des pointeurs de fichiers à utiliser avec setrlimit(). Si cette valeur est 0, alors mysqld va réserver max_connections*5 ou max_connections + table_cache*2 (le plus grand des deux) pointeurs de fichiers. Vous devriez augmenter cette valeur si mysqld vous donne des erreurs du type 'Too many open files'.

• pid_file

  Le chemin vers le fichier de processus (PID). La valeur de l'option --pid-file. Cette variable a été ajoutée en MySQL 3.23.23.

• port

  Le port de connexion sur lequel le serveur attend les connexions TCP/IP. Cette variable peut être spécifiée avec --port.

• protocol_version

  La version du protocole utilisé par le serveur MySQL. Cette variable a été ajoutée en MySQL 3.23.18.

• query_alloc_block_size

  Taille des blocs de mémoire alloués pour les objets durant l'analyse et la préparation des requêtes. Si vous avez un problème avec la fragmentation de la mémoire, cela peut être utile d'augmenter cette valeur. Cette variable a été ajoutée en MySQL 4.0.16.

• query_cache_limit

  Ne met pas en cache les résultats qui sont plus grands que query_cache_limit. Par défaut, 1 Mo. Cette variable a été ajoutée en MySQL 4.0.1.

• query_cache_min_res_unit

  La taille minimale pour les blocs alloués par le cache de requêtes. La valeur par défaut est de 4 ko. Des informations sur l'optimisation de cette variable sont données dans la section Section 5.11.3, « Configuration du cache de requêtes »5.11.3. Configuration du cache de requêtes. Cette variable a été ajoutée en MySQL 4.1.

• query_cache_size

  La mémoire allouée pour stocker les résultats des vieilles requêtes. Si query_cache_size vaut 0, le cache de requêtes est désactivé (par défaut). Cette variable a été ajoutée en MySQL 4.0.1.

• query_cache_type

  Choisit le type de cache de requêtes. Modifier la variable GLOBAL modifie le cache pour tous les clients. Les clients peuvent modifier la variable de SESSION pour l'adapter à leur utilisation.

  query_cache_type peut prendre les valeurs numériques suivantes :

  Option	Description
  0 or OFF	Ne met pas en cache les résultats. Notez que cela ne va pas libérer le buffer de requête. Pour cela, il faut donner à query_cache_size la valeur de 0.
  1 or ON	Met en cache tous les résultats exceptés les requêtes SELECT SQL_NO_CACHE ....
  2 or DEMAND	Met en cache uniquement les requêtes SELECT SQL_CACHE ....

  Cette variable a été ajoutée en MySQL 4.0.3.

• query_cache_wlock_invalidate

  Normalement, lorsqu'un client pose un verrou WRITE sur une table MyISAM, les autres clients ne sont pas empêchés d'émettre des requêtes sur la table, si le résultat est déjà en cache. En donnant la valeur de 1 à cette variable, le verrou WRITE empêchera toutes les requêtes qui feront référence à cette table. Cela force les autres clients à attendre que le verrou se libère. Cette variable a été ajoutée en MySQL 4.0.19.

• query_prealloc_size

  La taille du buffer persistant utilisé pour l'analyse des requêtes et leur exécution. Ce buffer n'est pas libéré entre deux requêtes. Si vous manipulez des requêtes complexes, une valeur plus grande pour query_prealloc_size sera plus utile pour améliorer les performances, car elle peut réduire les allocations complémentaires de mémoire durant l'exécution des requêtes.

  Cette variable a été ajoutée en MySQL 4.0.16.

• range_alloc_block_size

  La taille de bloc qui est alloué lors de l'optimisation d'intervalle. Cette variable a été ajoutée en MySQL 4.0.16.

• read_buffer_size

  Chaque thread qui fait une recherche séquentielle alloue un buffer de cette taille pour son scan. Si vous faites de nombreux scans séquentiels, vous pourriez avoir besoin d'augmenter cette valeur. Cette variable a été ajoutée en MySQL 4.0.3. Auparavant, cette variable s'appelait record_buffer.

• read_only

  Lorsque cette variable vaut ON pour un serveur de réplication esclave, cela fait que le serveur ne permet aucune modification, hormis celles de la réplication, ou des utilisateurs ayant le droit de SUPER. Cela peut être pratique pour s'assurer qu'un esclave n'accepte aucune modification des clients. Cette variable a été ajoutée en MySQL 4.0.14.

• read_rnd_buffer_size

  Lors de la lecture des lignes triées, les lignes sont lues dans un buffer, pour éviter les accès disques. En donnant à cette variable une grande valeur, vous améliorerez les performances des clauses ORDER BY. Cependant, ce buffer est alloué pour chaque client : il est recommandé de ne pas donner une valeur globale trop importante. Au lieu de cela, modifiez cette valeur si votre client a besoin de faire de gros tris. Cette variable a été ajoutée en MySQL 4.0.3. Auparavant, cette variable s'appelait record_rnd_buffer.

• safe_show_database

  Ne montre pas les bases pour lesquelles un utilisateur n'a pas des droits de bases ou de tables. Cela peut améliorer considérablement la sécurité si vous craignez de voir les utilisateurs découvrir ce que les autres ont mis en place. Voir aussi skip_show_database.

  Cette variable a été supprimée en MySQL 4.0.5. À la place, utilisez le droit SHOW DATABASES pour contrôler les accès aux noms des bases de données.

• secure_auth

  Si le serveur MySQL a été lancé avec l'option --secure-auth, il va empêcher les connexions des comptes qui ont un compte au format préversion 4.1. Dans ce cas, la valeur de cette variable vaut ON, sinon, c'est OFF.

  Vous devriez activer cette option si vous voulez empêcher l'utilisation des mots de passe à l'ancien format (et donc, améliorer la sécurité de votre serveur). Cette variable a été ajoutée en MySQL 4.1.1.

  Le démarrage du serveur échouera avec une erreur si cette option est activée, mais que la table de droits est toujours au format préversion 4.1.

  Lorsqu'elle est utilisée comme une option du client, le client va refuser de se connecter au serveur si le serveur requiert un mot de passe à l'ancien format.

• server_id

  La valeur de l'option --server-id. Elle sert à la réplication. Cette variable a été ajoutée en MySQL 3.23.26.

• skip_external_locking

  skip_locking vaut OFF si mysqld utilise le verrouillage externe. Cette variable a été ajoutée en MySQL 4.0.3. Auparavant, cette variable s'appelait skip_locking.

• skip_networking

  skip_networking vaut ON si seules les connexions locales (via socket) sont autorisées. Sous Unix, les connexions locales utilisent un fichier de socket Unix. Sous Windows, les connexions locales utilisent les pipes nommés. Sous NetWare, seules les connexions TCP/IP sont supportées, alors ne donnez pas la valeur de ON à cette variable. Cette variable a été ajoutée en MySQL 3.22.23.

• skip_show_database

  skip_show_database empêche les utilisateurs d'exécuter des commandes SHOW DATABASES s'ils n'ont pas les droits de PROCESS. Cela peut améliorer la sécurité si vous craignez de voir les utilisateurs découvrir ce que les autres ont mis en place. Voir aussi safe_show_database. Cette variable a été ajoutée en MySQL 3.23.4. Depuis MySQL 4.0.2, son effet dépend aussi du droit SHOW DATABASES : si la variable vaut ON, la commande SHOW DATABASES n'est autorisée qu'aux comptes ayant le droit de SHOW DATABASES, et la commande affiche tous les noms de bases. Si la valeur est OFF, SHOW DATABASES est autorisé à tous les utilisateurs, mais il n'affichera que les noms de bases de données pour lesquelles l'utilisateur a le droit de SHOW DATABASES ou un droit quelconque dans la base.

• slave_net_timeout

  Nombre de secondes d'attente de données en lecture ou écriture sur une connexion maître/esclave avant d'annuler. Cette variable a été ajoutée en MySQL 3.23.40.

• slow_launch_time

  Si la création du thread prend plus de slow_launch_time secondes, le compteur de threads lents Slow_launch_threads sera incrémenté. Cette variable a été ajoutée en MySQL 3.23.15.

• socket

  La socket Unix utilisé par le serveur. Sous Unix, c'est le fichier de socket Unix, pour les connexions locales. Sous Windows, c'est le nom du pipe nommé, pour les connexions locales.

• sort_buffer_size

  Chaque thread qui doit faire un tri alloue un buffer de cette taille. Augmentez cette taille pour accélérer les clauses ORDER BY ou GROUP BY. Voir Section A.4.4, « Où MySQL stocke les fichiers temporaires ? »A.4.4. Où MySQL stocke les fichiers temporaires ?.

• sql_mode

  Le mode SQL courant. Cette variable a été ajoutée en MySQL 3.23.41. Voir Section 5.2.2, « Le mode SQL du serveur »5.2.2. Le mode SQL du serveur.

• storage_engine

  Cette variable est un synonyme de table_type. Cette variable a été ajoutée en MySQL 4.1.2.

• table_cache

  Le nombre de tables ouvertes pour tous les threads réunis. En augmentant cette valeur, vous augmentez le nombre de pointeurs de fichiers que mysqld utilise. Vous pouvez vérifier si vous avez besoin de plus de cache de tables en étudiant la valeur de la variable Opened_tables. Voir Section 5.2.4, « Variables de statut du serveur  »5.2.4. Variables de statut du serveur . Si cette variable est grande, c'est que vous ne faites pas souvent de commandes FLUSH TABLES (qui forcent les tables à se recharger), vous devrez alors augmenter cette valeur.

  Pour plus d'informations sur le cache de tables, voyez Section 7.4.8, « Quand MySQL ouvre et ferme les tables »7.4.8. Quand MySQL ouvre et ferme les tables.

• table_type

  Le type de table par défaut. Pour configurer le type de table par défaut au démarrage, utilisez --default-table-type. Cette variable a été ajoutée en MySQL 3.23.0. Voir Section 5.2.1, « Options de ligne de commande de mysqld »5.2.1. Options de ligne de commande de mysqld.

• thread_cache_size

  Combien de threads nous allons conserver en cache pour réutilisation. Lorsqu'un client se déconnecte, les threads du client sont mis en cache s'il n'y en a pas déjà thread_cache_size de conservé. Tous les nouveaux threads sont d'abord prélevés dans le cache, et uniquement lorsque le cache est vide, un nouveau thread est créé. Cette variable peut vous permettre d'améliorer les performances si vous avez de nombreuses connexions. Normalement, thread_cache_size ne donne pas d'amélioration notable si vous avez une bonne implémentation des threads. En examinant la différence entre les variables de statut Connections et Threads_created vous pouvez voir comment votre système de cache de threads est efficace. (Voir Section 5.2.4, « Variables de statut du serveur  »5.2.4. Variables de statut du serveur pour plus de détails) Cette variable a été ajoutée en MySQL 3.23.16.

• thread_concurrency

  Sous Solaris, mysqld va appeler thr_setconcurrency() avec cette valeur. thr_setconcurrency() permet à l'application de donner au système de threads une indication sur le nombre de threads qui seront exécutés en même temps. Cette variable a été ajoutée en MySQL 3.23.7.

• thread_stack

  La taille de la pile pour chaque thread. De nombreuses limites détectées par crash-me sont dépendantes de cette valeur. La valeur par défaut est suffisamment grande pour des opérations normales. Voir Section 7.1.4, « La suite de tests MySQL »7.1.4. La suite de tests MySQL.

• timezone

  Le fuseau horaire du serveur. Cette option prend la valeur de la variable d'environnement TZ lorsque mysqld est démarré. Elle peut aussi être modifiée avec l'argument --timezone de mysqld_safe. Cette variable a été ajoutée en MySQL 3.23.15. Voir Section A.4.6, « Problèmes de fuseaux horaires »A.4.6. Problèmes de fuseaux horaires.

• tmp_table_size

  Si une table temporaire en mémoire excède cette taille, MySQL va automatiquement la convertir en une table MyISAM sur le disque. Augmentez la valeur de tmp_table_size si vous faites un usage intensif de la clause GROUP BY et que vous avez beaucoup de mémoire.

• tmpdir

  Le dossier utilisé pour les fichiers temporaires et les tables temporaires. Depuis MySQL 4.1, cette variable peut prendre une liste de différents chemins, qui sont utilisés circulairement. Les chemins doivent être séparés par des deux-points (':') sous Unix et des points-virgules (';') sous Windows, NetWare et OS/2.

  Cette fonctionnalité permet de répartir la charge en plusieurs disques. Si le serveur MySQL sert d'esclave de réplication, vous ne devez pas faire pointer tmpdir sur un dossier en mémoire, car il sera vidé si le serveur redémarre. Un esclave de réplication doit pouvoir reprendre ses fichiers temporaires pour que la réplication puisse redémarrer, en incluant les tables temporaires et les opérations de LOAD DATA INFILE. Si les fichiers du dossier temporaire sont perdus au redémarrage, la réplication s'arrêtera.

  Cette variable a été ajoutée en MySQL 3.22.4.

• transaction_alloc_block_size

  La taille de bloc d'allocation de mémoire pour le stockage des requêtes qui font partie d'une transaction, qui sera stockée dans le log binaire durant une validation. Cette variable a été ajoutée en MySQL 4.0.16.

• transaction_prealloc_size

  Le buffer persistant pour transaction_alloc_blocks, qui n'est pas libéré entre deux requêtes. En rendant ce buffer « assez grand » pour accommoder toutes les requêtes dans une transaction classique, vous pouvez éviter de nombreux appels malloc(). Cette variable a été ajoutée en MySQL 4.0.16.

• tx_isolation

  Le niveau par défaut d'isolation de transactions. Cette variable a été ajoutée en MySQL 4.0.3.

• version

  Le numéro de version du serveur.

• wait_timeout

  Le nombre de secondes d'attente du serveur sur une connexion non interactive avant de la refermer.

  Lors du démarrage du thread, SESSION.WAIT_TIMEOUT est initialisé avec GLOBAL.WAIT_TIMEOUT ou GLOBAL.INTERACTIVE_TIMEOUT, suivant le type de client (tel que défini par l'option de connexion CLIENT_INTERACTIVE). Voir aussi interactive_timeout.

5-2-3-1. Variables système dynamiques▲

SHOW STATUS affiche des informations sur le statut du serveur (par exemple, mysqladmin extended-status). L'affichage ressemble à ce qui est affiché ci-dessous, mais les valeurs différeront sûrement de votre propre serveur.

mysql> SHOW STATUS;
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| Aborted_clients          | 0          |
| Aborted_connects         | 0          |
| Bytes_received           | 155372598  |
| Bytes_sent               | 1176560426 |
| Connections              | 30023      |
| Created_tmp_disk_tables  | 0          |
| Created_tmp_files        | 60         |
| Created_tmp_tables       | 8340       |
| Delayed_errors           | 0          |
| Delayed_insert_threads   | 0          |
| Delayed_writes           | 0          |
| Flush_commands           | 1          |
| Handler_delete           | 462604     |
| Handler_read_first       | 105881     |
| Handler_read_key         | 27820558   |
| Handler_read_next        | 390681754  |
| Handler_read_prev        | 6022500    |
| Handler_read_rnd         | 30546748   |
| Handler_read_rnd_next    | 246216530  |
| Handler_update           | 16945404   |
| Handler_write            | 60356676   |
| Key_blocks_used          | 14955      |
| Key_read_requests        | 96854827   |
| Key_reads                | 162040     |
| Key_write_requests       | 7589728    |
| Key_writes               | 3813196    |
| Max_used_connections     | 0          |
| Not_flushed_delayed_rows | 0          |
| Not_flushed_key_blocks   | 0          |
| Open_files               | 2          |
| Open_streams             | 0          |
| Open_tables              | 1          |
| Opened_tables            | 44600      |
| Qcache_free_blocks       | 36         |
| Qcache_free_memory       | 138488     |
| Qcache_hits              | 79570      |
| Qcache_inserts           | 27087      |
| Qcache_lowmem_prunes     | 3114       |
| Qcache_not_cached        | 22989      |
| Qcache_queries_in_cache  | 415        |
| Qcache_total_blocks      | 912        |
| Questions                | 2026873    |
| Select_full_join         | 0          |
| Select_full_range_join   | 0          |
| Select_range             | 99646      |
| Select_range_check       | 0          |
| Select_scan              | 30802      |
| Slave_open_temp_tables   | 0          |
| Slave_running            | OFF        |
| Slow_launch_threads      | 0          |
| Slow_queries             | 0          |
| Sort_merge_passes        | 30         |
| Sort_range               | 500        |
| Sort_rows                | 30296250   |
| Sort_scan                | 4650       |
| Table_locks_immediate    | 1920382    |
| Table_locks_waited       | 0          |
| Threads_cached           | 0          |
| Threads_connected        | 1          |
| Threads_created          | 30022      |
| Threads_running          | 1          |
| Uptime                   | 80380      |
+--------------------------+------------+

De nombreuses variables de statut sont remises à 0 par la commande FLUSH STATUS.

Les variables de statut ont les significations suivantes. Les variables compteur de commande Com_xxx ont été ajoutées en MySQL 3.23.47. Les variables de cache de requêtes Qcache_xxx ont été ajoutées en MySQL 4.0.1. Sinon, les variables sans versions sont présentes depuis MySQL 3.22.

• Aborted_clients

  Nombre de connexions annulées parce que le client est mort sans se déconnecter correctement. Voir Section A.2.10, « Erreurs de communication / Connexion annulée »A.2.10. Erreurs de communication / Connexion annulée.

• Aborted_connects

  Nombre de tentatives de connexions au serveur MySQL qui ont échoué. Voir Section A.2.10, « Erreurs de communication / Connexion annulée »A.2.10. Erreurs de communication / Connexion annulée.

• Binlog_cache_disk_use

  Le nombre de transactions qui ont utilisé le cache de logs binaires, mais qui ont dépassé la taille de binlog_cache_size et ont finalement utilisé un fichier temporaire pour stocker les commandes de la transaction. Cette variable a été ajoutée en MySQL 4.1.2.

• Binlog_cache_use

  Le nombre de transactions qui ont utilisé le cache de logs binaires temporaires. Cette variable a été ajoutée en MySQL 4.1.2.

• Bytes_received

  Nombre d'octets reçu de tous les clients. Cette variable a été ajoutée en MySQL 3.23.7.

• Bytes_sent

  Nombre d'octets envoyés à tous les clients. Cette variable a été ajoutée en MySQL 3.23.7.

• Com_xxx

  Nombre d'exécutions de chaque commande xxx. Il y a une variable par type de commande. Par exemple, Com_delete et Com_insert comptent respectivement les commandes DELETE et INSERT.

• Connections

  Nombre de tentatives de connexion au serveur MySQL, réussies ou pas.

• Created_tmp_disk_tables

  Nombre de tables temporaires implicites créées sur le disque lors d'exécutions de commandes. Cette variable a été ajoutée en MySQL 3.23.24.

• Created_tmp_files

  Combien de fichiers temporaires mysqld a créés. Si Created_tmp_disk_tables est grand, augmentez la taille de tmp_table_size pour que les tables temporaires restent plus souvent en mémoire.

• Created_tmp_tables

  Nombre de tables temporaires implicites créées en mémoire lors d'exécutions de commandes. Cette variable a été ajoutée en MySQL 3.23.28.

• Delayed_errors

  Nombre de lignes écrites avec INSERT DELAYED pour lesquelles des erreurs sont survenues (probablement une erreur de doublons (duplicate key)).

• Delayed_insert_threads

  Nombre de gestionnaires d'insertions retardées sont en cours d'utilisation.

• Delayed_writes

  Nombre de lignes écrites avec INSERT DELAYED.

• Flush_commands

  Nombre de commandes FLUSH.

• Handler_commit

  Nombre de commandes internes COMMIT. Cette variable a été ajoutée en MySQL 4.0.2.

• Handler_delete

  Nombre de fois qu'une ligne a été effacée dans une table.

• Handler_read_first

  Nombre de fois que la première ligne a été lue dans un index. Si ce chiffre est haut, c'est que le serveur fait de nombreuses recherches par analyse complète de la table, par exemple SELECT col1 FROM foo, en supposant que col1 est indexé.

• Handler_read_key

  Nombre de requêtes de lecture de lignes basées sur une clé. Si ce chiffre est grand, c'est une bonne indication de l'indexation correcte de vos tables.

• Handler_read_next

  Nombre de requêtes de lecture de la ligne suivante en ordre. Cela sera augmenté si vous listez une colonne avec une contrainte d'intervalle. Cette valeur sera aussi incrémentée si vous effectuez un scan d'index.

• Handler_read_prev

  Nombre de requêtes de lecture de la clé précédente, dans l'ordre. C'est souvent utilisé pour optimiser les clauses ORDER BY ... DESC. Cette variable a été ajoutée en MySQL 3.23.6.

• Handler_read_rnd_next

  Nombre de requêtes de lecture de la prochaine ligne dans le fichier de données. Ce chiffre sera grand si vous faites de nombreux scans de tables. Généralement, cela indique que vos requêtes ne sont pas écrites pour profiter des index que vous avez mis en place.

• Handler_read_rnd

  Nombre de lectures d'une ligne basée sur une position fixe. Ce chiffre sera grand si vous effectuez de nombreuses requêtes qui réclament le tri du résultat.

• Handler_rollback

  Nombre de commandes internes ROLLBACK.

• Handler_update

  Nombre de requêtes de modification d'une ligne dans une table.

• Handler_write

  Nombre de requêtes pour insérer une ligne dans une table.

• Key_blocks_used

  Nombre de blocs utilisés dans un cache de clés. Vous pouvez utiliser cette valeur pour déterminer l'occupation du cache de clés : voyez la discussion de key_buffer_size dans Section 5.2.3, « Variables serveur système »5.2.3. Variables serveur système.

• Key_read_requests

  Nombre de requêtes de lecture d'un bloc de clés dans le cache.

• Key_reads

  Nombre de lecture physique d'un bloc de clés sur le disque. Si Key_reads est grand, alors votre valeur pour key_buffer_size est probablement trop petite. Le ratio peut être calculé avec Key_reads/Key_read_requests.

• Key_write_requests

  Nombre de requêtes d'écriture d'un bloc de clés dans le cache.

• Key_writes

  Nombre d'écritures physiques de blocs de clés sur le disque.

• Max_used_connections

  Nombre maximum de connexions utilisées simultanément.

• Not_flushed_delayed_rows

  Nombre de lignes en attente d'écriture dans les listes INSERT DELAY.

• Not_flushed_key_blocks

  Nombre de blocs de clés dans le cache de clés, qui ont été modifiées, mais pas encore écrites sur le disque.

• Open_files

  Nombre de fichiers ouverts.

• Open_streams

  Nombre de flux ouverts (utilisés généralement pour les logs).

• Open_tables

  Nombre de tables ouvertes.

• Opened_tables

  Nombre de tables qui ont été ouvertes. Si Opened_tables est grand, votre valeur pour table_cache est probablement trop petite.

• Qcache_free_blocks

  Le nombre de blocs de mémoire libre dans le cache de requêtes.

• Qcache_free_memory

  La quantité de mémoire libre dans le cache de requêtes.

• Qcache_hits

  Le nombre de sollicitations du cache.

• Qcache_inserts

  Le nombre de requêtes ajoutées dans le cache.

• Qcache_lowmem_prunes

  Le nombre de requêtes qui ont été effacées du cache, pour libérer de la place.

• Qcache_not_cached

  Le nombre de requêtes non cachées (elles ne peuvent pas être mises en cache, ou à cause de query_cache_type).

• Qcache_queries_in_cache

  Le nombre de requêtes enregistrées dans le cache.

• Qcache_total_blocks

  Le nombre total de blocs dans le cache de requêtes.

• Questions

  Nombre de requêtes envoyées au serveur.

• Rpl_status

  Statut de la réplication sans erreur (réservé pour utilisation ultérieure).

• Select_full_join

  Nombre de jointures sans clé (si cette variable vaut 0, vous devriez vérifier soigneusement les index de vos tables). Cette variable a été ajoutée en MySQL 3.23.25.

• Select_full_range_join

  Nombre de jointures où une recherche d'intervalle a été utilisée. Cette variable a été ajoutée en MySQL 3.23.25.

• Select_range_check

  Nombre de jointures sans clé, où l'utilisation de clé a été vérifiée après chaque ligne (si cette variable vaut 0, vous devriez vérifier soigneusement les index de vos tables). Cette variable a été ajoutée en MySQL 3.23.25.

• Select_range

  Nombre de jointures où une recherche d'intervalle a été utilisée sur la première table. (Ce n'est généralement pas important, même si cette valeur est importante.) Cette variable a été ajoutée en MySQL 3.23.25.

• Select_scan

  Nombre de jointures où la première table a été totalement analysée. Cette variable a été ajoutée en MySQL 3.23.25.

• Slave_open_temp_tables

  Nombre de tables temporaires actuellement utilisées par le thread esclave. Cette variable a été ajoutée en MySQL 3.23.29.

• Slave_running

  Cette variable vaut ON si ce serveur est un esclave connecté au maître. Cette variable a été ajoutée en MySQL 3.23.16.

• Slow_launch_threads

  Nombre de threads qui ont pris plus de slow_launch_time secondes pour être créés. Cette variable a été ajoutée en MySQL 3.23.15.

• Slow_queries

  Nombre de requêtes qui ont pris plus de long_query_time pour s'exécuter. Voir Section 5.9.5, « Le log des requêtes lentes »5.9.5. Le log des requêtes lentes.

• Sort_merge_passes

  Nombre de passes que l'algorithme de tri a dû faire. Si cette valeur est grande, vous devriez vérifier la taille de sort_buffer.

• Sort_range

  Nombre de tris qui ont été faits sur des intervalles.

• Sort_rows

  Nombre de lignes triées.

• Sort_scan

  Nombre de tris qui ont été faits en analysant la table.

• ssl_xxx

  Variables utilisées par SSL. Réservée pour utilisation ultérieure. Ces variables ont été ajoutées en MySQL 4.0.0.

• Table_locks_immediate

  Nombre de fois que la table a reçu immédiatement un verrou. Disponible depuis 3.23.33. Cette variable a été ajoutée en MySQL 3.23.33.

• Table_locks_waited

  Nombre de fois qu'une table n'a pu recevoir de verrou immédiatement, et qu'il a fallu attendre. Si ce chiffre est haut, vous avez des problèmes de performance, et vous devriez optimiser vos requêtes, couper vos tables en deux, ou utiliser la réplication. Disponible depuis la version 3.23.33. Cette variable a été ajoutée en MySQL 3.23.33.

• Threads_cached

  Nombre de threads dans le cache de threads. Cette variable a été ajoutée en MySQL 3.23.17.

• Threads_connected

  Nombre de connexions actuellement ouvertes.

• Threads_created

  Nombre de threads créés pour gérer les connexions. Si Threads_created est grand, vous pouvez augmenter la valeur de

• Threads_running

  Nombre de threads qui ne dorment pas.

• Uptime

  Durée de vie du serveur, en secondes depuis le redémarrage.

Tous ceux qui utilisent MySQL avec un serveur connecté à Internet doivent lire cette section, pour éviter les erreurs les plus communes.

En parlant de sécurité, nous devons insister sur la nécessité de protéger tout le serveur, et non pas juste MySQL, contre tous les types d'attaques : surveillance des communications, usurpation, réexécution et dénis de service. Nous ne pouvons pas couvrir tous les aspects de tolérance aux fautes et de disponibilité ici.

MySQL dispose d'un système de sécurité basé sur des listes de contrôle d'accès (Access Control Lists, or ACL) pour toutes les connexions, requêtes et opérations que l'utilisateur peut faire. Il y a aussi le support des connexions SSL entre le client et le serveur MySQL. De nombreux concepts présentés ici ne sont pas spécifiques à MySQL : le même concept s'applique à de nombreuses applications.

Lorsque vous utilisez MySQL, suivez ces règles aussi souvent que possible.

• Ne donnez jamais à personne (sauf aux comptes MySQL root) accès à la table user de la base mysql ! C'est primordial. Le mot de passe chiffré est le vrai mot de passe de MySQL. Toute personne qui connaît le mot de passe de la table user et qui a accès à l'hôte associé peut facilement se connecter sous le nom de cet utilisateur.

• Apprenez à fond le système de droits MySQL. Les commandes GRANT et REVOKE sont utilisées pour contrôler les accès à MySQL. Ne donnez pas plus de droits que nécessaire. Ne donnez jamais de droits à tous les serveurs hôtes.

  Liste de vérification :

  • essayez la commande en ligne mysql -u root. Si vous pouvez vous connecter, sans donner de mot de passe, vous avez un problème. Toute personne peut se connecter au serveur comme utilisateur root avec le maximum de droits ! Passez en revue les instructions d'installation de MySQL, en insistant sur les passages où le mot de passe root est configuré. Voir Section 2.5.3, « Création des premiers droits MySQL »2.5.3. Création des premiers droits MySQL ;

  • utilisez la commande SHOW GRANTS et vérifiez qui a accès à quoi. Puis, utilisez la commande REVOKE pour retirer les droits inutiles ;

• ne stockez jamais de mot de passe en clair dans votre base de données. Si votre serveur est compromis, le pirate aura alors la liste complète des mots de passe, et pourra les utiliser. À la place, utilisez MD5(), SHA1() ou une autre fonction de signature injective ;

• ne choisissez pas vos mots de passe dans un dictionnaire. Il y a des programmes spéciaux pour les rechercher. Même des mots de passe tels que « xfish98 » est très faible. Par contre, « duag98 » est bien mieux : il contient aussi le mot « fish », mais décalé d'une touche sur un clavier QWERTY. Une autre méthode de génération consiste à prendre la première lettre de chaque mot d'une phrase : « Maupa » est issu de « Marie a un petit agneau ». C'est facile à retenir, mais difficile à deviner pour un attaquant ;

• investissez dans un pare-feu. Cela protège de 50 % de tous les types d'attaque et vulnérabilité. Placez MySQL derrière le coupe-feu, ou dans une zone démilitarisée (DMZ).

  Liste de vérification :

  • essayez de scanner vos portes depuis l'Internet, avec des outils comme nmap. MySQL utilise le port 3306 par défaut. Ce port ne doit pas être accessible à tous les serveurs. Une autre méthode simple pour vérifier si le port MySQL est ouvert ou non, est d'essayer la commande suivante depuis une machine distante, où server_host est le serveur qui héberge MySQL :

     

    Sélectionnez

    shell> telnet server_host 3306

    Si vous obtenez une connexion et des caractères binaires, le port est ouvert, et il devrait être fermé par votre routeur ou votre coupe-feu, à moins d'avoir une bonne raison pour le garder ouvert. Si telnet attend, ou que la connexion est refusée, tout va bien : le port est bloqué ;

• ne faites confiance à aucune donnée entrée par les utilisateurs de votre application. Ils peuvent déjouer vos filtres en entrant des séquences spéciales via les formulaires Web, les URL ou tout autre point d'entrée de l'application. Assurez-vous que votre application reste sûre si un utilisateur entre une chaîne telle que « ; DROP DATABASE mysql; ». C'est un exemple extrêmement simple, mais il dévoilera un trou de sécurité important. Il engendrera aussi des pertes de données si un pirate, utilisant cette technique, vous attaque.

  Une erreur courante est de ne protéger que les chaînes de caractères. N'oubliez pas de protéger aussi les valeurs numériques. Si une application génère une requête telle que SELECT * FROM table WHERE ID=234 où l'utilisateur fournit le 234, alors ce dernier peut proposer la valeur 234 OR 1=1 pour conduire à la requête SELECT * FROM table WHERE ID=234 OR 1=1. Par conséquent, le serveur va lire toutes les lignes de la table. Cela va diffuser toutes les lignes de votre application, et générer un trafic excessif. Pour vous prémunir contre ce type d'attaque, ajoutez toujours des guillemets autour des constantes numériques : SELECT * FROM table WHERE ID='234'. Si un utilisateur entre des informations supplémentaires, elles seront intégrées dans la chaîne. Dans un contexte numérique, MySQL supprimera automatiquement les caractères incompréhensibles.

  Parfois, les gens pensent que si une base de données contient des informations publiques, elle n'a pas besoin d'être défendue. C'est faux. Même si vous pouvez accéder à toutes les lignes de la table, il faut toujours se prémunir contre les dénis de service (par exemple, en utilisant la technique ci-dessus pour générer un trafic excessif). Sinon, votre serveur sera inutilisable.

  Liste de vérification :

  • essayez d'entrer des caractères ''' et '"' dans tous vos formulaires Web. Si vous obtenez une erreur MySQL, étudiez immédiatement le problème ;

  • essayez de modifier une URL dynamique en ajoutant les séquences %22 ('"'), %23 ('#') et %27 (''') ;

  • essayez de modifier les types de données des URL dynamiques de numériques en textuels, avec les caractères cités ci-dessus. Votre application doit être sécurisée contre ce type d'attaque ;

  • essayez d'entrer des caractères, des espaces et d'autres symboles spéciaux, autres que des nombres, dans un champ numérique. Votre application devrait supprimer tous ces caractères avant de les passer à MySQL, ou générer une erreur. Passer à MySQL des valeurs non vérifiées est très dangereux ;

  • vérifiez la taille des chaînes avant de les passer à MySQL ;

  • essayez de faire connecter votre application en utilisant un autre nom que celui qui est utilisé pour les tâches d'administration. Ne donnez pas à votre application des droits dont elle n'a pas besoin ;

• de nombreuses interfaces de programmation disposent de moyens pour protéger les valeurs. Correctement utilisés, ils évitent aux utilisateurs de l'application de faire passer des caractères qui auront un effet différent de celui attendu.

  • MySQL C API : Utilisez la fonction mysql_real_escape_string().

  • MySQL++ : Utilisez les options escape et quote dans le flux de requête.

  • PHP : Utilisez la fonction mysql_escape_string(), qui est basée sur la fonction C du même nom. Avant PHP 4.0.3, utilisez addslashes().

  • Perl DBI : Utilisez la méthode quote() ou utilisez les variables de requête.

  • Java JDBC : Utilisez un objet PreparedStatement ou utilisez les variables de requête.

  Les autres interfaces ont des fonctionnalités similaires.

• Ne transmettez pas de données déchiffrées sur Internet. Cette information est accessible à tous ceux qui ont le temps et la capacité d'intercepter et d'utiliser ces mots de passe. Utilisez plutôt un protocole sécurisé comme SSL ou SSH. MySQL supporte les connexions SSL depuis la version 4.0.0. SSH peut être utilisé pour créer un tunnel chiffré et compressé de communication.

• Apprenez à utiliser les programmes tcpdump et strings. Dans la plupart des cas, vous pouvez vérifier si un flux MySQL est chiffré avec la commande suivante :

   

  Sélectionnez

  shell> tcpdump -l -i eth0 -w - src or dst port 3306 | strings

  (Cette commande fonctionne sous Linux, et devrait être adaptée facilement dans les autres systèmes.) Attention : si vous ne voyez pas de données en clair, cela ne signifie pas toujours que les informations sont chiffrées. Si vous avez besoin de haute sécurité, consultez un expert.

Lorsque vous vous connectez à MySQL, vous devriez avoir besoin d'un mot de passe. Ce mot de passe n'est pas transmis en texte clair sur le réseau. La gestion des mots de passe durant l'identification des utilisateurs a été améliorée en MySQL 4.1.1 pour être très sécurisée. Si vous utilisez une vieille version de MySQL, ou si vous utilisez toujours les mots de passe de type pré-4.1.1, l'algorithme de chiffrement n'est pas très fort, quelques efforts permettront à un pirate d'obtenir votre mot de passe s'il est capable de surveiller le trafic entre le client et le serveur. (Voyez Section 5.5.9, « Hashage de mots de passe en MySQL 4.1 »5.5.9. Hashage de mots de passe en MySQL 4.1 pour une discussion des différentes méthodes de gestions des mots de passe). Si la connexion entre le client et le serveur utilise des réseaux non fiables, il est alors recommandé d'utiliser un tunnel SSH.

Toutes les autres informations sont transférées comme du texte clair, et quiconque qui surveille la connexion pourra les lire. Si vous souhaitez relever ce niveau de sécurité, il est recommandé d'utiliser le protocole compressé (avec les versions de MySQL 3.22 et plus récentes), pour compliquer considérablement le problème. Pour rendre la communication encore plus sûre, vous pouvez aussi utiliser ssh. Vous trouverez une version Open Source du client ssh sur le site http://www.openssh.org/, et une version commerciale du client ssh sur le site de http://www.ssh.com/. Avec eux, vous pouvez mettre en place une connexion TCP/IP chiffrée entre le serveur et le client MySQL.

Si vous utilisez MySQL 4.0, vous pouvez aussi utiliser le support OpenSSL interne. Voir Section 5.6.7, « Utilisation des connexions sécurisées »5.6.7. Utilisation des connexions sécurisées.

Pour rendre le système MySQL encore plus sûr, nous vous recommandons de suivre les suggestions suivantes.

• Utilisez des mots de passe pour tous les utilisateurs MySQL. N'oubliez pas que tout le monde peut se connecter avec un nom d'utilisateur quelconque, simplement avec l'option mysql -u autre_utilisateur nom_de_base, si autre_utilisateur n'a pas de mot de passe. C'est un comportement classique pour les applications client/serveur que le client spécifie son nom d'utilisateur. Il sera plus difficile à un attaquant de pénétrer dans votre serveur si tous les comptes ont un mot de passe.

  Vous pouvez modifier les mots de passe de tous les utilisateurs en modifiant le script mysql_install_db avant de l'exécuter, ou vous pouvez modifier seulement le mot de passe du root MySQL comme ceci :

   

  Sélectionnez

  shell> mysql -u root
  mysql> UPDATE mysql.user SET Password=PASSWORD('nouveau_mot_de_passe')
      -> WHERE User='root';
  mysql> FLUSH PRIVILEGES;

• N'exécutez jamais le démon MySQL avec l'utilisateur Unix root. C'est très dangereux, car toute personne ayant le droit de FILE pour créer des fichiers au nom du root (par exemple, ~root/.bashrc). Pour éviter cela, mysqld refusera de s'exécuter au nom de root à moins que soit précisé l'option --user=root.

  mysqld peut être exécuté avec un utilisateur ordinaire sans droits particuliers. Vous pouvez aussi créer un utilisateur Unix mysql pour rendre cela encore plus sûr. Si vous exécutez mysqld sous un autre utilisateur Unix, vous n'avez pas à changer le mot de passe root dans la table user, car les noms d'utilisateurs MySQL n'ont rien à voir avec les noms d'utilisateurs Unix. Pour démarrer mysqld sous un autre nom d'utilisateur Unix, ajoutez la ligne user, qui spécifie le nom de l'utilisateur, dans le fichier d'options de [mysqld] /etc/my.cnf ou dans le fichier my.cnf présent dans le dossier de données du serveur. Par exemple :

   

  Sélectionnez

  [mysqld]
  user=mysql

  Cette ligne va forcer le serveur à démarrer en tant qu'utilisateur mysql, même si vous démarrez le serveur manuellement ou avec les scripts safe_mysqld, ou mysql.server. Pour plus de détails, voyez Section A.3.2, « Comment exécuter MySQL comme un utilisateur normal »A.3.2. Comment exécuter MySQL comme un utilisateur normal.

  Exécuter mysql sous un autre compte Unix que root ne signifie pas que vous devez changer le nom de root dans la table user. Les comptes d'utilisateurs de MySQL n'ont rien à voir avec ceux du compte Unix.

• N'autorisez pas l'utilisation de liens symboliques pour les tables. Cette fonctionnalité peut être désactivée avec l'option --skip-symbolic-links. C'est particulièrement important si vous utilisez mysqld comme root, car tout utilisateur a alors le droit d'écrire des données sur le disque, n'importe où sur le système !! Voir Section 7.6.1.2, « Utiliser les liens symboliques avec les tables sous Unix »7.6.1.2. Utiliser les liens symboliques avec les tables sous Unix.

• Vérifiez que l'utilisateur Unix qui exécute mysqld est le seul utilisateur avec les droits de lecture et écriture dans le dossier de base de données.

• Ne donnez pas le droit de PROCESS à tous les utilisateurs. La liste fournie par mysqladmin processlist affiche le texte des requêtes actuellement exécutées, ce qui permet à toute personne pouvant exécuter cette commande de lire des valeurs qui seraient en clair, comme : UPDATE user SET password=PASSWORD('not_secure').

  mysqld réserve une connexion supplémentaire pour les utilisateurs qui ont le droit de PROCESS, afin que le root MySQL puisse toujours se connecter et vérifier que tout fonctionne bien, même s'il ne reste plus de connexion libre pour les autres utilisateurs.

  Le droit SUPER peut être utilisé pour fermer des connexions clients, changer les variables système et contrôler la réplication.

• Ne donnez pas le droit de FILE à tous les utilisateurs. Tout utilisateur qui possède ce droit peut écrire un fichier n'importe où sur le serveur, avec les droits hérités du démon mysqld ! Pour rendre cela plus sécuritaire, tous les fichiers générés par SELECT ... INTO OUTFILE sont lisibles par tous, mais personne ne peut les modifier.

  Le droit de FILE peut aussi être utilisé pour lire n'importe quel fichier accessible en lecture au démon qui fait tourner MySQL. Il devient donc possible, suivant les configurations, d'utiliser la commande LOAD DATA sur le fichier /etc/passwd pour tout mettre en table, et ensuite le relire avec la commande SELECT.

• Si vous ne faites pas confiance à votre DNS, vos pouvez simplement utiliser des adresses IP au lieu des noms d'hôtes. Dans ce cas, soyez très prudents lors de la création de droits qui utilisent des caractères joker.

• Si vous voulez restreindre le nombre de connexions d'un utilisateur, vous pouvez le faire en utilisant la variable max_user_connections de mysqld. La commande GRANT dispose aussi d'options de contrôle des ressources, pour limiter l'utilisation du serveur par un compte utilisateur.

Les options suivantes de mysqld affectent la sécurité.

• --local-infile[=(0|1)]

  Si vous utilisez --local-infile=0 alors vous ne pourrez pas utiliser LOAD DATA LOCAL INFILE. Voir Section 5.4.4, « Problèmes de sécurité avec LOAD DATA LOCAL »5.4.4. Problèmes de sécurité avec LOAD DATA LOCAL.

• --safe-show-database

  Avec cette option, la commande SHOW DATABASES ne retourne que les bases pour lesquelles l'utilisateur courant a des droits. Depuis la version 4.0.2, cette option est abandonnée, et ne sert plus à rien (elle est activée par défaut), car désormais, il y a le droit de SHOW DATABASES. Voir Section 13.5.1.3, « Syntaxe de GRANT et REVOKE »13.5.1.3. Syntaxe de GRANT et REVOKE.

• --safe-user-create

  Si cette option est activée, tout utilisateur ne peut créer d'autres utilisateurs avec les droits de GRANT, s'il ne dispose pas des droits d'insertion dans la table mysql.user. Si vous voulez donner un accès à un utilisateur pour qu'il puisse créer des utilisateurs avec les droits dont il dispose, vous pouvez lui donner les droits suivants :

   

  Sélectionnez

  mysql> GRANT INSERT(user) ON mysql.user TO 'user'@'hostname';

  Cela va s'assurer que l'utilisateur ne peut pas modifier une colonne directement, mais qu'il peut exécuter la commande GRANT sur d'autres utilisateurs.

• --secure-auth

  Interdit l'identification pour les comptes qui ont d'anciens mots de passe (avant la version 4.1). Cette option est valable depuis MySQL 4.1.1.

• --skip-grant-tables

  Cette option force le serveur à ne pas utiliser les tables de droits. Cette option donne donc tous les droits à tout le monde sur le serveur ! Vous pouvez forcer un serveur en fonctionnement à reprendre les tables de droits en exécutant la commande mysqladmin flush-privileges ou mysqladmin reload.)

• --skip-name-resolve

  Les noms d'hôtes ne sont pas résolus. Toutes les valeurs de la colonne Host dans les tables de droits doivent être des adresses IP, ou bien localhost.

• --skip-networking

  Ne pas accepter les connexions TCP/IP venant du réseau. Toutes les connexions au serveur mysqld doivent être faites avec les sockets Unix. Cette option n'existe pas pour les versions antérieures à la 3.23.27, avec les MIT-pthread, car les sockets Unix n'étaient pas supportés par les MIT-pthreads à cette époque.

• --skip-show-database

  Ne pas autoriser la commande SHOW DATABASES, à moins que l'utilisateur n'ait les droits de SHOW DATABASES. Depuis la version 4.0.2, vous n'avez plus besoin de cette option, car les accès sont désormais donnés spécifiquement avec le droit SHOW DATABASES.

La commande LOAD DATA peut lire des données sur le serveur hôte, ou bien charger un fichier sur le client, avec l'option LOCAL.

Il existe deux problèmes particuliers pour le support de cette commande :

• comme la lecture du fichier est réalisée depuis le serveur, il est possible théoriquement de créer un serveur MySQL modifié qui pourrait lire n'importe quel fichier de la machine cliente, qui serait accessible à l'utilisateur ;

• dans un environnement web, où les clients se connectent depuis un serveur web, un utilisateur peut se servir de la commande LOAD DATA LOCAL pour lire les fichiers qui sont sur le serveur web, et auxquels ce dernier a accès (en supposant qu'un utilisateur peut exécuter n'importe quelle commande sur le serveur).

Pour traiter ces problèmes, nous avons changé la gestion des commandes LOAD DATA LOCAL depuis MySQL version 3.23.49 et MySQL version 4.0.2 (4.0.13 pour Windows) :

• par défaut, tous les clients MySQL et les bibliothèques des distributions binaires sont compilées avec l'option --enable-local-infile, pour être compatibles avec MySQL 3.23.48 et plus ancien ;

• si vous ne configurez pas MySQL avec l'option --enable-local-infile, alors LOAD DATA LOCAL sera désactivé pour tous les clients, à moins que l'option mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0) soit activée dans le client. Voir Section 24.2.3.43, « mysql_options() »24.2.3.43. mysql_options() ;

• pour le client en ligne de commande mysql, LOAD DATA LOCAL peut être activé en spécifiant l'option --local-infile[=1], ou désactivé avec --local-infile=0 ;

• vous pouvez désactiver toutes les commandes LOAD DATA LOCAL du serveur MySQL en démarrant mysqld avec --local-infile=0. Similairement, pour mysqlimport, les options --local et -L active le chargement distant de fichiers. Dans ce cas, il faut que le serveur accepte aussi cette configuration pour que l'opération fonctionne ;

• au cas où LOAD DATA LOCAL INFILE est désactivé sur le serveur ou le client, vous obtiendrez le message d'erreur (1148) :

   

  Sélectionnez

  The used command is not allowed with this MySQL version

La fonction première du système de privilèges de MySQL est d'authentifier les utilisateurs se connectant à partir d'un hôte donné, et de leur associer des privilèges sur une base de données comme SELECT, INSERT, UPDATE et DELETE.

Les fonctionnalités additionnelles permettent d'avoir un utilisateur anonyme et de contrôler les privilèges pour les fonctions spécifiques à MySQL comme LOAD DATA INFILE et les opérations administratives.

Le système de droits de MySQL s'assure que les utilisateurs font exactement ce qu'ils sont supposés pouvoir faire dans la base. Lorsque vous vous connectez au serveur, votre identité est déterminée par l'hôte d'où vous vous connectez et le nom d'utilisateur que vous spécifiez. Le système donne les droits en fonction de votre identité et de ce que vous voulez faire.

MySQL considère votre nom d'hôte et d'utilisateur pour vous identifier, car il n'y pas que peu de raisons de supposer que le même nom d'utilisateur appartient à la même personne, quel que soit son point de connexion sur Internet. Par exemple, l'utilisateur joe qui se connecte depuis office.com n'est pas forcément la même personne que joe qui se connecte depuis elsewhere.com. MySQL gère cela en vous aidant à distinguer les différents utilisateurs et hôtes qui ont le même nom : vous pourriez donner des droits à joe lorsqu'il utilise sa connexion depuis office.com, et un autre jeu de droits lorsqu'il se connecte depuis elsewhere.com.

Le contrôle d'accès de MySQL se fait en deux étapes :

• Étape 1 : le serveur vérifie que vous êtes autorisé à vous connecter ;

• Étape 2 : en supposant que vous pouvez vous connecter, le serveur vérifie chaque requête que vous soumettez, pour vérifier si vous avez les droits suffisants pour l'exécuter. Par exemple, si vous sélectionnez des droits dans une table, ou effacez une table, le serveur s'assure que vous avez les droits de SELECT pour cette table, ou les droits de DROP, respectivement.

Si vos droits ont changé (par vous-même ou bien par un administrateur), durant votre connexion, ces changements ne prendront peut-être effet qu'à la prochaine requête. Voyez la section Section 5.5.7, « Quand les modifications de privilèges prennent-elles effet ? »5.5.7. Quand les modifications de privilèges prennent-elles effet ? pour plus détails.

Le serveur stocker les droits dans des tables de droits, situées dans la base mysql. Le serveur lit le contenu de ces tables en mémoire lorsqu'il démarre, et les relit dans différentes circonstances, détaillées dans Section 5.5.7, « Quand les modifications de privilèges prennent-elles effet ? »5.5.7. Quand les modifications de privilèges prennent-elles effet ?. Le contrôle d'accès se fait par rapport aux tables en mémoire.

Normalement, vous manipulez le contenu des tables indirectement, via les commandes GRANT et REVOKE pour configurer des comptes et des droits. Voir Section 13.5.1.3, « Syntaxe de GRANT et REVOKE »13.5.1.3. Syntaxe de GRANT et REVOKE. La discussion de cette section décrit la structure des tables de droits, et comment elle interagit avec les clients.

Le serveur utilise les tables user, db et host dans la base mysql durant les deux étapes. Les champs de cette table sont les suivants :

Lors de la seconde étape du contrôle d'accès (vérification de la requête), le serveur peut, suivant la requête, consulter aussi les tables tables_priv et columns_priv. Les champs de ces tables sont :

Chaque table de droit contient des champs d'identification et des champs de droits.

• Les champs d'identification déterminent quels utilisateurs correspondent à cette ligne dans la table. Par exemple, une ligne dans la table user avec les valeurs dans les colonnes Host et User de 'thomas.loc.gov' et 'bob' servira à identifier les connexions qui sont faites par l'utilisateur bob depuis l'hôte thomas.loc.gov. De même, une ligne dans la table db avec les valeurs des colonnes Host, User et Db de 'thomas.loc.gov', 'bob' et 'reports' sera utilisée lorsque l'utilisateur bob se connecte depuis l'hôte thomas.loc.gov pour accéder à la base reports. Les tables tables_priv et columns_priv contiennent en plus des champs indiquant les tables et combinaisons tables et colonnes auxquelles les lignes s'appliquent.

• Les champs de droits indiquent si le droit est donné, c'est-à-dire si l'opération indiquée peut être exécutée. Le serveur combine les informations dans différentes tables pour former une description complète de l'utilisateur. Les règles utilisées sont décrites dans Section 5.5.6, « Contrôle d'accès, étape 2 : Vérification de la requête »5.5.6. Contrôle d'accès, étape 2 : Vérification de la requête.

Les champs d'identification sont des chaînes, déclarées comme suit. La valeur par défaut de chacun des champs est la chaîne vide.

Avant MySQL 3.23, la colonne Db valait CHAR(32) dans certaines tables, et CHAR(60) dans d'autres.

Pour vérifier les accès, la comparaison sur les valeurs de la colonne Host sont sensibles à la casse. User, Password, Db et Table_name sont insensibles. Les valeurs de Column_name sont insensibles depuis MySQL 3.22.12.

Dans les tables user, db et host, tous les champs de droits sont déclarés avec le type ENUM('N','Y') : ils peuvent prendre tous les valeurs de 'N' (non) ou 'Y' (oui, YES), et la valeur par défaut est 'N'.

Dans les tables tables_priv et columns_priv, les champs de droits sont déclarés comme des champs de type SET :

En bref, le serveur utilise les tables de droits comme ceci :

• la table user détermine si le serveur accepte ou rejette la connexion. Pour les connexions acceptées, tous les privilèges donnés dans la table user indiquent des privilèges globaux. Ces droits s'appliquent à toutes les bases du serveur ;

• les champs d'identification de la table db déterminent quels utilisateurs peuvent accéder à quelles bases, depuis quel hôte. Les champs de droits indiquent alors les opérations permises. Les droits s'appliquent alors à toutes les bases sur le serveur ;

• la table host est utilisée comme extension de la table db lorsque vous voulez qu'une ligne de la table db s'applique à plusieurs hôtes. Par exemple, si vous voulez qu'un utilisateur soit capable d'utiliser une base depuis plusieurs hôtes dans votre réseau, laissez la colonne Host vide dans la table db, Ce mécanisme est décrit en détail dans Section 5.5.6, « Contrôle d'accès, étape 2 : Vérification de la requête »5.5.6. Contrôle d'accès, étape 2 : Vérification de la requête ;

• les tables tables_priv et columns_priv sont similaires à la table db, mais sont plus atomiques : elles s'appliquent au niveau des tables et des colonnes, plutôt qu'au niveau des bases.

Notez que les droits d'administration tels que (RELOAD, SHUTDOWN, etc.) ne sont spécifiés que dans la table user. En effet, ces opérations sont des opérations au niveau serveur, et ne sont pas liées à une base de données, ce qui fait qu'il n'y a pas de raison de les lier avec les autres tables. En fait user doit être consulté pour déterminer les autorisations d'administration.

Le droit de FILE est spécifié par la table user. Ce n'est pas un droit d'administration, mais votre capacité à lire ou écrire des fichiers sur le serveur hôte et dépendant de la base à laquelle vous accédez.

Le serveur mysqld lit le contenu des tables de droits une fois, au démarrage. Lorsqu'il y a des modifications dans les tables, elles prennent effet tel qu'indiqué dans Section 5.5.7, « Quand les modifications de privilèges prennent-elles effet ? »5.5.7. Quand les modifications de privilèges prennent-elles effet ?.

Lorsque vous modifiez le contenu des tables de droits, c'est une bonne idée que de s'assurer que vous avez bien configuré les droits qui vous intéressent. Un moyen de vérifier les droits pour un compte est d'utiliser la commande SHOW GRANTS. Par exemple, pour déterminer les droits qui sont donnés à un compte avec les valeurs Host et User de pc84.example.com et bob, utilisez cette commande :

mysql> SHOW GRANTS FOR 'bob'@'pc84.example.com';

Un outil de diagnostic pratique est le script mysqlaccess, que Yves Carlier a fourni à la distribution MySQL. Appelez mysqlaccess avec l'option the --help pour comprendre comment il fonctionne. Notez que mysqlaccess ne vérifie les accès que pour les tables user, db et host. Il n'utilise pas les tables de droits de niveau table ou colonne.

Pour plus d'aide au diagnostic pour les problèmes de droits, voyez la section Section 5.5.8, « Causes des erreurs Access denied »5.5.8. Causes des erreurs Access denied. Pour des conseils généraux sur la sécurité, voyez la section Section 5.4, « Sécurité générale du serveur »5.4. Sécurité générale du serveur.

Les droits des utilisateurs sont stockés dans les tables user, db, host, tables_priv et columns_priv de la base mysql (c'est-à-dire, la base nommée mysql). Le serveur MySQL lit ces tables au démarrage, et dans les circonstances indiquées dans la section Section 5.5.7, « Quand les modifications de privilèges prennent-elles effet ? »5.5.7. Quand les modifications de privilèges prennent-elles effet ?.

Les noms utilisés dans ce manuel font référence aux droits fournis par MySQL version 4.0.2, tels que présentés dans la table ci-dessous, avec le nom de la colonne associée au droit, dans la table de droits, et dans le contexte d'application. Plus d'informations sur la signification de chaque droit sont disponibles à Section 13.5.1.3, « Syntaxe de GRANT et REVOKE »13.5.1.3. Syntaxe de GRANT et REVOKE.

Les droits de SELECT, INSERT, UPDATE et DELETE vous permettent de faire des opérations sur les lignes qui existent, dans une table existante d'une base.

La commande SELECT requiert le droit de SELECT uniquement si des lignes sont lues dans une table. Vous pouvez exécuter une commande SELECT même sans aucun droit d'accès à une base de données dans le serveur. Par exemple, vous pourriez utiliser le client mysql comme une simple calculatrice :

mysql> SELECT 1+1;
mysql> SELECT PI()*2;

Le droit de INDEX vous donne le droit de créer et détruire des index de table.

Le droit de ALTER vous donne le droit de modifier une table avec la commande ALTER TABLE.

Les droits de CREATE et DROP vous permettent de créer de nouvelles tables et bases de données, et de les supprimer.

Notez que si vous donnez le droit de DROP pour la base de données mysql à un utilisateur, cet utilisateur pourra détruire la base qui contient les droits d'accès du serveur !

Le droit de GRANT vous permet de donner les droits que vous possédez à d'autres utilisateurs.

Le droit de FILE vous donne la possibilité de lire et écrire des fichiers sur le serveur avec les commandes LOAD DATA INFILE et SELECT ... INTO OUTFILE. Tout utilisateur qui possède ce droit peut donc lire ou écrire dans n'importe quel fichier à l'intérieur duquel le serveur MySQL peut lire ou écrire.

Les autres droits sont utilisés pour les opérations administratives qui sont exécutées par l'utilitaire mysqladmin. La table ci-dessous montre quelle commande est associée à mysqladmin avec un de ces droits :

La commande reload indique au serveur de relire les tables de droits. La commande refresh vide les tables de la mémoire, écrit les données et ferme le fichier de logs. flush-privileges est un synonyme de reload. Les autres commandes flush-* effectuent des fonctions similaires à la commande refresh mais sont plus limitées dans leur application, et sont préférables dans certains contextes. Par exemple, si vous souhaitez simplement vider les tampons dans le fichier de logs, utilisez flush-logs, qui est un meilleur choix que refresh.

La commande shutdown éteint le serveur.

La commande processlist affiche les informations sur les threads qui s'exécutent sur le serveur. La commande kill termine un des threads du serveur. Vous pouvez toujours afficher et terminer vos propres threads, mais vous aurez besoin des droits de PROCESS pour afficher les threads, et le droit de SUPER pour terminer ceux qui ont été démarrés par d'autres utilisateurs. Voir Section 13.5.4.3, « Syntaxe de KILL »13.5.4.3. Syntaxe de KILL.

C'est une bonne idée en général, de ne donner les droits de Grant qu'aux utilisateurs qui en ont besoin, et vous devriez être particulièrement vigilant pour donner certains droits.

• Le droit de GRANT permet aux utilisateurs de donner leurs droits à d'autres utilisateurs. Deux utilisateurs avec des droits différents et celui de GRANT pourront combiner leurs droits respectifs pour gagner un autre niveau d'utilisation du serveur.

• Le droit de ALTER peut être utilisé pour tromper le système en renommant les tables.

• Le droit de FILE peut servir à lire des fichiers accessibles à tous sur le serveur, et les placer dans une base de données. Le contenu pourra alors être lu et manipulé avec SELECT. Cela inclut le contenu de toutes les bases actuellement hébergées sur le serveur !

• Le droit de SHUTDOWN peut conduire au déni de service, en arrêtant le serveur.

• Le droit de PROCESS permet de voir en texte clair les commandes qui s'exécutent actuellement, et notamment les changements de mot de passe.

• Le droit de SUPER peut être utilisé pour terminer les connexions ou modifier le mode opératoire du serveur.

• Les droits sur la base de données mysql peuvent être utilisés pour changer des mots de passe ou des droits dans la table des droits. (Les mots de passe sont stockés chiffrés, ce qui évite que les intrus ne les lisent). S'ils accèdent à un mot de passe dans la table mysql.user, ils pourront l'utiliser pour se connecter au serveur avec cet utilisateur (avec des droits suffisants, le même utilisateur pourra alors remplacer un mot de passe par un autre).

Il y a des choses qui ne sont pas possibles avec le système de droits de MySQL :

• vous ne pouvez pas explicitement interdire l'accès à un utilisateur spécifique. C'est-à-dire, vous ne pouvez pas explicitement décrire un utilisateur et lui refuser la connexion ;

• vous ne pouvez pas spécifier qu'un utilisateur a les droits de créer et de supprimer des tables dans une base, mais qu'il n'a pas les droits pour créer et supprimer cette base.

Les clients MySQL requièrent généralement que vous spécifiiez les paramètres de connexion pour vous connecter au serveur MySQL :

• l'hôte que vous voulez utiliser ;

• votre nom d'utilisateur ;

• votre mot de passe.

Par exemple, le client mysql peut être démarré comme ceci :

shell> mysql [-h nom_d_hote] [-u nom_d_utilisateur] [-pvotre_mot_de_passe]

Les formes alternatives des options -h, -u et -p sont --host=host_name, --user=user_name et --password=your_pass. Notez qu'il n'y a aucun espace entre l'option -p ou --password= et le mot de passe qui le suit.

Si vous utilisez les options -p et --password mais que vous ne spécifiez pas de mot de passe, le client vous le demandera interactivement. Le mot de passe ne sera alors pas affiché. C'est la méthode la plus sécuritaire. Sinon, n'importe quel utilisateur du système pourra voir le mot de passe de la ligne de commande en exécutant une commande telle que ps auxww. Voir Section 5.6.6, « Garder vos mots de passe en lieu sûr »5.6.6. Garder vos mots de passe en lieu sûr.

mysql utilise des valeurs par défaut pour chacun des paramètres qui manquent en ligne de commande :

• le nom d'hôte par défaut est localhost ;

• le nom d'utilisateur par défaut est votre nom d'utilisateur de système Unix ;

• aucun mot de passe n'est transmis si -p manque.

Par exemple, pour un utilisateur Unix joe, les commandes suivantes sont équivalentes :

shell> mysql -h localhost -u joe
shell> mysql -h localhost
shell> mysql -u joe
shell> mysql

Les autres clients MySQL se comportent de manière similaire.

Sous Unix, vous pouvez spécifier différentes valeurs par défaut qui seront utilisées lorsque vous établirez la connexion, de manière à ce que vous n'ayez pas à entrer ces informations en ligne de commande lorsque vous invoquez un programme client. Cela peut se faire de plusieurs façons.

• Vous pouvez spécifier les informations de connexion dans la section [client] du fichier de configuration .my.cnf de votre dossier personnel. La section qui vous intéresse ressemble à ceci :

   

  Sélectionnez

  [client]
  host=nom_d_hote
  user=nom_d'utilisateur
  password=votre_mot_de_passe

  Les fichiers d'options sont présentés dans la section Section 4.3.2, « Fichier d'options my.cnf »4.3.2. Fichier d'options my.cnf.

• Vous pouvez spécifier les paramètres de connexion avec les variables d'environnement. L'hôte peut être spécifié à mysql avec la variable MYSQL_HOST. L'utilisateur MySQL peut être spécifié avec la variable USER (uniquement pour Windows). Le mot de passe peut être spécifié avec MYSQL_PWD : mais ceci est peu sécuritaire voyez Section 5.6.6, « Garder vos mots de passe en lieu sûr »5.6.6. Garder vos mots de passe en lieu sûr. Voyez aussi la prochaine section Annexe E, Variables d'environnementAnnexe E. Variables d'environnement.

Lorsque vous tentez de vous connecter au serveur MySQL, le serveur accepte ou rejette la connexion en fonction de votre identité et du mot de passe que vous fournissez. Si le mot de passe ne correspond pas à celui qui est en base, le serveur vous interdit complètement l'accès. Sinon, le serveur accepte votre connexion et passe à l'étape 2, et la gestion de commandes.

Votre identité est basée sur trois informations :

• l'hôte depuis lequel vous vous connectez ;

• votre nom d'utilisateur MySQL.

La vérification d'identité est réalisée avec les trois colonnes de la table user (Host, User et Password). Le serveur accepte la connexion uniquement si une entrée dans la table user correspond à votre hôte, et que vous fournissez le mot de passe qui correspond.

Les valeurs de la table user peuvent être paramétrées comme ceci :

• une valeur de la colonne Host peut être un nom d'hôte, une adresse IP numérique, ou encore 'localhost', qui représente l'hôte local ;

• vous pouvez utiliser les caractères joker '%' et '_' dans le champ Host. Ces caractères ont la même valeur que pour les opérations de recherches avec l'opérateur LIKE. Par exemple, une valeur Host de '%' remplace n'importe quel nom d'hôte, alors que la valeur '%.mysql.com' représente tous les hôtes du domaine mysql.com ;

• depuis MySQL version 3.23, les valeurs de Host spécifiées sous la forme d'IP numériques peuvent être complétées avec le masque de réseau qui indique combien de bits d'adresse sont utilisés. Par exemple :

   

  Sélectionnez

  mysql> GRANT ALL PRIVILEGES ON db.*
      -> TO david@'192.58.197.0/255.255.255.0';

  Cela permet à toute personne se connectant depuis une adresse IP qui satisfait la contrainte suivante :

   

  Sélectionnez

  user_ip & netmask = host_ip

  C'est-à-dire, pour la commande GRANT ci-dessus :

   

  Sélectionnez

  client_ip & 255.255.255.0 = 192.58.197.0

  Les adresses IP qui satisfont cette condition et qui peuvent se connecter au serveur MySQL sont dans l'intervalle 192.58.197.0 à 192.58.197.255 ;

• une valeur vide pour la colonne Host indique que les droits doivent être gérés avec les entrées de la table host qui correspond à l'hôte se connectant. Vous trouverez plus d'informations à ce sujet dans le chapitre Section 5.5.6, « Contrôle d'accès, étape 2 : Vérification de la requête »5.5.6. Contrôle d'accès, étape 2 : Vérification de la requête.

  Une valeur vide dans la colonne Host des autres tables de droits revient à '%'.

Comme vous pouvez utiliser des jokers dans les valeurs IP de Host (par exemple, '144.155.166.%' pour tous les hôtes d'un sous-réseau), il est possible d'exploiter cette particularité en appelant un hôte 144.155.166.ailleurs.com. Pour contrer ce type d'attaque, MySQL bloque les noms de domaines qui commencent par des chiffres et des points. Par conséquent, si vous avez un hôte nommé 1.2.foo.com, il ne sera jamais accepté par la colonne Host des tables de droits. Un caractère joker d'adresse IP peut remplacer uniquement des nombres d'IP, et pas un nom d'hôte.

Dans la colonne User, les caractères joker ne sont pas autorisés, mais vous pouvez laisser cette valeur vide, qui acceptera tous les noms. Si la table user contient une connexion avec un nom d'utilisateur vide, l'utilisateur est considéré comme anonyme. Cela signifie que le nom d'utilisateur vide est utilisé pour les prochaines vérifications d'accès pour la durée de la connexion.

Le champ Password peut être vide. Cela ne signifie pas que n'importe quel mot de passe est valable, mais que l'utilisateur peut se connecter sans fournir de mot de passe.

Les valeurs non vides du champ Password représentent des valeurs du mot de passe chiffrées. MySQL ne stocke pas les mots de passe en clair, à la vue de tous. Au contraire, le mot de passe fourni par l'utilisateur qui tente de se connecter est chiffré (avec la fonction PASSWORD()). Le mot de passe ainsi chiffré est alors utilisé entre le client et le serveur pour vérifier s'il est valable. Cela évite que des mots de passe en clair circulent entre le client et le serveur, sur la connexion. Notez que du point de vue de MySQL, le mot de passe chiffré est le vrai mot de passe, ce qui fait que vous ne devez en aucun cas le donner à un tiers. En particulier, ne donnez pas accès en lecture aux utilisateurs normaux aux tables d'administration dans la base mysql ! À partir de sa version 4.1, MySQL utilise un mécanisme différent pour les logins, mots de passe qui est sécurisé même si les paquets TCP/IP sont sniffés et/ou que la base de données mysql est capturée.

Depuis la version 4.1, MySQL emploie une identification forte qui protège mieux les mots de passe durant le processus de connexion. Cette méthode est sécuritaire, même si les paquets TCP/IP sont surveillés pour que la base de données mysql soit capturée. Le chiffrement est présenté dans la section Section 5.5.9, « Hashage de mots de passe en MySQL 4.1 »5.5.9. Hashage de mots de passe en MySQL 4.1.

Les exemples ci-dessous illustrent comment différentes variantes de Host et User dans la table user s'appliquent aux connexions entrantes :

Comme vous pouvez utiliser des caractères joker dans les adresses IP de la colonne Host (par exemple, '144.155.166.%' pour identifier tout un sous-réseau), il est possible d'exploiter cette fonctionnalité en nommant un hôte 144.155.166.kekpart.com. Pour contrer de telles tentatives, MySQL interdit les caractères joker avec les noms d'hôtes qui commencent par des chiffres ou des points. Par exemple, si vous avez un nom d'hôte tel que 1.2.foo.com, il ne sera jamais trouvé dans la colonne Host des tables de droits. Seule une adresse IP numérique peut être comparée avec un masque à caractère joker.

Une connexion entrante peut être identifiée par plusieurs entrées dans la table user. MySQL résout ce problème comme ceci :

• lorsque le serveur lit la table user en mémoire, il trie les lignes ;

• lorsqu'un client tente de se connecter, le serveur lit les lignes dans l'ordre ;

• le serveur utilise la première ligne qui correspond au nom du client et à son nom d'utilisateur.

Supposons que votre table user ressemble à ceci :

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

Lorsque le serveur lit cette table, il ordonne les lignes depuis les valeurs les plus spécialisées de la colonne Host jusqu'aux plus générales ('%' dans la colonne Host signifie « tous les hôtes » et elle est la moins spécifique). Les entrées identiques dans la colonne Host sont ordonnées en fonction de la spécificité des valeurs de la colonne User (une entrée vide dans la colonne User signifie « n'importe quel utilisateur » et est spécifique). Le résultat de ce tri donne quelque chose comme ceci :

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

Lorsqu'une connexion est en cours de mise en place, le serveur regarde dans cette liste, et utilisera la première entrée trouvée. Pour une connexion depuis l'hôte localhost avec le nom d'utilisateur jeffrey, les entrées 'localhost' dans la colonne Host sont trouvées en premier. Parmi celles-là, la ligne avec un utilisateur vide satisfait les deux contraintes sur le nom et l'hôte. '%'/'jeffrey' pourrait avoir fonctionné, mais comme ce n'est pas le premier rencontré, il n'est pas utilisé.

Voici un autre exemple. Supposons que la table user ressemble à ceci :

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

La table triée ressemble à ceci :

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

Une connexion depuis l'hôte thomas.loc.gov avec jeffrey satisfait les conditions de la première ligne, tandis qu'une connexion depuis whitehouse.gov avec jeffrey satisfait la seconde ligne.

Une erreur commune est de penser que pour un utilisateur donné, toutes les entrées qui utilisent explicitement ce nom seront utilisées en premier lorsque la connexion est en cours d'établissement. Ceci est tout simplement faux. L'exemple précédent illustre cette situation, car la connexion depuis l'hôte thomas.loc.gov avec jeffrey est la première ligne qui est trouvée, alors que la ligne contenant 'jeffrey' dans la colonne User est ignorée, car il n'y a pas de nom d'utilisateur.

Si vous arrivez à vous connecter au serveur, mais que les droits ne sont pas ce que vous attendez, vous vous êtes probablement identifié avec un autre compte. Pour savoir quel compte le serveur utilise lors de votre identification, utilisez la fonction CURRENT_USER(). Elle retourne la valeur au format user_name@host_name qui indique les valeurs des colonnes User et Host de la table user qui vous est affectée. Supposons que jeffrey se connecte et utilise la requête suivante :

mysql> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| @localhost     |
+----------------+

Le résultat affiché ci-dessus indique que la ligne de la table user est l'utilisateur User vide. En d'autres termes, le serveur traite jeffrey comme un utilisateur anonyme.

La fonction CURRENT_USER() est disponible depuis MySQL 4.0.6. Voir Section 12.8.3, « Fonctions d'informations »12.8.3. Fonctions d'informations. Une autre piste à explorer : imprimez le contenu de la table user et triez-la manuellement pour voir quelle est la première ligne qui est utilisée.

Une fois que vous avez établi la connexion, le serveur passe à l'étape 2. Pour chaque requête qui est fournie avec la connexion, le serveur vérifie si vous avez les droits suffisants pour exécuter une commande, en fonction du type de commande. C'est à ce moment que les colonnes de droits des tables d'administration entrent en scène. Ces droits peuvent provenir de la table user, db, host, tables_priv ou columns_priv. Les tables d'administration sont manipulées avec les commandes GRANT et REVOKE. (Vous pouvez aussi vous reporter à la section Section 5.5.2, « Comment fonctionne le système de droits »5.5.2. Comment fonctionne le système de droits qui liste les champs présents dans chaque table d'administration).

La table d'administration user donne les droits aux utilisateurs au niveau global, c'est-à-dire que ces droits s'appliquent quelle que soit la base de données courante. Par exemple, si la table user vous donne le droit d'effacement, DELETE, vous pouvez effacer des données dans n'importe quelle base de ce serveur. En d'autres termes, les droits stockés dans la table user sont des droits de super-utilisateur. Il est recommandé de ne donner des droits via la table user uniquement aux super-utilisateurs, ou aux administrateurs de bases. Pour les autres utilisateurs, il vaut mieux laisser les droits dans la table user à 'N' et donner des droits au niveau des bases uniquement, avec les tables db et host.

Les tables db et host donnent des droits au niveau des bases. Les droits peuvent être spécifiés dans ces tables comme ceci :

• les caractères '%' et '_' peuvent être utilisés dans la colonne Host et Db des deux tables. Si vous souhaitez utiliser le caractère '_' comme nom de base, utiliser la séquence '\_' dans la commande GRANT ;

• la valeur '%' dans la colonne Host de la table db signifie « tous les hôtes ». Une valeur vide dans la colonne Host de la table db signifie « consulte la table host pour plus de détails » ;

• la valeur '%' ou vide dans la colonne Host de la table host signifie « tous les hôtes » ;

• la valeur '%' ou vide dans la colonne Db des deux tables signifie « toutes les bases de données » ;

• un utilisateur vide dans la colonne User de l'une des deux tables identifie l'utilisateur anonyme.

Les tables db et host sont lues et triées par le serveur au démarrage (en même temps que la table user. La table db est triée suivant les valeurs des colonnes Host, Db et User, et la table host est triée en fonction des valeurs des colonnes Host et Db. Comme pour la table user, le tri place les entrées les plus spécifiques au début, et les plus générales à la fin. Lorsque le serveur recherche une ligne, il utilise la première qu'il trouve.

Les tables tables_priv et columns_priv spécifient les droits au niveau des tables et des colonnes. Les valeurs des droits dans ces tables peuvent être spécifiées avec les caractères spéciaux suivants :

• les caractères '%' et '_' peuvent être utilisés dans la colonne Host des deux tables ;

• la valeur '%' dans la colonne Host des deux tables signifie « tous les hôtes » ;

• les colonnes Db, Table_name et Column_name ne peuvent pas contenir de valeur vide ou de caractères joker, dans les deux tables.

Les tables tables_priv et columns_priv sont triées en fonction des colonnes Host, Db et User. Ce tri est similaire à celui du tri de la table db, même si le tri est bien plus simple, car seul le champ Host peut contenir des caractères joker.

Le processus de vérification est décrit ci-dessous. Si vous êtes familier avec le code source de contrôle d'accès, vous noterez que la description diffère légèrement de l'algorithme utilisé. La description est équivalente à ce que fait en réalité le code. La différence permet une meilleure approche pédagogique.

Pour les requêtes d'administration comme SHUTDOWN, RELOAD, etc., le serveur vérifie uniquement l'entrée dans la table user, car c'est la seule table qui spécifie des droits d'administration. Le droit est donné si la ligne utilisée dans la connexion courante dans la table user donne le droit, et sinon, ce droit est interdit. Par exemple, si vous souhaitez exécuter la commande mysqladmin shutdown, mais que votre ligne dans la table user ne vous en donne pas le droit (SHUTDOWN), vous n'aurez pas le droit sans même vérifier les tables db ou host : ces tables ne contiennent pas de colonne Shutdown_priv, ce qui évite qu'on en ait besoin.

Pour les requêtes exploitant une base de données, comme INSERT, UPDATE, etc., le serveur vérifie d'abord les droits globaux de l'utilisateur (droits de super-utilisateur), en regardant dans la table user. Si la ligne utilisée dans cette table donne droit à cette opération, le droit est donné. Si les droits globaux dans user sont insuffisants, le serveur déterminera les droits spécifiques à la base avec les tables db et host.

1. Le serveur recherche dans la table db des informations en se basant sur les colonnes Host, Db et User. Les champs Host et User sont comparés avec les valeurs de l'hôte et de l'utilisateur qui sont connectés. Le champ Db est comparé avec le nom de la base de données que l'utilisateur souhaite utiliser. S'il n'existe pas de ligne qui corresponde à Host et User, l'accès est interdit.

2. S'il existe une ligne dans la table db et que la valeur de la colonne Host n'est pas vide, cette ligne définit les droits de l'utilisateur.

3. Si dans la ligne de la table db, la colonne Host est vide, cela signifie que la table host spécifie quels hôtes doivent être autorisés dans la base. Dans ce cas, une autre recherche est faite dans la table host pour trouver une ligne avec les colonnes Host et Db. Si aucune ligne de la table host n'est trouvée, l'accès est interdit. S'il y a une ligne, les droits de l'utilisateur sont calculés comme l'intersection (NON PAS l'union !) des droits dans les tables db et host, c'est-à-dire que les droits doivent être marqués 'Y' dans les deux tables (de cette façon, vous pouvez donner des droits généraux dans la table db puis les restreindre sélectivement en fonction des hôtes, en utilisant la table host.

Après avoir déterminé les droits spécifiques à l'utilisateur pour une base grâce aux tables db et host, le serveur les ajoute aux droits globaux, donnés par la table user. Si le résultat autorise la commande demandée, l'accès est donné. Sinon, le serveur vérifie les droits au niveau de la table et de la colonne dans les tables tables_priv et columns_priv, et les ajoute aux droits déjà acquis. Les droits sont alors donnés ou révoqués en fonction de ces résultats.

Exprimée en termes booléens, la description précédente du calcul des droits peut être résumée comme ceci :

droits globaux
OR (droits de base AND droits d'hôte)
OR droits de table
OR droits de colonne

Il n'est peut-être pas évident pourquoi, si les droits globaux issus de la table user sont initialement insuffisants pour l'opération demandée, le serveur ajoute ces droits à ceux de base, table ou colonne ? La raison est que la requête peut demander l'application de plusieurs droits. Par exemple, si vous exécutez une commande INSERT ... SELECT, vous aurez besoin des droits de INSERT et de SELECT. Vos droits peuvent être tels que la table user donne un droit, mais que la table db en donne un autre. Dans ce cas, vous aurez les droits nécessaires pour faire une opération, mais le serveur ne peut le déduire d'une seule table : les droits de plusieurs tables doivent être combinés pour arriver à la bonne conclusion.

La table host sert à gérer une liste d'hôtes reconnus et sécuritaires.

Chez TcX, la table host contient une liste de toutes les machines du réseau local. Ces machines reçoivent tous les droits.

Vous pouvez aussi utiliser la table host pour spécifier les hôtes qui ne sont pas sécuritaires. Supposons que la machine public.votre.domaine t est placée dans une zone publique que vous considérez comme peu sûre. Vous pouvez autoriser l'accès de toutes les machines, hormis celle-ci, grâce à la table host configurée comme ceci :

+--------------------+----+-
| Host               | Db | ...
+--------------------+----+-
| public.your.domain | %  | ... (tous les droits à 'N')
| %.your.domain      | %  | ... (tous les droits à 'Y')
+--------------------+----+-

Naturellement, vous devriez toujours tester vos requêtes dans la table de droits, en utilisant l'utilitaire mysqlaccess pour vous assurer que vous disposez des droits nécessaires pour réaliser cette opération.

Lorsque mysqld est lancé, toutes les tables de droits sont lues, et sont utilisées.

Les modifications aux tables de droits que vous faites avec GRANT, REVOKE et SET PASSWORD sont immédiatement prises en compte par le serveur.

Si vous modifiez les tables de droits manuellement (avec INSERT, UPDATE, etc.), vous devez exécuter la commande FLUSH PRIVILEGES ou la commande mysqladmin flush-privileges, ou encore mysqladmin reload pour dire au serveur de relire les tables de droits. Sinon, vos modifications n'auront aucun effet jusqu'au redémarrage du serveur. Si vous modifiez les tables de droits manuellement, mais que vous oubliez de recharger les droits, vous vous demanderez sûrement pourquoi vos modifications n'ont pas d'effet.

Lorsque le serveur remarque que les tables de droits ont été modifiées, les connexions existantes avec les clients sont modifiées comme ceci :

• les droits de tables et colonnes prennent effet à la prochaine requête du client ;

• les droits de bases prennent effet à la prochaine commande USE nom_de_base ;

• les droits globaux et les modifications de droits prennent effet lors de la prochaine connexion.

Si vous rencontrez des erreurs Access denied quand vous essayez de vous connecter au serveur MySQL, la liste suivante indique quelques actions à entreprendre pour corriger le problème.

• Assurez-vous que le serveur fonctionne. S'il ne fonctionne pas, vous ne pourrez pas vous y connecter. Par exemple, si vous tentez de vous connecter au serveur, et que vous recevez un message comme celui-ci, c'est peut-être que le serveur ne fonctionne pas :

   

  Sélectionnez

  shell> mysql
  ERROR 2003: Can't connect to MySQL server on 'host_name' (111)
  shell> mysql
  ERROR 2002: Can't connect to local MySQL server through socket
  '/tmp/mysql.sock' (111)

  Il se peut aussi que le serveur fonctionne, mais que vous essayez de vous connecter en utilisant un port TCP/IP, un pipe nommé ou un fichier de socket Unix qui n'est pas celui que le serveur utilise. Pour corriger cela, lorsque vous utilisez un client, spécifiez l'option --port pour indiquer le bon port, et l'option --socket pour indiquer le bon fichier de socket Unix ou le pipe nommé Windows. Pour connaître le port utilisé, et le chemin jusqu'à la socket, vous pouvez utiliser cette commande :

   

  Sélectionnez

  shell> netstat -l | grep mysql

• Les tables de droits doivent être correctement configurées pour que le serveur les utilise lors de l'identification. Les installations Windows qui utilisent une distribution binaire ou les installations binaires Unix RPM initialisent automatiquement la base mysql contenant les tables de droits. Pour les autres types d'installation, vous devez initialiser les tables de droits manuellement, avec le script mysql_install_db. Pour plus de détails, voyez Section 2.5.2, « Procédures de postinstallation sous Unix »2.5.2. Procédures de postinstallation sous Unix.

  Un moyen de déterminer si vous avez besoin d'initialiser les tables de droits est de regarder dans le dossier mysql dans le dossier de données. Le dossier de données s'appelle data ou var et est situé dans le dossier d'installation de MySQL. Assurez-vous que vous avez un fichier appelé user.MYD dans le dossier mysql. Si vous ne le trouvez pas, exécutez le script mysql_install_db. Après exécution de ce script, et redémarrage du serveur, testez les premiers droits avec la commande :

   

  Sélectionnez

  shell> mysql -u root test

  Le serveur doit vous laisser vous connecter sans erreur.

• Après une installation toute fraîche, vous devez vous connecter au serveur et créer les utilisateurs en réglant leurs permissions d'accès :

   

  Sélectionnez

  shell> mysql -u root mysql

  Le serveur devrait vous laisser vous connecter, car l'utilisateur root de MySQL n'a pas de mot de passe initial. Ceci est aussi une faille de sécurité, et donc, vous devez choisir un mot de passe pour l'utilisateur root en même tant que les autres utilisateurs MySQL. Pour des instructions sur la configuration des mots de passe initiaux, voyez la section Section 2.5.3, « Création des premiers droits MySQL »2.5.3. Création des premiers droits MySQL.

• Si vous avez mis à jour une version de MySQL avec une nouvelle version, avez-vous utilisé le script mysql_fix_privilege_tables ? Si ce n'est pas le cas, faites-le. La structure des tables de droits change occasionnellement, lorsque de nouvelles fonctionnalités sont ajoutées : après une mise à jour, assurez-vous que vos tables ont la bonne structure. Pour des instructions, voyez Section 2.6.7, « Mise à jour des tables de droits »2.6.7. Mise à jour des tables de droits.

• Si un programme client reçoit l'erreur suivante lorsqu'il essaie de se connecter, cela signifie que le serveur attend un mot de passe dans un nouveau format, alors que le client fournit un ancien format :

   

  Sélectionnez

  shell> mysql
  Client does not support authentication protocol requested
  by server; consider upgrading MySQL client

  Pour des informations sur comment traiter ce type de situations, voyez Section 5.5.9, « Hashage de mots de passe en MySQL 4.1 »5.5.9. Hashage de mots de passe en MySQL 4.1 et Section A.2.3, « Erreur Client does not support authentication protocol »A.2.3. Erreur Client does not support authentication protocol.

• Si vous essayez de vous connecter en tant que root et que vous recevez l'erreur suivante, cela signifie que vous n'avez pas d'entrée dans la table user avec une valeur 'root' dans la colonne User et que mysqld ne peut pas résoudre le nom d'hôte du client :

   

  Sélectionnez

  Access denied for user: ''@'unknown' to database mysql

  Dans ce cas, vous devez relancer le serveur avec l'option --skip-grant-tables, et éditer votre fichier /etc/hosts ou \windows\hosts pour ajouter une ligne vous votre hôte.

• N'oubliez pas que les clients utilisent les paramètres de connexions placés dans les fichiers d'options ou les variables d'environnement. Si un client semble envoyer des paramètres de connexions invalides, lorsque vous n'en spécifiez aucun, vérifiez votre environnement, et les options appropriées. Par exemple, si vous recevez l'erreur Access denied avec un client utilisé sans option, assurez-vous que vous n'avez pas spécifié un ancien mot de passe dans vos anciens fichiers d'options.

  Vous pouvez supprimer l'utilisation des fichiers d'options d'un client en utilisant l'option --no-defaults. Par exemple :

   

  Sélectionnez

  shell> mysqladmin --no-defaults -u root version

  Le fichier d'options que les clients utilisent est listé dans la section Section 4.3.2, « Fichier d'options my.cnf »4.3.2. Fichier d'options my.cnf. Les variables d'environnement sont listées dans Annexe E, Variables d'environnementAnnexe E. Variables d'environnement.

• Si vous obtenez une erreur qui ressemble à celle-ci :

   

  Sélectionnez

  shell> mysqladmin -u root -pxxxx ver
  Access denied for user: 'root'@'localhost' (Using password: YES)

  Cela signifie que vous utilisez un mot de passe erroné.

  Si l'erreur précédente survient lorsque vous n'avez pas spécifié de mot de passe, cela signifie que vous n'avez pas spécifié de mot de passe dans un fichier d'options. Essayez l'option --no-defaults telle que décrite ci-dessus.

  Pour des informations sur les changements de mot de passe, voyez Section 5.6.5, « Configurer les mots de passe »5.6.5. Configurer les mots de passe.

  Si vous avez oublié le mot de passe root, vous pouvez redémarrer mysqld avec --skip-grant-tables pour changer le mot de passe. Voir Section A.4.1, « Comment réinitialiser un mot de passe Root oublié »A.4.1. Comment réinitialiser un mot de passe Root oublié.

• Si vous n'arrivez pas à faire fonctionner votre mot de passe, souvenez-vous que vous devez utiliser la fonction PASSWORD() si vous le changez avec les commandes INSERT, UPDATE, ou SET PASSWORD. L'utilisation de la fonction PASSWORD() n'est pas nécessaire si vous spécifiez le mot de passe en utilisant la commande GRANT ... INDENTIFIED BY ou la commande mysqladmin password. Voir Section 5.6.5, « Configurer les mots de passe »5.6.5. Configurer les mots de passe.

   

  Sélectionnez

  mysql> SET PASSWORD FOR 'abe'@'host_name' = 'eagle';

  À la place, utilisez cette commande :

   

  Sélectionnez

  mysql> SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');

  La fonction PASSWORD() n'est pas nécessaire si vous spécifiez un mot de passe avec la commande GRANT ou la commande en ligne mysqladmin password, qui utilise automatiquement PASSWORD() pour chiffrer le mot de passe.

• localhost est un synonyme de votre nom d'hôte local, et est aussi l'hôte par défaut auquel le client essaye de se connecter si vous n'en spécifiez pas un explicitement. Toutefois, les connexions à localhost ne fonctionnent pas si vous utilisez une version antérieure à la 3.23.27 qui utilise les MIT-pthreads.

  Pour contourner ce problème sur de tels systèmes, vous devez utiliser l'option --host pour nommer l'hôte du serveur explicitement. Cela créera une connexion TCP/IP vers le serveur mysqld. Dans ce cas, vous devez avoir votre vrai nom d'hôte dans les entrées de la table user du serveur hôte. (Cela est vrai même si vous utilisez un programme client sur la même machine que le serveur.)

• Si vous obtenez une erreur Access denied lorsque vous essayez de vous connecter à la base de données avec mysql -u nom_utilisateur nom_base, vous pouvez avoir un problème dans la table user. Vérifiez-le en vous exécutant mysql -u root mysql et entrant la commande SQL suivante :

   

  Sélectionnez

  mysql> SELECT * FROM user;

  Le résultat devrait comprendre une entrée avec les colonnes Host et User correspondante au nom d'hôte de votre ordinateur et votre nom d'utilisateur MySQL.

• Le message d'erreur Access denied vous dira en tant que qui vous essayez de vous identifier, l'hôte à partir duquel vous voulez le faire, et si vous utilisez ou pas un mot de passe. Normalement, vous devez avoir une entrée dans la table user qui correspond au nom d'hôte et nom d'utilisateur donnés dans le message d'erreur. Par exemple, si vous obtenez une erreur qui contient Using password: NO, cela signifie que vous avez essayé de vous connecter sans mot de passe.

• Si vous obtenez l'erreur suivante en essayant de vous connecter à partir d'un hôte différent de celui sur lequel est placé le serveur, c'est qu'il n'y a pas d'enregistrement dans la table user qui correspond à cet hôte :

   

  Sélectionnez

  Host ... is not allowed to connect to this MySQL server

  Vous pouvez corriger ce problème en configurant un compte avec la combinaison hôte/nom d'utilisateur que vous utilisez lors de la connexion.

  Si vous ne connaissez ni l'IP ni le nom d'hôte à partir duquel vous essayez de vous connecter, vous devez créer une entrée avec '%' dans la colonne Host dans la table user et redémarrer mysqld avec l'option --log sur la machine serveur. Après avoir essayé à nouveau de vous connecter à partir de la machine cliente, les informations contenues dans le log de MySQL vous apprendront comment vous vous êtes vraiment connecté. (Remplacez alors l'entrée de la table user contenant '%' avec le nom d'hôte qui apparaît dans le log. Sinon, vous aurez un système non sécurisé.)

  Une autre raison pour cette erreur sous Linux est que vous utilisez une version binaire de MySQL qui est compilée avec une version de glibc différente de celle que vous utilisez. Dans ce cas, vous devez soit mettre à jour votre système d'exploitation et sa bibliothèque glibc, soit télécharger les sources de MySQL et les compiler vous-même. Un RPM de sources est normalement facile à compiler et installer, cela ne devrait donc pas vous poser de gros problèmes.

• Si vous obtenez une erreur où le nom d'hôte est absent ou que celui-ci est une adresse IP alors que vous avez bien entré le nom d'hôte :

   

  Sélectionnez

  shell> mysqladmin -u root -pxxxx -h some-hostname ver
  Access denied for user: 'root@' (Using password: YES)

  Cela signifie que MySQL a rencontré des erreurs lors de la résolution de l'IP du nom d'hôte. Dans ce cas, vous pouvez exécuter mysqladmin flush-hosts pour vider le cache interne des DNS. Voir Section 7.5.6, « Comment MySQL utilise le DNS »7.5.6. Comment MySQL utilise le DNS.

  Les autres solutions sont :

  • essayez de trouver le problème avec votre serveur DNS et corrigez-le ;

  • spécifiez les IP à la place des noms d'hôtes dans les tables de droits de MySQL ;

  • ajoutez une ligne pour le nom de votre machine dans /etc/hosts ;

  • démarrez mysqld avec --skip-name-resolve ;

  • démarrez mysqld avec --skip-host-cache ;

  • sous Unix, si vous utilisez le serveur et le client sur la même machine, connectez-vous à localhost. Les connexions Unix à localhost utilisent un socket Unix plutôt que TCP/IP ;

  • sous Windows, si vous exécutez le serveur et le client sur la même machine, et que le serveur supporte les pipes nommés, connectez-vous à l'hôte . (point). Les connexions à . utilisent les pipes nommés plutôt que TCP/IP ;

• si mysql -u root test fonctionne, mais que mysql -h votre_hote -u root test provoque une erreur Access denied, il se peut que vous ayez entré de mauvaises informations pour votre nom d'hôte dans la table user. Un problème commun ici est que la valeur Host dans la table user spécifie un nom d'hôte non qualifié, mais que vos routines système de résolution de noms retournent un nom de domaine pleinement qualifié (ou vice-versa). Par exemple, si vous avez une entrée avec l'hôte 'tcx' dans la table user, mais que vos DNS disent à MySQL que votre nom d'hôte est 'tcx.subnet.se', l'entrée ne fonctionnera pas. Essayez d'ajouter une entrée dans la table user qui contient votre adresse IP en tant que valeur de la colonne Host. (Une autre solution est d'ajouter une entrée dans la table user avec une valeur de Host qui contient un caractère spécial, par exemple, 'tcx.%'. Toutefois, l'utilisation des noms d'hôtes se terminant par '%' est non sécurisée et n'est pas recommandée !) ;

• si mysql -u utilisateur test fonctionne, mais que mysql -u utilisateur autre_base ne fonctionne pas, vous n'avez pas d'entrée pour autre_base listée dans la table db ;

• si mysql -u utilisateur nom_base fonctionne à partir du serveur, mais que mysql -h nom_hote -u utilisateur nom_base ne fonctionne pas à partir d'une autre machine, cette machine n'est pas listée dans la table user ou db ;

• si vous n'arrivez pas à trouver pourquoi vous obtenez l'erreur Access denied, effacez toutes les entrées de la table user dont la valeur du champ Host contiennent des caractères spéciaux (entrées contenant '%' ou '_'). Une erreur commune est d'insérer une nouvelle entrée avec Host='%' et User='un utilisateur', en pensant que cela vous permettra de spécifier localhost pour vous connecter à partir de la même machine. La raison pour laquelle cela ne fonctionnera pas est que les droits par défaut incluent une entrée avec Host='localhost' et User=''. Puisque cette entrée possède une valeur de Host égale à 'localhost', qui est plus spécifique que '%', elle est utilisée de préférence à la nouvelle entrée lors de la connexion à partir de localhost ! La procédure correcte est d'insérer une seconde entrée avec Host='localhost' et User='un_utilisateur', ou de supprimer l'entrée avec Host='localhost' et User='' ;

• si vous avez l'erreur suivante, vous avez peut-être un problème avec la table db ou host :

   

  Sélectionnez

  Access to database denied

  Si l'entrée sélectionnée dans la table db possède un champ Host vide, assurez-vous qu'il y a au moins une entrée correspondante dans la table host spécifiant les hôtes auxquels l'entrée dans la table db s'applique ;

• si vous obtenez l'erreur lors de l'utilisation des commandes SQL SELECT ... INTO OUTFILE ou LOAD DATA INFILE, votre entrée dans la table user ne possède probablement pas les droits de FILE ;

• si vous apportez des modifications aux tables de droits directement (en utilisant une requête INSERT ou UPDATE) et que vos changements semblent ignorés, souvenez-vous que vous devez exécuter une requête FLUSH PRIVILEGES ou la commande mysqladmin flush-privileges pour demander au serveur de lire à nouveau les tables de droits. Sinon, vos changements ne seront pris en compte qu'au prochain démarrage du serveur. Souvenez-vous qu'après avoir choisi le mot de passe root avec une commande UPDATE, vous n'aurez pas à le spécifier avant de recharger les privilèges, car le serveur ne sait pas que vous l'avez modifié !

• si vos droits changent en milieu de session, c'est peut-être qu'un administrateur MySQL a changé les droits. En rechargeant les tables de droits, il a modifié aussi les connexions existantes, comme indiqué dans Section 5.5.7, « Quand les modifications de privilèges prennent-elles effet ? »5.5.7. Quand les modifications de privilèges prennent-elles effet ? ;

• si vous avez des problèmes d'accès avec un programme Perl, PHP, Python, ou ODBC, essayez de vous connecter au serveur avec mysql -u utilisateur nom_base ou mysql -u utilisateur -pvotre_passe nom_base. Si vous pouvez vous connecter en utilisant le client mysql, c'est que le problème vient de votre programme et non des droits MySQL. (Notez qu'il n'y a pas d'espace entre -p et le mot de passe, vous pouvez aussi utiliser la syntaxe --password=votre_passe pour spécifier le mot de passe. Si vous utilisez l'option -p toute seule, MySQL vous demandera le mot de passe.) ;

• pour les tests, démarrez le démon mysqld avec l'option --skip-grant-tables. Vous pourrez alors changer les tables de droits MySQL puis utiliser le script mysqlaccess pour vérifier si vos changements ont l'effet désiré. Lorsque vous êtes satisfait de vos modifications, exécutez mysqladmin flush-privileges pour dire au serveur mysqld de commencer à utiliser les nouvelles tables de droits. Recharger les tables de droits écrase l'option --skip-grant-tables. Cela vous permet de dire au serveur de commencer à prendre en considération les droits sans avoir à le couper et le redémarrer ;

• si rien ne fonctionne, démarrez le démon mysqld avec l'option de débogage (par exemple, --debug=d,general,query). Cela affichera l'hôte et les informations de l'utilisateur pour chaque tentative de connexion. Les informations à propos de chaque commande exécutée seront aussi affichées. Voir Section D.1.2, « Créer un fichier de traçage »D.1.2. Créer un fichier de traçage ;

• si vous avez d'autres problèmes avec les tables de droits de MySQL et que vous sentez que vous devez envoyer le problème à la liste de diffusion, fournissez toujours le contenu de vos tables de droits. Vous pouvez obtenir les données avec la commande mysqldump mysql. Comme toujours, postez votre problème à l'aide du script mysqlbug. Voir Section 1.4.1.3, « Comment rapporter un bogue ou un problème »1.4.1.3. Comment rapporter un bogue ou un problème. Dans certains cas, vous aurez besoin de redémarrer mysqld avec --skip-grant-tables pour pouvoir exécuter mysqldump.

Les comptes utilisateurs de MySQL sont stockés dans la table user de la base mysql. Chaque compte MySQL a un mot de passe, même si ce qui est stocké dans la colonne Password de la table user n'est pas la version texte du mot de passe, mais un hash calculé à partir du mot de passe. La transformation est faite avec la fonction PASSWORD().

MySQL utilise les mots de passe en deux phases, lors de la communication client/serveur :

• premièrement, lorsqu'un client tente de se connecter au serveur, il y a une identification initiale au cours de laquelle le client doit présenter un mot de passe dont la valeur hashée est la même que celle qui est présente dans la table d'utilisateur, pour le compte que le client veut utiliser ;

• ensuite, après la connexion du client, il peut modifier ou changer le mot de passe pour les utilisateurs du serveur (s'il a les droits nécessaires pour cela). Le client peut faire cela avec la fonction PASSWORD(), pour générer un autre mot de passe, ou en utilisant les commandes GRANT ou SET PASSWORD.

En d'autres termes, le serveur utilise les valeurs hashées durant la phase d'identification, lorsque le client tente de se connecter. Le serveur génère des valeurs hash, si un client appelle la fonction PASSWORD() ou utilise les commandes GRANT ou SET PASSWORD.

Le mécanisme de modifications des mots de passe a été modifié en MySQL 4.1, pour apporter une sécurité accrue et réduire le risque de vol de mots de passe. Cependant, ce nouveau mécanisme ne peut être compris que de la version 4.1, et des clients MySQL 4.1, ce qui pose des problèmes de compatibilité. Un client 4.1 peut se connecter sur un serveur pré-4.1, car le client comprend les deux méthodes de hashage, ancienne et nouvelle. Cependant, un client pré-4.1 qui tente se de connecter à un serveur 4.1 aura des problèmes. Par exemple, si un client mysql 4.0 essaie de se connecter au serveur 4.1, il va recevoir l'erreur suivante :

shell> mysql -h localhost -u root
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

La discussion suivante décrit les différences entre les mécanismes de mots de passe, et ce que vous devez faire pour mettre à jour votre serveur en version 4.1, tout en conservant la compatibilité avec les clients pre-4.1.

Note : cette discussion compare les comportements des versions 4.1 avec les versions d'avant (dites pré-4.1), mais le comportement 4.1 ne commence en réalité qu'avec la version 4.1.1. MySQL 4.1.0 est une version « marginale », car elle a un mécanisme légèrement différent de celui qui est implémenté en versions 4.1.1 et plus récentes. Les différences entre les versions 4.1.0 et les versions plus récentes sont décrites ultérieurement.

Avant MySQL 4.1, les hashs calculés par PASSWORD() étaient longs de 16 octets. Des hashs ressemblaient à ceci :