Prise en main du client mysql : administrer MySQL en ligne de commande

Vous avez installé MySQL, le service tourne, systemctl status mysql affiche active (running). Maintenant, il faut entrer dedans. Comment lister les bases existantes ? Voir la structure d'une table ? Exécuter une requête, exporter un résultat en CSV, ou lancer un script SQL automatisé ?

mysql est le client en ligne de commande officiel de MySQL. C'est l'outil quotidien de l'administrateur : exploration des bases et des tables, exécution de requêtes, import/export de données, et scripting en mode batch. Contrairement à psql (PostgreSQL), les commandes d'exploration passent par des instructions SHOW et des vues INFORMATION_SCHEMA plutôt que par des méta-commandes.

Version utilisée

Ce guide s'appuie sur le client mysql 8.4.5 (MySQL Community Server) sous Debian 12. Les commandes présentées fonctionnent sur toutes les distributions et toutes les versions MySQL 8.x.

Ce que vous allez apprendre

• Se connecter à MySQL en local (socket Unix) et en réseau (TCP/IP, login-path)
• Explorer la structure d'une instance avec SHOW, DESCRIBE et INFORMATION_SCHEMA
• Formater la sortie : mode vertical (\G), pager, export vers fichier avec tee
• Importer et exporter des données avec LOAD DATA, SELECT INTO OUTFILE et mysqlimport
• Scripter des tâches d'administration avec le mode batch (-e, redirection, source)

Dans quel contexte ?

Le client mysql est l'outil que vous utiliserez dans toutes ces situations :

• Vous venez d'installer MySQL et voulez vérifier ce qui existe sur l'instance
• Vous devez créer une base et des tables pour une nouvelle application
• Vous administrez un serveur et avez besoin de connaître la taille des bases, les connexions actives ou les variables critiques
• Vous devez importer un fichier CSV ou exporter des résultats pour un collègue
• Vous automatisez des tâches d'administration dans un script shell (migration, rapport, nettoyage)
• Vous devez diagnostiquer un problème de performance ou de connexion en production

Ce guide ne couvre pas…

Ce guide reste centré sur le client en ligne de commande, c'est-à-dire sur ce que vous tapez une fois connecté. L'architecture du serveur, son installation, son réglage et son durcissement font l'objet de guides séparés, listés ci-dessous. Si vous n'avez pas encore d'instance qui tourne, commencez par l'installation.

Découvrir MySQL Architecture, InnoDB, buffer pool, threads, le contexte avant d'administrer

Installation Installer MySQL 8.4 LTS depuis les dépôts Oracle et sécuriser l'instance

Configuration Régler InnoDB buffer pool, connexions, binary log et slow query log

Sécurisation caching_sha2_password, TLS, rôles et moindre privilège

Prérequis

• MySQL installé et le service actif (voir le guide Installation)
• Un compte avec les droits suffisants (root ou un compte d'administration créé lors de l'installation)

Vérification rapide :

mysql --version

mysql  Ver 8.4.5 for Linux on x86_64 (MySQL Community Server - GPL)

Se connecter à MySQL

MySQL accepte deux canaux de connexion : le socket Unix, un fichier spécial utilisable uniquement depuis la machine locale, et le TCP/IP pour tout le reste. Le client choisit le socket dès que l'hôte vaut localhost, ce qui surprend souvent : indiquer 127.0.0.1 force au contraire le passage par le réseau. Les trois méthodes de stockage des identifiants présentées ici vont du moins au plus sûr, terminez par mysql_config_editor.

Connexion locale (socket Unix)

La méthode la plus courante sur le serveur lui-même. La connexion passe par un socket Unix, pas de réseau, pas de chiffrement nécessaire :

mysql -u root -p

Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 12
Server version: 8.4.5 MySQL Community Server - GPL

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Le prompt mysql> indique que vous êtes connecté. Contrairement à PostgreSQL, MySQL n'a pas de prompt différent pour les superusers.

Pour se connecter directement à une base spécifique :

mysql -u root -p labdb

Connexion réseau (TCP/IP)

Pour une connexion depuis un autre serveur ou en forçant TCP (utile quand le socket n'est pas accessible) :

mysql -h 192.168.122.70 -P 3306 -u labadmin -p labdb

Option	Description
-h	Adresse du serveur (hostname ou IP)
-P	Port (3306 par défaut)
-u	Nom d'utilisateur
-p	Demander le mot de passe (sans espace après -p)
labdb	Base de données à sélectionner au démarrage

Glissez pour voir

Attention à -p vs -pMOTDEPASSE

-p seul demande le mot de passe en mode interactif (sécurisé). -pmotdepasse (collé, sans espace) passe le mot de passe en argument, il sera visible dans ps aux et dans l'historique shell. Ne faites jamais ça en production.

Fichier d'options ~/.my.cnf

Plutôt que de taper les options de connexion à chaque fois, créez un fichier ~/.my.cnf :

[client]
user=labadmin
password=MotDePasseFort!2026
host=127.0.0.1
port=3306

Protégez immédiatement les permissions :

chmod 600 ~/.my.cnf

Sur Unix, MySQL ignore les fichiers de configuration world-writable, le chmod 600 est donc indispensable, pas optionnel.

Ensuite, une simple commande suffit :

mysql labdb

Mot de passe en clair

Le fichier ~/.my.cnf stocke le mot de passe en clair sur le disque. C'est acceptable pour un lab, mais en production, préférez mysql_config_editor (voir ci-dessous) qui chiffre les identifiants.

mysql_config_editor : identifiants chiffrés (login-path)

MySQL fournit un outil dédié pour stocker les identifiants de manière sécurisée :

mysql_config_editor set --login-path=lab --host=127.0.0.1 --user=labadmin --password

L'outil demande le mot de passe et le stocke chiffré dans ~/.mylogin.cnf. Pour l'utiliser :

mysql --login-path=lab labdb

Pour lister les profils enregistrés :

mysql_config_editor print --all

[lab]
user = labadmin
password = *****
host = 127.0.0.1

Le mot de passe est masqué, il n'est jamais affiché en clair.

Préférez login-path à ~/.my.cnf

mysql_config_editor stocke les paramètres de connexion dans ~/.mylogin.cnf sous forme de login paths. Ce fichier est utilisé par les clients MySQL sans exposer le mot de passe sur la ligne de commande, et il reste pris en compte même avec --no-defaults (sauf si vous ajoutez --no-login-paths).

\s et status : vérifier sa connexion

Une fois connecté, vérifiez toujours où vous êtes :

\s

--------------
mysql  Ver 8.4.5 for Linux on x86_64 (MySQL Community Server - GPL)

Connection id:          12
Current database:       labdb
Current user:           root@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         8.4.5 MySQL Community Server - GPL
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    utf8mb4
Db     characterset:    utf8mb4
Client characterset:    utf8mb4
Conn.  characterset:    utf8mb4
UNIX socket:            /var/run/mysqld/mysqld.sock
Binary data as:         Hexadecimal
Uptime:                 2 hours 15 min 32 sec

Connection: Localhost via UNIX socket confirme la connexion locale. Current database: labdb montre la base active.

Explorer l'instance

Contrairement à PostgreSQL qui utilise des méta-commandes (\l, \dt, \d), MySQL s'appuie sur des instructions SHOW et des vues dans INFORMATION_SCHEMA.

SHOW DATABASES

Lister toutes les bases de données de l'instance :

SHOW DATABASES;

+--------------------+
| Database           |
+--------------------+
| information_schema |
| labdb              |
| mysql              |
| performance_schema |
| sys                |
+--------------------+

Base	Rôle
information_schema	Catalogue virtuel, métadonnées sur toutes les tables, colonnes, index
mysql	Tables système : comptes, privilèges, data dictionary
performance_schema	Instrumentation interne : requêtes, verrous, I/O, threads
sys	Vues simplifiées au-dessus de performance_schema (lisibles par un humain)
labdb	Votre base de données applicative

Glissez pour voir

USE : changer de base de données

USE fixe la base active de la session, ce qui évite de préfixer chaque nom de table. La commande ne renvoie aucune donnée et n'ouvre aucune transaction, elle ne fait que changer le contexte courant.

USE labdb;

Database changed

Toutes les requêtes suivantes s'exécutent dans le contexte de labdb, pas besoin de préfixer les noms de tables.

SHOW TABLES et SHOW COLUMNS

Lister les tables de la base active :

SHOW TABLES;

+-----------------+
| Tables_in_labdb |
+-----------------+
| clients         |
| commandes       |
| deploiements    |
| environnements  |
| services        |
+-----------------+

Voir les colonnes d'une table :

SHOW COLUMNS FROM clients;

+-------------+--------------+------+-----+-----------+----------------+
| Field       | Type         | Null | Key | Default   | Extra          |
+-------------+--------------+------+-----+-----------+----------------+
| id          | int          | NO   | PRI | NULL      | auto_increment |
| nom         | varchar(100) | NO   |     | NULL      |                |
| email       | varchar(200) | NO   | UNI | NULL      |                |
| equipe      | varchar(50)  | YES  |     | NULL      |                |
| inscription | date         | YES  |     | curdate() |                |
+-------------+--------------+------+-----+-----------+----------------+

L'alias DESCRIBE (ou DESC) produit le même résultat :

DESC clients;

SHOW CREATE TABLE : le DDL exact

Pour voir la requête CREATE TABLE exacte, y compris le moteur de stockage, le charset et les contraintes :

SHOW CREATE TABLE clients\G

*************************** 1. row ***************************
       Table: clients
Create Table: CREATE TABLE `clients` (
  `id` int NOT NULL AUTO_INCREMENT,
  `nom` varchar(100) NOT NULL,
  `email` varchar(200) NOT NULL,
  `equipe` varchar(50) DEFAULT NULL,
  `inscription` date DEFAULT (curdate()),
  PRIMARY KEY (`id`),
  UNIQUE KEY `email` (`email`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

C'est la commande la plus utile pour reproduire une table sur un autre serveur ou comprendre sa configuration exacte (moteur InnoDB, charset utf8mb4, collation).

SHOW INDEX : les index d'une table

Cette commande liste un enregistrement par colonne indexée, pas par index : un index composite apparaît donc sur plusieurs lignes, distinguées par Seq_in_index. La colonne Cardinality estime le nombre de valeurs distinctes ; c'est elle que l'optimiseur consulte pour décider d'utiliser l'index, et elle n'est rafraîchie que par ANALYZE TABLE.

SHOW INDEX FROM clients\G

*************************** 1. row ***************************
        Table: clients
   Non_unique: 0
     Key_name: PRIMARY
 Seq_in_index: 1
  Column_name: id
    Collation: A
  Cardinality: 10
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
      Visible: YES
   Expression: NULL
*************************** 2. row ***************************
        Table: clients
   Non_unique: 0
     Key_name: email
 Seq_in_index: 1
  Column_name: email
    Collation: A
  Cardinality: 10
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
      Visible: YES
   Expression: NULL

INFORMATION_SCHEMA : requêtes sur le catalogue

INFORMATION_SCHEMA est un standard SQL implémenté par MySQL. Il expose les métadonnées sous forme de tables virtuelles interrogeables avec du SQL classique :

Taille des bases :

SELECT table_schema AS base,
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS taille_mb
FROM information_schema.TABLES
GROUP BY table_schema
ORDER BY taille_mb DESC;

+--------------------+-----------+
| base               | taille_mb |
+--------------------+-----------+
| mysql              |      2.67 |
| labdb              |      0.22 |
| sys                |      0.02 |
| information_schema |      0.00 |
| performance_schema |      0.00 |
+--------------------+-----------+

Taille détaillée par table :

SELECT table_name,
       ROUND((data_length + index_length) / 1024, 2) AS taille_ko,
       table_rows AS lignes_estimees
FROM information_schema.TABLES
WHERE table_schema = 'labdb'
ORDER BY (data_length + index_length) DESC;

+----------------+-----------+-----------------+
| table_name     | taille_ko | lignes_estimees |
+----------------+-----------+-----------------+
| deploiements   |     48.00 |              20 |
| commandes      |     48.00 |              15 |
| services       |     32.00 |               8 |
| clients        |     32.00 |              10 |
| environnements |     32.00 |               4 |
+----------------+-----------+-----------------+

table_rows est une estimation

La colonne table_rows de INFORMATION_SCHEMA.TABLES est une estimation pour les tables InnoDB, pas un comptage exact. Pour un décompte précis, utilisez SELECT COUNT(*) FROM table. Cette approximation vient du fait qu'InnoDB utilise un comptage MVCC qui serait trop coûteux à maintenir en temps réel.

Lister les colonnes d'une table :

SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.COLUMNS
WHERE table_schema = 'labdb' AND table_name = 'clients'
ORDER BY ordinal_position;

+-------------+-----------+-------------+----------------+
| column_name | data_type | is_nullable | column_default |
+-------------+-----------+-------------+----------------+
| id          | int       | NO          | NULL           |
| nom         | varchar   | NO          | NULL           |
| email       | varchar   | NO          | NULL           |
| equipe      | varchar   | YES         | NULL           |
| inscription | date      | YES         | curdate()      |
+-------------+-----------+-------------+----------------+

Performance Schema et sys : diagnostic en direct

Performance Schema instrumente le serveur en temps réel. La base sys offre des vues simplifiées par-dessus :

Connexions actives :

SELECT * FROM sys.session\G

Requêtes les plus lentes (top 10) :

SELECT query, exec_count, avg_latency, rows_examined_avg
FROM sys.statements_with_runtimes_in_95th_percentile
LIMIT 10;

Tables les plus accédées :

SELECT table_schema, table_name, rows_fetched, rows_inserted, rows_updated, rows_deleted
FROM sys.schema_table_statistics
WHERE table_schema = 'labdb'
ORDER BY rows_fetched DESC;

Commencez par les vues sys

Les requêtes directes sur performance_schema sont verbeuses et complexes. Utilisez d'abord les vues de sys, elles sont conçues pour être lisibles par un humain. Le guide Monitoring les explore en détail.

Tableau récapitulatif des commandes d'exploration

Gardez ce tableau sous la main : ce sont les onze commandes qui couvrent la quasi-totalité de l'exploration d'une instance inconnue. Les trois dernières concernent le serveur plutôt que les données, elles répondent aux questions « comment est-il configuré » et « que fait-il en ce moment ».

Commande	Description
SHOW DATABASES;	Lister les bases de données
USE <base>;	Changer de base active
SHOW TABLES;	Lister les tables de la base active
SHOW COLUMNS FROM <table>;	Colonnes, types, clés, défauts
DESC <table>;	Alias de SHOW COLUMNS
SHOW CREATE TABLE <table>\G	DDL complet (moteur, charset, contraintes)
SHOW INDEX FROM <table>\G	Index, cardinalité, type
SHOW TABLE STATUS\G	Taille, moteur, lignes estimées
SHOW VARIABLES LIKE 'pattern';	Variables de configuration serveur
SHOW GLOBAL STATUS LIKE 'pattern';	Compteurs de statut serveur
SHOW PROCESSLIST;	Connexions actives et requêtes en cours

Glissez pour voir

Formatage et affichage

Le client ajuste sa présentation selon le contexte : bordures ASCII en mode interactif, valeurs séparées par des tabulations quand la sortie est redirigée. Savoir forcer l'un ou l'autre change tout, aussi bien pour lire une table de trente colonnes que pour produire une sortie exploitable par un script shell.

Mode tableau (par défaut) et mode vertical (\G)

Le mode par défaut affiche les résultats en tableau horizontal. Pour les résultats larges (beaucoup de colonnes), le mode vertical avec \G est beaucoup plus lisible :

-- Mode tableau (défaut)
SELECT * FROM clients WHERE id = 1;

+----+---------+-------------------+--------+-------------+
| id | nom     | email             | equipe | inscription |
+----+---------+-------------------+--------+-------------+
|  1 | Alice   | alice@devops.lab  | SRE    | 2026-01-15  |
+----+---------+-------------------+--------+-------------+

-- Mode vertical
SELECT * FROM clients WHERE id = 1\G

*************************** 1. row ***************************
         id: 1
        nom: Alice
      email: alice@devops.lab
     equipe: SRE
inscription: 2026-01-15

Le \G remplace le ; en fin de requête, ne mettez pas les deux.

Pager et tee : sortie vers un fichier

Pour paginer les résultats longs (comme less en shell) :

pager less -S;
SHOW GLOBAL STATUS;
nopager;

Pour capturer toute la session dans un fichier (requêtes + résultats) :

tee /tmp/session-mysql.log
-- vos requêtes ici...
notee

Le fichier /tmp/session-mysql.log contiendra l'intégralité de vos commandes et leurs résultats, utile pour documenter une session de diagnostic.

Options de formatage en ligne de commande

Ces options s'appliquent à toute la session et se combinent entre elles. Le duo -B -N est celui des scripts : il produit des valeurs brutes séparées par des tabulations, directement exploitables par cut ou awk.

Option	Effet
-t ou --table	Force le mode tableau (défaut en interactif)
-E ou --vertical	Force le mode vertical pour toutes les requêtes
-N ou --skip-column-names	Supprime les en-têtes de colonnes
-B ou --batch	Mode batch (pas de tableau, valeurs séparées par tabulation)
--xml	Sortie en XML
--html	Sortie en HTML

Glissez pour voir

Exécuter du SQL

Le client fonctionne dans deux régimes différents. En interactif, il attend un terminateur (; ou \G) et vous laisse écrire une requête sur plusieurs lignes. En batch, il lit son entrée standard ou l'argument de -e, exécute et rend la main, ce qui en fait la brique de base des scripts d'administration et des jobs planifiés.

Requêtes interactives

Tapez votre SQL suivi de ; ou \G :

SELECT nom, equipe, inscription FROM clients ORDER BY inscription;

+---------+----------+-------------+
| nom     | equipe   | inscription |
+---------+----------+-------------+
| Alice   | SRE      | 2026-01-15  |
| Bob     | Backend  | 2026-02-20  |
| Claire  | Frontend | 2026-03-10  |
| David   | SRE      | 2026-03-28  |
| Eva     | DevOps   | 2026-04-01  |
+---------+----------+-------------+

Les requêtes multi-lignes sont supportées, MySQL attend le ; final :

SELECT c.nom, COUNT(d.id) AS nb_deploy
FROM clients c
JOIN deploiements d ON d.responsable = c.nom
GROUP BY c.nom
ORDER BY nb_deploy DESC;

Mode batch : -e et redirection

Pour exécuter une requête depuis le shell (scripts, cron, CI/CD) :

mysql -u root -p labdb -e "SELECT nom, equipe FROM clients;"

+---------+----------+
| nom     | equipe   |
+---------+----------+
| Alice   | SRE      |
| Bob     | Backend  |
| Claire  | Frontend |
| David   | SRE      |
| Eva     | DevOps   |
+---------+----------+

Pour un résultat sans tableau (exploitable par un script) :

mysql -u root -p labdb -BNe "SELECT COUNT(*) FROM clients;"

5

Option	Effet
-B	Mode batch (séparateur tabulation, pas de bordures)
-N	Pas d'en-têtes de colonnes
-e "..."	Exécuter la requête et quitter

Glissez pour voir

Pour rediriger un fichier SQL complet :

mysql -u root -p labdb < /tmp/rapport.sql

source : exécuter un fichier SQL depuis le client

Depuis le prompt mysql> :

source /tmp/01-sample-data.sql

Ou avec le raccourci :

\. /tmp/01-sample-data.sql

C'est l'équivalent MySQL de \i dans psql. Le fichier est lu et exécuté ligne par ligne.

Créer et gérer des objets

Créer une base, la peupler, revenir en arrière : ces opérations quotidiennes réservent quelques surprises à qui vient de PostgreSQL. La principale tient au DDL non transactionnel de MySQL, qui valide implicitement tout ce qui précède. Cette section explique aussi le mode autocommit, actif par défaut, qui décide si vos modifications sont enregistrées immédiatement ou non.

Créer une base et des tables

Deux précisions valent d'être écrites explicitement dans tout DDL : le jeu de caractères utf8mb4, seul à couvrir l'intégralité d'Unicode (émojis compris), et le moteur de stockage InnoDB, qui apporte les transactions et les clés étrangères.

CREATE DATABASE mon_projet CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE mon_projet;

CREATE TABLE utilisateurs (
  id INT AUTO_INCREMENT PRIMARY KEY,
  login VARCHAR(50) UNIQUE NOT NULL,
  email VARCHAR(200) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

Toujours préciser ENGINE=InnoDB

InnoDB est le moteur par défaut depuis MySQL 5.5, mais l'indiquer explicitement dans le DDL documente votre intention et préserve la compatibilité si quelqu'un change le moteur par défaut dans la configuration.

Transactions : BEGIN, COMMIT, ROLLBACK

MySQL avec InnoDB supporte les transactions ACID :

BEGIN;
INSERT INTO clients (nom, email, equipe) VALUES ('Test Rollback', 'test@lab.dev', 'QA');
SELECT COUNT(*) AS total FROM clients;

+-------+
| total |
+-------+
|    11 |
+-------+

L'insertion est visible dans la transaction. Annulons :

ROLLBACK;
SELECT COUNT(*) AS total FROM clients;

+-------+
| total |
+-------+
|    10 |
+-------+

DDL et transactions dans MySQL

Beaucoup d'ordres DDL MySQL (CREATE TABLE, ALTER TABLE, DROP TABLE, TRUNCATE) provoquent un COMMIT implicite, si vous êtes dans une transaction et exécutez un DROP TABLE, toutes les modifications précédentes sont commitées automatiquement.

MySQL 8.4 prend en charge l'atomic DDL pour de nombreuses opérations InnoDB (un DROP TABLE multi-tables est entièrement annulé s'il échoue en cours de route), mais cela ne signifie pas que le DDL se comporte comme du DDL transactionnel à la PostgreSQL.

autocommit : comprendre le comportement par défaut

Par défaut, MySQL exécute chaque requête dans sa propre transaction, c'est le mode autocommit :

SELECT @@autocommit;

+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+

Chaque INSERT, UPDATE ou DELETE est immédiatement commité. Pour grouper des opérations dans une transaction, utilisez BEGIN / START TRANSACTION :

START TRANSACTION;
-- vos modifications ici...
COMMIT;     -- ou ROLLBACK;

Supprimer des objets

DROP supprime un objet :

DROP TABLE IF EXISTS utilisateurs;
DROP DATABASE IF EXISTS mon_projet;

IF EXISTS évite une erreur si l'objet n'existe pas, recommandé dans les scripts.

Pas de CASCADE automatique sur DROP TABLE

Contrairement à PostgreSQL, DROP TABLE dans MySQL supprime les contraintes de clé étrangère qui référencent la table si vous désactivez temporairement les vérifications : SET FOREIGN_KEY_CHECKS = 0;. Sans cela, le DROP échoue si d'autres tables ont des FK vers cette table. Ne désactivez FOREIGN_KEY_CHECKS que dans des scripts de migration contrôlés.

Importer et exporter des données

Quatre outils se partagent la tâche, et le premier critère de choix est l'emplacement du fichier : sur le serveur ou sur votre poste. La seconde contrainte est la variable secure_file_priv, qui restreint les répertoires autorisés et bloque purement et simplement ces opérations quand elle vaut NULL. Vérifiez-la avant de chercher pourquoi un import échoue.

LOAD DATA INFILE : import depuis un fichier sur le serveur

LOAD DATA INFILE est la méthode la plus rapide pour charger des données massives. Le fichier doit être sur le serveur :

LOAD DATA INFILE '/tmp/clients.csv'
INTO TABLE clients
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 ROWS
(nom, email, equipe);

LOAD DATA LOCAL INFILE

LOAD DATA LOCAL INFILE lit le fichier depuis le client (votre machine). C'est plus pratique mais doit être autorisé côté serveur (local_infile=ON) et côté client (--local-infile=1). Pour les imports massifs en production, préférez LOAD DATA INFILE (sans LOCAL), les données ne transitent pas par le réseau.

SELECT INTO OUTFILE : export vers un fichier sur le serveur

C'est l'opération symétrique de LOAD DATA INFILE. Le fichier de destination ne doit pas exister : MySQL refuse d'écraser un fichier, ce qui évite d'effacer un export précédent mais impose de nettoyer avant de relancer la commande.

SELECT nom, email, equipe
INTO OUTFILE '/tmp/export_clients.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM clients;

Le fichier est créé sur le serveur avec les permissions de l'utilisateur MySQL (mysql). Pour ajouter un en-tête CSV, combinez avec UNION :

SELECT 'nom', 'email', 'equipe'
UNION ALL
SELECT nom, email, equipe
INTO OUTFILE '/tmp/export_clients_header.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM clients;

secure_file_priv et LOCAL INFILE

LOAD DATA INFILE et SELECT ... INTO OUTFILE sont soumis à secure_file_priv :

• si la variable contient un répertoire (défaut DEB/RPM : /var/lib/mysql-files), les fichiers doivent s'y trouver ;
• si elle est vide, il n'y a pas de restriction ;
• si elle vaut NULL, les opérations d'import/export de fichiers sont désactivées.

Vérifiez sa valeur :

SHOW VARIABLES LIKE 'secure_file_priv';

Pour LOAD DATA LOCAL INFILE, il faut en plus que le client et le serveur autorisent LOCAL (local_infile=ON côté serveur + --local-infile=1 côté client).

mysqlimport : import en ligne de commande

mysqlimport est un wrapper shell autour de LOAD DATA INFILE. Le nom du fichier doit correspondre au nom de la table :

mysqlimport -u root -p --local --fields-terminated-by=',' \
  --lines-terminated-by='\n' --ignore-lines=1 \
  labdb /tmp/clients.csv

mysqlimport retire l'extension du fichier et utilise le nom restant comme nom de table. Ici, /tmp/clients.csv → table clients de la base labdb.

mysqldump : export SQL complet

Pour exporter une base entière (structure + données) en SQL :

mysqldump -u root -p labdb > /tmp/labdb_backup.sql

Pour n'exporter que la structure (sans les données) :

mysqldump -u root -p --no-data labdb > /tmp/labdb_schema.sql

Pour exporter une seule table :

mysqldump -u root -p labdb clients > /tmp/clients_backup.sql

Le guide Sauvegarde et restauration explore en détail toutes les options de mysqldump.

MySQL Shell (mysqlsh) : l'alternative moderne

MySQL Shell est le client nouvelle génération fourni par Oracle. Il apporte des fonctionnalités absentes du client mysql classique :

Fonctionnalité	mysql (classique)	mysqlsh
Mode SQL	Oui	Oui
Mode JavaScript	Non	Oui
Mode Python	Non	Oui
Complétion avancée	Basique	Oui (tables, colonnes, fonctions)
Export parallèle	Non	util.dumpInstance() multi-thread
Import parallèle	Non	util.loadDump() multi-thread
AdminAPI (InnoDB Cluster)	Non	Oui
X Protocol	Non	Oui (port 33060)

Glissez pour voir

Pour l'installer :

sudo apt install mysql-shell    # Debian/Ubuntu
sudo dnf install mysql-shell    # RHEL/Rocky

Connexion en mode SQL :

mysqlsh --sql -u root -p -h localhost

Quand utiliser mysqlsh ?

Pour l'administration quotidienne (SHOW, SELECT, INSERT), le client mysql classique suffit amplement. MySQL Shell devient indispensable pour le dump/restore parallèle (beaucoup plus rapide que mysqldump sur les grosses bases), l'administration InnoDB Cluster et les scripts d'automatisation en Python/JavaScript.

Les utilitaires util.dumpInstance(), util.loadDump(), etc. sont disponibles en modes JavaScript et Python uniquement, pas en mode SQL.

Requêtes d'administration courantes

Voici les requêtes que vous taperez le plus souvent en exploitation : lire la configuration effective du serveur, voir qui est connecté, et mesurer l'espace occupé. Elles ne modifient rien et peuvent être exécutées en production sans précaution particulière.

Variables et statut

Ne confondez pas les deux notions : une variable est un paramètre de configuration, modifiable, alors qu'un statut est un compteur d'activité alimenté par le serveur. Le mot-clé GLOBAL porte sur l'instance entière, sans lui vous n'obtenez que les valeurs de votre propre session.

-- Voir une variable de configuration
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

-- Voir un compteur de statut
SHOW GLOBAL STATUS LIKE 'Threads_connected';

-- Plusieurs variables à la fois
SHOW VARIABLES WHERE Variable_name IN ('max_connections', 'wait_timeout', 'interactive_timeout');

Connexions actives

SHOW PROCESSLIST est le premier réflexe quand le serveur ralentit. La colonne Time donne la durée en secondes de l'état courant, et Info la requête en cours, tronquée à 100 caractères dans la forme courte.

SHOW PROCESSLIST;

+----+---------+-----------+-------+---------+------+----------+------------------+
| Id | User    | Host      | db    | Command | Time | State    | Info             |
+----+---------+-----------+-------+---------+------+----------+------------------+
| 12 | root    | localhost | labdb | Query   |    0 | starting | SHOW PROCESSLIST |
+----+---------+-----------+-------+---------+------+----------+------------------+

Pour une vue plus complète (requêtes longues, verrous) :

SHOW FULL PROCESSLIST\G

Espace disque par base

Cette requête additionne les données et les index de chaque base à partir du catalogue. Les valeurs sont estimées pour les tables InnoDB et n'incluent pas l'espace libéré mais non rendu au système, l'écart avec la taille réelle du répertoire de données est donc normal.

SELECT table_schema AS 'Base',
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Taille (Mo)',
       COUNT(*) AS 'Tables'
FROM information_schema.TABLES
GROUP BY table_schema
ORDER BY SUM(data_length + index_length) DESC;

Dépannage

Les messages ci-dessous sont ceux que vous rencontrerez le plus souvent avec le client. Retenez la logique des numéros : les erreurs 1xxx viennent du serveur (droits, objet inexistant), les erreurs 2xxx viennent du client, qui n'a pas réussi à établir la connexion.

Symptôme	Cause probable	Solution
ERROR 1045 (28000): Access denied for user 'root'@'localhost'	Mot de passe incorrect	Vérifier le mot de passe ou réinitialiser (voir guide Installation)
ERROR 2002 (HY000): Can't connect to local MySQL server through socket	Service MySQL non démarré ou socket absent	sudo systemctl start mysql
ERROR 2003 (HY000): Can't connect to MySQL server on 'host'	Connexion réseau refusée	Vérifier bind_address et le pare-feu
ERROR 1049 (42000): Unknown database 'xxx'	La base n'existe pas	SHOW DATABASES; pour lister les bases disponibles
ERROR 3948 (42000): Loading local data is disabled	local_infile désactivé	SET GLOBAL local_infile = ON; + reconnecter avec --local-infile=1
Le prompt affiche -> au lieu de mysql>	Requête non terminée (manque ;)	Tapez ; pour terminer ou \c pour annuler

Glissez pour voir

À retenir

• Le client mysql est l'outil d'administration quotidien, les commandes SHOW et INFORMATION_SCHEMA remplacent les méta-commandes de psql.
• La connexion locale passe par un socket Unix, pas besoin de réseau ni de mot de passe sur certaines configurations.
• mysql_config_editor stocke les identifiants chiffrés dans ~/.mylogin.cnf, préférez-le au mot de passe en clair dans ~/.my.cnf.
• Le mode vertical \G remplace le ; et rend les résultats larges lisibles.
• Le mode batch (-BNe) produit une sortie exploitable par les scripts shell, indispensable pour l'automatisation.
• Le DDL MySQL provoque un COMMIT implicite, pas de ROLLBACK possible après un CREATE TABLE ou un DROP TABLE. MySQL 8.4 supporte l'atomic DDL (un DDL échoué est entièrement annulé), mais ce n'est pas du DDL transactionnel à la PostgreSQL.
• LOAD DATA INFILE est la méthode la plus rapide pour les imports massifs. mysql_config_editor sécurise les identifiants pour les scripts automatisés.
• La base sys offre des vues simplifiées au-dessus de performance_schema, utilisez-la en premier pour le diagnostic.

Prochaines étapes

Configurer MySQL Régler InnoDB buffer pool, connexions, binary log et slow query log

Sécuriser MySQL caching_sha2_password, TLS, rôles et moindre privilège

Sauvegarde et restauration mysqldump, MySQL Shell, binary log PITR et XtraBackup

Monitoring et maintenance Performance Schema, sys, EXPLAIN, slow queries et OPTIMIZE TABLE

×

📖 Voir la documentation →