FAQ MySQLConsultez toutes les FAQ
Nombre d'auteurs : 15, nombre de questions : 155, dernière mise à jour : 22 avril 2014 Ajouter une question
Cette FAQ a été conçue à partir des questions fréquemment posées sur le forum MySQL de Developpez.com. Elle ne prétend pas à être exhaustive et peut contenir des erreurs occasionnelles. Si vous relevez une coquille, n'hésitez pas à nous le faire savoir.
Pour participer à cette FAQ, veuillez envoyer vos réponses sur le forum.
- Quels sont les types de variables de MySQL ?
- Quelle est la différence entre une variable GLOBAL et une variable SESSION ?
- Quelle est la syntaxe de SET ?
- Comment retrouver une variable système dont on ignore le nom exact ?
- Que sont les commandes préparées (prepared statements) ?
- Peut-on rendre variable un nom de table, de colonne, d'utilisateur ?
MySQL dispose de 3 types de variables :
- locale (à l'intérieur d'une routine, créée et typée avec DECLARE, sans @) ;
- utilisateur (valable pour la session, non déclarée, non typée, préfixée par @) ;
- système (portée globale ou session, pré-définie, préfixée par @@).
MySQL utilise une série de variables système, pré-définies.
Les valeurs de ces variables sont lues dans le fichier my.ini au démarrage du serveur ; elles sont alors affectées aux variables avec une portée globale.
Lorsqu'un utilisateur ouvre une session, les variables globales sont copiées sur des variables de même nom, mais dont la portée est limitée à la session.
Ce sont ces copies qui seront utilisées durant toute la session.
Nous pouvons donc considérer les variable globales comme des valeurs par défaut.
Vous pouvez modifier la valeur d'une variable système de trois façons :
mode de modif. | début d'effet | portée | fin d'effet | privilèges nécessaires |
dans le fichier my.ini | prochain redémarrage | toutes sessions | définitif | accès au fichier my.ini |
SET GLOBAL | prochaine ouverture de session | futures sessions | arrêt du serveur | SUPER |
SET LOCAL | immédiat | session en cours | fermeture de la session | aucun |
Le mode SET GLOBAL est assez trompeur :
- il ne s'applique pas à la session en cours ;
- il sera oublié au prochain arrêt du serveur ;
- il nécessite le privilège d'administration SUPER.
Parmi les variables système les plus couramment utilisées, on trouve notamment @@autocommit, @@sql_mode, @@tx_isolation, @@foreign_key_checks, etc.
Pour une variable locale (dans une routine) :
Code sql : | Sélectionner tout |
1 2 | DECLARE a INT ; SET a = 5 ; |
Code sql : | Sélectionner tout |
SET @a = 5 ;
Code sql : | Sélectionner tout |
1 2 3 4 5 | SET SESSION div_precision_increment = 9 ; SET div_precision_increment = 9 ; -- identique à SET SESSION SET @@div_precision_increment = 9 ; -- identique à SET SESSION SET GLOBAL div_precision_increment = 9 ; |
A l'aide de l'instruction suivante :
Code sql : | Sélectionner tout |
SHOW VARIABLES LIKE ...
Les commandes préparées (prepared statements) sont des requêtes, pouvant inclure des paramètres variables, qui sont préparées (compilées) sur le serveur avant exécution. Ce système offre deux avantages :
- meilleure performance : si la requête est exécutée plusieurs fois avec simplement un changement de valeur des paramètres, elles ne seront compilées qu'une fois ;
- meilleure sécurité : les valeurs des paramètres sont cadrées par le système, ce qui évite le risque des injections SQL.
L'API MySQLi (utilisable notamment dans PHP 5) permet d'utiliser ce système avec la fonction mysqli_prepare.
MySQL dispose également d'une syntaxe interne à son SQL avec les ordres PREPARE et EXECUTE (cf documentation MySQL).
Code sql : | Sélectionner tout |
1 2 3 4 5 6 7 | prepare mon_statement FROM 'insert into personnes(nom, prenom) values (?, ?) ; ' ; SET @n = 'Dinimant' ; SET @p = 'Antoine' ; execute mon_statement USING @n, @p ; deallocate prepare mon_statement ; |
Il est également possible de préparer un statement d'après une variable utilisateur, ce qui ouvre des possibilités comparables au SQL dynamique d'Oracle ou au EXEC @SQL de SQL Server (voir cette question).
Les commandes préparées sont utilisables dans des procédures stockées, mais pas dans des fonctions ni dans des triggers.
En théorie, c'est impossible. Seules les données peuvent être variables. Toutefois, les commandes préparées permettent de contourner cette limite :
Code sql : | Sélectionner tout |
1 2 3 4 5 6 7 | SET @u = 'toto' ; SET @p = 'passepartout' ; SET @sql = CONCAT('CREATE USER ', @u, '@localhost IDENTIFIED BY ''', @p, ''' ;') ; prepare mon_statement FROM @sql ; execute mon_statement ; deallocate prepare mon_statement ; |
Proposer une nouvelle réponse sur la FAQ
Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour çaLes sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2024 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.