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. See Section 5.2, « Configuration de MySQL ».

mysqld-max

Une version du serveur qui inclut des fonctionnalités supplémentaires. See Section 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. See Section 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. See Section 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. See Section 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_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.

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 ».

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.

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.php. See Section 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 » pour plus d'informations sur les paquets Linux RPM.

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

--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 de InnoDB, mais cette option est nécessaire pour MySQL 3.23. Depuis MySQL 4, InnoDB est inclut 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.

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 incluent 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.

--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

Ecrit le fichier d'erreurs dans le fichier ci-dessus. See Section 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 connexion 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 serveur et les bases de données sont placées 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 sources). 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ées dans le dossier de travail, safe_mysqld essaie de les trouver en utilisant leurs chemins absolus. Les chemin 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.

--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 log. Par défaut, le fichier de log 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 de la 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.

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 :

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

See Section 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 reception 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 :

----------------------------------------------------------------
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
----------------------------------------------------------------

See Section 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 super utilisateur, 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 faîtes.

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 sachiers ce que vous faîtes. Démarrer plusieurs serveurs mysqlds dans le même dossier ne vous donnera aucun gain de performance dans un système threadé. See Section 5.10, « Faire fonctionner plusieurs serveurs MySQL sur la même machine ».

Options qui affectent la sécurité : voir Section 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 ».

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

Options de réplication : voir Section 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 », Section 14.4.3, « Options de démarrage BDB », Section 15.5, « Options de démarrage InnoDB ».

--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 utilisateurs qui disposent d'un seul symbôle xxx puissent être chargées. Par défaut, cette option est désactivée, et seule 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. See Section 27.2.3.6, « Précautions à prendre avec les fonctions utilisateur ».

--ansi

Utilise la syntaxe ANSI SQL au lieu de la syntaxe MySQL. See Section 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 suffirait. Depuis la version 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

Ecrit les messages d'erreurs 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. See Section 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

Ecrire le fichier core lorsque mysqld s'arrête inopinément. Pour certains fichiers, vous devez aussi spécifier --core-file-size à safe_mysqld. See Section 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. See Section D.1.2, « Créer un fichier de tra¸age ».

--default-character-set=charset

Spécifie le jeu de caractères par défaut. See Section 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. See Section 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. See Chapitre 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 écriture 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. See Section 7.5.2, « Réglage des paramètres du serveur ». See Section 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 tables 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é 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 ca 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 qui 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 :

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

Ecrit 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. See Section 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é. See Section 5.8.2, « Langue des messages d'erreurs ».

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

Enregistre les connexions et les requêtes dans ce fichier. See Section 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. See Section 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. See Section 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'erreurs et les messages de démarrage dans ce fichier. See Section 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 enregistre spécifiquement les requête 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. See Section 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 a s'exécuter. Notez que la quantité d'information enregistrée par défaut a changé en MySQL 4.1. Voyez les options --log-long-format et --log-long-format pour plus de détails. See Section 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. See Section 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). See Section 5.9.4, « Le log binaire ». Depuis la version 5.0.0, utilisez --log-update va simplement activer le log binaire. (see Section 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. See Section 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 modifications 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. See Section 7.3.2, « Problème de verrouillage de tables ».

--memlock

Verrouille le processus mysqld en mémoire. Cela fonctionne si votre système support 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 la quelle la réparation s'effectue.

Avant que la table ne soit automatiquement réparée, MySQL va ajouter une note dans le fichier de log 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 :

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 connexion TCP/IP.

--old-protocol, -o

Utilise le protocole 3.20, pour la compatibilité avec de très vieux clients. See Section 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. See Section 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 certains é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. See Section 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 ancien (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 bug 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. See Section 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. See Section 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 tables. 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 nom de domaine pour une résolution des IP plus rapide, mais interroger le serveur DNS à chaque connexion. See Section 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. See Section 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. See Section 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.

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, a 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. See Section 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. See Section 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 fichier 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. See Section 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 que 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. See Section 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 que 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.

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 sont 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)

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 a ê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 :

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 exporter, vous éviter 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. See Section 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)

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 uni-lignes.

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.

ANSI

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

DB2

Equivalent à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

MAXDB

Equivalent à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

MSSQL

Equivalent à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

MYSQL323

Equivalent à NO_FIELD_OPTIONS.

MYSQL40

Equivalent à NO_FIELD_OPTIONS.

ORACLE

Equivalent à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

POSTGRESQL

Equivalent à PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.

TRADITIONAL

Equivalent à STRICT_TRANS_TABLES, STRICT_ALL_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO.

ansi_mode

Vaut ON si mysqld a été démarré en mode --ansi. See Section 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 connexions 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ête 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 donne 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 la 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 la 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.

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 transactionnel, et depuis MySQL 4.1.2, si le serveur a un log binaire activé (option --log-bin). Si vous utilisez souvent de grandes transactions multi-requê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. See Section 5.9.4, « Le log binaire ».

bulk_insert_buffer_size

MyISAM utilise une cache hiérarchisé pour les insertions de masses (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ées 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 :

Si DELAY_KEY_WRITE est activé, cela signifie que le buffer de clé des tables ayant cette option ne seront pas écrit sur le disque dès la fin de la modification de la table, mais attendrons 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 » et Section 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 si 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. See Section 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 :

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

Une 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és, tels que définis 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 a 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'auto-validation activé. Il n'y a pas de variable globale à spécifier pour désactiver l'auto-validation, et init_connect peut servir à ¸a :

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 là :

[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 ».

interactive_timeout

Le nombre de secondes durant lequel le serveur attend une activité de la part de la connexion avant de la fermée. 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é est aussi appelé le cache de clé.

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. See Section 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. See Section 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é 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 :

(Key_blocks_used * key_cache_block_size) / key_buffer_size

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

(Key_blocks_used * 1024) / key_buffer_size

See Section 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é 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. See Section 7.4.6, « Le cache de clé des tables MyISAM ».

key_cache_block_size

La taille du bloc de cache de clé, en octets. La valeur par défaut est 1024. Cette variable a été ajoutée en MySQL 4.1.1. See Section 7.4.6, « Le cache de clé 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. See Section 7.4.6, « Le cache de clé des tables MyISAM ».

language

La langue utilisée pour les message 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é. See Section 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. See Section 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. See Section 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. See Section 5.9.5, « Le log des requêtes lentes ».

log_update

Si le log de modification 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. See Section 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é, pourrait être au dessus avec le même système, mais chargé. See Section 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ées 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. See Section 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 fichier 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 message est initialisé avec net_buffer_length octets, mais peut grandir jusqu'à max_allowed_packet octets lorsque nécessaire. Cette valeur est par défaut petit, 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 multi-requê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 grand 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 connexion 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 pointeur de fichier que requiert mysqld. Voyez la section Section 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 ».

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'erreur, 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ête, 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 binaire 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. See Section 6.3, « Détails d'implémentation de la réplication ».

max_seeks_for_key

La limite de recherche lors de recherche 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 a 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 ouverte 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 pose 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. See Section 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é. C'est surtout utilisé pour forcer les grands index à utiliser la méthode plus lente du cache de clé pour créer l'index. Cette variable a été ajoutée en MySQL 3.23.37. Note  : la valeur donnée est en megaoctets 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é (plus lent). Cette variable a été ajoutée en MySQL 3.23.37. Note : ce paramètre est spécifié en megaoctets 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 multi-threadé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és 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 communication 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 requête envoyé 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 une port de communication est interrompu, net_retry_count tentatives sont faites avant d'abandonner. Cette valeur doit être particulièrement grande pour FreeBSD car les interruptions internes sont envoyés à 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ête. 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 ». 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ête 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ête. 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 :

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 scan 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. A 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 pre-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 pre-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 si 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. See Section 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. See Section 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. See Section 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 force les tables à se recharger), vous devrez alors augmenter cette valeur.

Pour plus d'informations sur le cache de table, voyez Section 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. See Section 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é 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. (see Section 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. See Section 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. See Section 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 cet 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.

Aborted_clients

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

Aborted_connects

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

Binlog_cache_disk_use

Le nombre de transactions qui ont utilisé le cache de log binaire 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 log binaire temporaire. 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écution 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 connexions 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éé. 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'insertion 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ées 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ête de lecture de ligne 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ête 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ête 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 faîtes 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 lecture 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ête de modification d'une ligne dans une table.

Handler_write

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

Key_blocks_used

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

Key_read_requests

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

Key_reads

Nombre de lecture physique d'un bloc de clé 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é dans le cache.

Key_writes

Nombre d'écriture physiques de bloc de clé 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ête.

Qcache_free_memory

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

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ée 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. See Section 5.9.5, « Le log des requêtes lentes ».

Sort_merge_passes

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

Sort_range

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

Sort_rows

Nombre de lignes triées.

Sort_scan

Nombre de tris qui ont été fait 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 thread. 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.

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 :

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. A 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 à devenir pour un attaquant.

Investissez dans un coupe-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 :

Ne faîtes 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 :

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 :

Les autres interfaces ont des fonctionnalités similaires.

Ne transmettez pas de données déchiffrées sur Internet. Cette information est accessible à tout 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 :

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.

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@ :

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 tout 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 :

[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 ».

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 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!! See Section 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 connexions libres pour les autres utilisateurs.

Le droit SUPER peut être utilisé pour fermer des connexions clients, changer les variables systèmes 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'option de contrôle des ressources, pour limiter l'utilisation du serveur par un compte utilisateur.

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

Si vous utilisez --local-infile=0 alors vous ne pourrez pas utiliser LOAD DATA LOCAL INFILE. See Section 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 verison 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. See Section 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 :

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

Cela va s'assurer que l'utilisateur ne peut par 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 mot 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 faîtes 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.

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 auquel ce dernier a accès (en supposant qu'un utilisateur peut exécuter n'importe quelle commande sur le serveur).

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 compatible 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é par tous les clients, à moins que l'option mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0) soit activée dans le client. See Section 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) :

The used command is not allowed with this MySQL version

Etape 1 : Le serveur vérifie que vous êtes autorisé à vous connecter.

Etape 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.

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é. 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 ».

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 d'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étails dans Section 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 : elle s'appliquent au niveau des tables et des colonnes, plutôt qu'au niveau des bases.

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 inclus le contenu de toutes les bases actuellement hébergées sur le serveur !

Le droit de SHUTDOWN peut conduire au dénis 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).

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.

l'hôte que vous voulez utiliser

votre nom d'utilisateur

votre mot de passe

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.

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 :

[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 ».

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 ». Voyez aussi la prochaine section Annexe E, Variables d'environnement.

L'hôte depuis lequel vous vous connectez

Votre nom d'utilisateur MySQL

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 jokers ?%? 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 :

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 :

user_ip & netmask = host_ip

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

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 ».

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

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.

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 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 jokers, dans les deux tables.

Les droits de table 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 effets lors de la prochaine connexion.

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 :

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 :

shell> netstat -l | grep mysql

Les tables de droits doivent être correctement configurée 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 post-installation 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 :

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 :

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 ».

Si vous avez mis à jour une version de MySQL avec une nouvelle versions, avez-vous utilisé le script mysql_fix_privilege_tables? Si ce n'est pas le cas, faîtes-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 ».

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 :

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 » et Section 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 :

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 :

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

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

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

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 décrit ci-dessus.

Pour des informations sur les changements de mot de passe, voyez Section 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. See Section 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. See Section 5.6.5, « Configurer les mots de passe ».

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

A la place, utilisez cette commande :

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 utilisent 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 :

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 correspondent 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 :

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és. (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 :

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. See Section 7.5.6, « Comment MySQL utilise le DNS ».

Les autres solutions sont :

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 alternative 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é et n'est pas recommandé !)

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 :

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-ils effets ? ».

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. See Section 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. See Section 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.

Premièrement, lorsqu'un client tente de se connecter au serveur, il y a une identification initial 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.

Si vous faites une nouvelle installation de MySQL 4.1, la colonne Password fera automatiquement 41 octets.

Si vous mettez à jour une ancienne installation, il est recommandé d'utiliser le script mysql_fix_privilege_tables pour mettre à jour la taille de la colonne Password, de 16 à 41 octets. Le script ne modifie pas les valeurs elles-mêmes, qui restent à 16 octets de long.

La différence principale et évidente est la taille : 16 octets et 41 octets.

La seconde différence est que les hashs au nouveau format commencent par le caractère ?*?, alors que l'ancien format ne le fait pas.

Si la colonne est étroite, l'identification par hash court sera utilisée.

Si la colonne est large, elle peut contenir des hashs longs ou courts, et le serveur peut utiliser l'un ou l'autre des formats :

Les clients pre-4.1 s'identifiant avec un hash court

Les clients 4.1 s'identifiant avec un hash court

Les clients 4.1 s'identifiant avec un hash long

La colonne Password doit être assez grande pour acceuillir des hashs de mot de passe longs (41 octets). Si la colonne n'a pas été mise à jour, et qu'elle a toujours la taille de 16 octets, le serveur le remarque, et générera des hashs de mots de passe courts lorsque le client va modifier son mot de passe avec PASSWORD(), GRANT ou SET PASSWORD. Ce comportement survient si vous avez mis à jour le serveur en version 4.1, mais omis d'utiliser le script mysql_fix_privilege_tables pour élargir la colonne Password.

Si la colonne Password est suffisamment grande, elle peut stocker un mot de passe long ou court. Dans ce cas, PASSWORD(), GRANT et SET PASSWORD vont générer des hashs longs, à moins que le serveur n'ait été lancé avec l'option --old-passwords. Cette option force le serveur à utiliser les hashs courts.

Un ancient client se connecter sur un compte, avec un hash court.

Le client change le mot de passe. Sans l'option --old-passwords, cela conduit à la création d'un hash long.

Lors de la prochaine connexion, le client pre-4.1 ne peut plus se connecter, car le compte requiert désormais le nouveau mécanisme d'identification. Une fois que le hash long est dans la table user, seuls les clients 4.1 peuvent l'utiliser, car les clients pre-4.1 ne le comprennent pas.

Seuls, les hashs courts peuvent être stockés dans la colonne Password.

Le serveur utilise uniquement les hashs courts pour les identifications.

Pour les clients connectés, la génération de mot de passe avec PASSWORD(), GRANT ou SET PASSWORD utilise les mots de passe courts uniquement. Toute modification de compte entraine la création d'un hash court.

L'option --old-passwords peut être utilisée, mais est superflue, car la colonne Password courte impose la manipulation de hashs courts de toutes manières.

les hashs courts et longs peuvent être stockés dans la colonne Password.

Les clients 4.1 peuvent s'identifier sur leur compte avec des hashs courts ou longs.

Les clients pre-4.1 peuvent s'identifier sur leur compte avec des hashs courts.

Pour les clients connectés, la génération de mot de passe avec PASSWORD(), GRANT ou SET PASSWORD utilise les mots de passe longs uniquement. Toute modification de compte entraine la création d'un hash long.

les hashs courts et longs peuvent être stockés dans la colonne Password.

Les clients 4.1 peuvent s'identifier sur leur compte avec des hashs courts ou longs. Notez qu'il n'est alors possible de créer des hashs longs si le serveur utilise --old-passwords).

Les clients pre-4.1 peuvent s'identifier sur leur compte avec des hashs courts.

Pour les clients connectés, la génération de mot de passe avec PASSWORD(), GRANT ou SET PASSWORD utilise les mots de passe courts uniquement. Toute modification de compte entraine la création d'un hash long.

Les noms d'utilisateurs, tels qu'utilisés pour le processus d'identification sous MySQL, n'ont rien à voir avec les noms d'utilisateurs Unix ou Windows. La plupart des clients utilisent par défaut leur mot de passe Unix, mais c'est surtout parce que c'est pratique. Les programmes clients permettent d'utiliser des noms d'utilisateurs différents avec les options -u et --user. Cela signifie que vous ne pouvez pas rendre une base de données sécuritaire sans donner de mots de passe à tous les clients. Tout le monde peut essayer de se connecter au serveur sous n'importe quel nom, et il sera possible de se connecter si un nom d'utilisateur n'a pas de mot de passe.

Les noms d'utilisateurs MySQL peuvent avoir jusqu'à 16 caractères ; les noms d'utilisateurs Unix sont généralement limités à 8 caractères.

Les mots de passe MySQL n'ont aucun rapport avec le passeport Unix. Il n'y a pas nécessairement de connexion entre le mot de passe que vous utilisez pour vous connecter sur la machine Unix et celui que vous utilisez pour accéder au serveur MySQL.

MySQL chiffre les mots de passe avec un algorithme différent de celui qui est utilisé par Unix. Reportez-vous aux descriptions des fonctions PASSWORD() et ENCRYPT() dans Section 12.8.2, « Fonctions de chiffrements ». Notez que même si le mot de passe est enregistré 'brouillé', connaître votre mot de passe 'brouillé' est suffisant pour se connecter au serveur MySQL.

en utilisant la commande GRANT

manipulant la table des droits de MySQL directement

Deux comptes de super-utilisateur qui utilisent le mot de passe 'un_mot_de_passe'. Les deux comptes ont tous les droits sur le serveur. Un des comptes, 'monty'@'localhost', peut être utilisé depuis la machine locale. L'autre depuis n'importe quel autre serveur : 'monty'@'%'. Notez que nous devons exécuter une commande GRANT pour 'monty'@'localhost' et 'monty'@'%'. Si nous n'ajoutons pas l'entrée avec localhost, l'entrée concernant l'utilisateur anonyme pour localhost qui est créée par mysql_install_db prendra précédence lors de la connexion à partir de l'hôte local, car elle a une entrée plus spécifique pour la valeur du champ Host et de plus, elle vient en premier dans l'ordre de tri de la table user. Les tris de la table user sont présentés dans la section Section 5.5.5, « Contrôle d'accès, étape 1 : Vérification de la connexion ».

Un utilisateur admin qui peut se connecter depuis localhost sans mot de passe et qui a les droits administratifs RELOAD et PROCESS. Cela permet à cet utilisateur d'exécuter les commandes mysqladmin reload, mysqladmin refresh, et mysqladmin flush-*, ainsi que mysqladmin processlist. Aucun droit lié aux bases de données n'est donné. Ils peuvent l'être plus tard en utilisant d'autres instructions GRANT.

Un utilisateur dummy qui peut se connecter sans mot de passe, mais seulement à partir de l'hôte local. Les droits globaux sont tous à 'N' : le type de droit USAGE vous permet de créer un utilisateur démuni de privilège. Il est supposé que vous lui assignerez les droits spécifiques aux bases de données plus tard.

Le premier compte a accès à la base bankaccount, mais uniquement depuis l'hôte local.

Le second compte peut accéder à la base expenses, mais uniquement depuis l'hôte whitehouse.gov.

Le troisième compte peut accéder à la base customer, mais uniquement depuis l'hôte server.domain.

Nombre de requête par heure : Toutes les commandes qu'un utilisateur peut exécuter.

Nombre de modifications par heure : Toute commande qui implique la modification d'une table ou d'une base.

Nombre de connexions réalisées par heure : Le nombre de nouvelles connexions par heure.

Pour remettre à zéro les compteurs pour tous les comptes, faites un FLUSH USER_RESOURCES. Les comptes sont remis à zéro au moment du re-chargement des tables de droits : par exemple, avec la commande FLUSH PRIVILEGES ou la commande mysqladmin reload.

Les comptes individuels peuvent être remis à zéro en donnant de nouvelles limites ou changeant les droits. Pour cela, utilisez GRANT USAGE tel que décrit précédemment, en donnant la même limite que celle qui est configurée.

Pour établir un mot de passe lors de la création d'un compte, fournissez une valeur à la colonne Password :

shell> mysql -u root mysql
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('%','jeffrey','biscuit');
mysql> FLUSH PRIVILEGES;

Pour changer le mot de passe d'un compte existant, utilisez la commande UPDATE pour modifier la valeur de la colonne Password :

shell> mysql -u root mysql
mysql> UPDATE user SET Password = PASSWORD('bagel')
    -> WHERE Host = '%' AND User = 'francis';
mysql> FLUSH PRIVILEGES;

Utilisez l'option -p ou --password (sans la valeur du mot de passe). Dans ce cas, le programme client va solliciter la saisie du mot de passe depuis le terminal :

shell> mysql -u user_name -p
Enter password: ********

Cette méthode est pratique mais peu sûre, car le mot de passe est visible par les programmes système tels que ps qui peuvent être appelé par les autres utilisateurs. Les clients MySQL remplacent généralement les arguments de la ligne de commande par des zéros durant leur initialisation, mais il y a un court instant où la valeur est visible.

Utilisez les options -p ou --password sans valeur de mot de passe. Dans ce cas, le client va solliciter explicitement le mot de passe du terminal :

shell> mysql -u francis
Enter password: ********

Les caractères ?*? représentent votre mot de passe. Le mot de passe n'est pas affiché en clair lors de votre saisie.

Cette méthode est bien plus sûre pour saisir votre mot de passe qu'en le spécifiant directement en ligne de commande, car il n'est pas visible des autres utilisateurs. Cependant, cette méthode n'est possible qu'avec les programmes que vous utilisez en mode interactif. Si vous voulez invoquer le client depuis un script qui s'exécute de manière non interactive, il n'y aura pas d'opportunité pour saisir ce mot de passe dans le terminal. Sur certains systèmes, vous pourriez même voir la première ligne de votre script lue et interprétée comme votre mot de passe, incorrectement.

Stockez votre mot de passe dans le fichier de configuration. Par exemple, vous pouvez lister votre mot de passe dans la section [client] du fichier .my.cnf dans votre dossier personnel :

[client]
password=mot_de_passe

Si vous stockez ce mot de passe dans le fichier .my.cnf, le fichier ne doit pas être lisible par le groupe ou par les autres utilisateurs, ou encore accessible en écriture : seul le propriétaire de ce fichier doit avoir ces droits. Assurez-vous les droits d'accès au fichiers sont 400 ou 600. Par exemple :

shell> chmod 600 .my.cnf

Section 4.3.2, « Fichier d'options my.cnf » présente les options pour plus de détail.s

Vous pouvez stocker votre mot de passe dans la variable d'environnement MYSQL_PWD, mais cette méthode doit être considérée comme extrêmement peu sûre, et doit être évitée autant que possible. Certaines versions de la commande en ligne ps incluent une option pour afficher les variables d'environnement des processus : votre mot de passe sera alors facilement accessible, et en texte clair, si vous configurez la commande MYSQL_PWD. Même sur les systèmes sans une telle version de la commande ps, il est peu recommandé de supposer que les variables d'environnement sont inaccessibles par une méthode quelconque. See Annexe E, Variables d'environnement.

Exportez la table avec SELECT * INTO OUTFILE 'nom_fichier' FROM nom_de_table

Restaurez avec LOAD DATA INFILE 'nom_fichier' REPLACE .... Pour éviter les lignes dupliquées, vous aurez besoin d'une PRIMARY KEY ou une clef UNIQUE dans la table. Le mot clef REPLACE fait que les anciens enregistrements sont remplacés par les nouveaux lorsque l'un d'eux duplique un ancien sur une valeur de clef unique.