Naviguer dans les bases de données : Utilisation pratique des commandes USE et DESCRIBE

USE et DESCRIBE sont de petites commandes MySQL, mais elles font gagner un temps précieux lorsque vous travaillez dans un shell, déboguez la base de données de quelqu'un d'autre ou vérifiez un schéma avant d'écrire une requête. Elles évitent également une erreur très courante : exécuter la bonne requête SQL sur la mauvaise base de données.

Si vous passez la majeure partie de votre journée dans un framework applicatif, il est facile d'oublier à quel point le client MySQL peut être utile. Vous vous connectez, regardez autour de vous, inspectez une table et répondez à une question en une minute. L'astuce est de procéder avec précaution. Les bases de données de production contiennent souvent des schémas aux noms similaires, des anciennes tables, des reliquats de staging et des colonnes dont la signification n'est pas exactement celle suggérée par leur nom.

Ce que `USE` change réellement

L'instruction MySQL USE définit la base de données par défaut pour la session en cours. Après l'avoir exécutée, les noms de tables non qualifiés sont résolus dans cette base de données.

USE ecommerce_db;

À partir de ce moment, cette requête :

SELECT id, email FROM customers LIMIT 5;

signifie :

SELECT id, email FROM ecommerce_db.customers LIMIT 5;

Le paramètre est spécifique à la session. Si vous ouvrez un autre terminal, un autre onglet de client de base de données ou vous reconnectez après un délai d'attente, vous devez sélectionner à nouveau la base de données. La documentation de MySQL elle-même décrit USE comme le choix de la base de données nommée comme base de données courante par défaut pour les instructions suivantes, ce qui correspond exactement à la façon dont vous devez le concevoir.

Avant de changer, listez ce qui existe :

SHOW DATABASES;

Sélectionnez ensuite la cible :

USE ecommerce_db;

Confirmez où vous êtes :

SELECT DATABASE();

Cette dernière vérification vaut les frappes supplémentaires avant toute commande destructive. J'ai vu des gens garder trois terminaux ouverts, tous avec des invites similaires, puis exécuter un DELETE rapide dans le mauvais. Un plugin d'invite peut aider, mais SELECT DATABASE(); reste la vérification de vérité la plus simple.

Quand qualifier les noms de tables à la place

USE est pratique, mais ce n'est pas toujours l'option la plus claire. Si vous comparez deux bases de données, les noms complets sont plus sûrs :

SELECT COUNT(*) FROM production.users;
SELECT COUNT(*) FROM staging.users;

Cela supprime toute ambiguïté. Cela rend également les notes collées plus faciles à comprendre plus tard car le nom de la base de données est dans la requête elle-même.

Pour les migrations et les scripts de maintenance ponctuels, je préfère les noms qualifiés pour tout ce qui est risqué. Pour l'inspection interactive, USE convient tant que vous continuez à vérifier le contexte.

La sensibilité à la casse des noms de base de données peut varier selon le système d'exploitation et la configuration MySQL. Le comportement des noms de tables peut également varier. Ne comptez pas sur la portabilité des noms en casse mixte. Si votre équipe utilise des noms de schéma et de table en minuscules partout, continuez à suivre cette convention.

Ce que `DESCRIBE` vous montre

DESCRIBE, souvent abrégé en DESC, affiche la structure de la table. Dans le travail quotidien avec MySQL, il répond à des questions comme :

Quel est le nom exact de la colonne ?
Ce champ est-il nullable ?
Quel type de données cette table utilise-t-elle réellement ?
Y a-t-il une clé primaire ?
La colonne s'incrémente-t-elle automatiquement ?
Quelle valeur par défaut une insertion obtiendra-t-elle ?

Utilisez-le comme ceci :

DESCRIBE customers;

ou :

DESC customers;

Un résultat typique ressemble à ceci :

+-------------+------------------+------+-----+---------+----------------+
| Field       | Type             | Null | Key | Default | Extra          |
+-------------+------------------+------+-----+---------+----------------+
| id          | bigint unsigned  | NO   | PRI | NULL    | auto_increment |
| email       | varchar(255)     | NO   | UNI | NULL    |                |
| name        | varchar(120)     | YES  |     | NULL    |                |
| created_at  | datetime         | NO   |     | NULL    |                |
+-------------+------------------+------+-----+---------+----------------+

La colonne Key est un indice rapide, pas un rapport d'index complet. PRI signifie clé primaire. UNI signifie que la colonne fait partie d'un index unique. MUL signifie généralement que la colonne est indexée mais peut contenir des valeurs répétées. Si vous avez besoin d'un détail complet sur les index, utilisez plutôt SHOW INDEX FROM customers;.

L'analyseur MySQL traite DESCRIBE et EXPLAIN comme des synonymes dans certains contextes. En pratique, les gens disent généralement DESCRIBE table_name lorsqu'ils veulent la structure de la table et EXPLAIN SELECT ... lorsqu'ils veulent un plan d'exécution de requête.

Un flux de travail d'inspection réaliste

Imaginez que vous déboguez un travail de validation de commande qui a échoué. Les logs de l'application indiquent Unknown column 'payment_status', mais vous n'êtes pas sûr de la base de données utilisée par le worker.

Commencez par vous connecter en lecture seule si possible :

mysql -u readonly_user -p -h db.example.internal

Recherchez les bases de données probables :

SHOW DATABASES;

Sélectionnez celle que l'application devrait utiliser :

USE shop_production;
SELECT DATABASE();

Listez les tables si vous ne connaissez pas le nom exact :

SHOW TABLES LIKE '%order%';

Inspectez la table :

DESCRIBE orders;

Peut-être trouvez-vous payment_state, pas payment_status. Ou peut-être que la colonne existe dans staging mais pas en production. Cela vous indique si le bogue est un décalage code/config, une migration manquée, ou simplement la mauvaise connexion à la base de données.

Avant d'écrire un INSERT, DESCRIBE est également utile :

DESC products;

Si sku est NOT NULL, price est decimal(10,2), et created_at n'a pas de valeur par défaut, votre insertion doit inclure ces champs :

INSERT INTO products (sku, name, price, created_at)
VALUES ('MOUSE-USB-01', 'USB mouse', 19.99, NOW());

C'est bien mieux que de deviner, d'échouer, puis de lire un long message d'erreur.

Utilisez `SHOW CREATE TABLE` quand `DESCRIBE` ne suffit pas

DESCRIBE est rapide, mais il cache des détails importants. Il n'affiche pas clairement les clés étrangères, les expressions de colonnes générées, les définitions d'index complètes, le partitionnement, les commentaires ou les options de table. Lorsque vous avez besoin de la vraie définition de table, exécutez :

SHOW CREATE TABLE orders\G

Le format de sortie \G est plus facile à lire pour les résultats larges dans le client MySQL. Cette commande est particulièrement utile avant de modifier une table car elle montre le DDL exact que MySQL connaît.

Par exemple, DESCRIBE peut montrer que customer_id a MUL dans la colonne Key. SHOW CREATE TABLE peut vous dire si l'index est uniquement sur customer_id ou fait partie d'un index composite comme (customer_id, created_at). Cette différence est importante pour les performances et pour décider si un nouvel index est réellement nécessaire.

Erreurs courantes avec `USE` et `DESCRIBE`

La première erreur est de supposer que USE change quoi que ce soit en dehors de votre session. Ce n'est pas le cas. Votre application, un autre terminal et la connexion d'un autre utilisateur conservent leur propre contexte.

La deuxième erreur est d'oublier que les noms de tables peuvent être qualifiés. Si vous exécutez :

USE staging;
SELECT * FROM production.users LIMIT 5;

MySQL lit depuis production.users, pas staging.users, car la requête nomme explicitement la base de données. C'est utile quand c'est intentionnel et dangereux quand c'est collé négligemment.

La troisième erreur est de traiter DESCRIBE comme une vérification de qualité des données. Il indique la forme, pas le contenu. Une colonne peut être nullable même si l'application ne s'attend jamais à des valeurs nulles. Un champ varchar(255) peut contenir des chaînes vides. Une colonne de prix decimal peut contenir d'anciennes valeurs importées avec des arrondis étranges. Utilisez DESCRIBE pour comprendre le schéma, puis échantillonnez les données séparément :

SELECT payment_state, COUNT(*)
FROM orders
GROUP BY payment_state
ORDER BY COUNT(*) DESC;

La quatrième erreur est d'exécuter des instructions d'écriture dans une session où vous n'avez pas confirmé la base de données. Prenez l'habitude : SELECT DATABASE();, inspectez, puis écrivez.

Une habitude plus sûre pour le travail quotidien avec MySQL

Lorsque j'ouvre un shell MySQL sur un environnement partagé, je suis un rythme court :

SHOW DATABASES;
USE target_database;
SELECT DATABASE();
SHOW TABLES;
DESCRIBE important_table;

Pour tout ce qui est risqué, j'ajoute :

START TRANSACTION;
-- inspecter ou modifier un petit nombre de lignes
ROLLBACK;

Ensuite, je réexécute la modification prévue seulement quand je suis sûr. Ce modèle de transaction ne convient pas à chaque instruction DDL ou comportement de moteur, mais pour de nombreuses vérifications de données, il vous donne une chance de vérifier votre clause WHERE avant de valider.

USE et DESCRIBE ne sont pas des commandes avancées, et c'est le but. Elles vous donnent une orientation. USE indique à MySQL où les noms de tables non qualifiés doivent pointer. DESCRIBE vous indique à quoi ressemble une table avant de l'interroger ou de la modifier. Utilisées ensemble, elles rendent le travail interactif avec la base de données plus calme, plus rapide et moins sujet aux erreurs.

Naviguer dans les bases de données : Utilisation pratique des commandes USE et DESCRIBE

Ce que USE change réellement