La FAQ MySQL - commentaires & suggestions

[yiannis]

La FAQ MySQL a subi un gros lifting : passage au format standard Développez.com, ajout de plus de 50 questions/réponses ; elle est désormais disponible à l'adresse : http://mysql.developpez.com/faq/.

J'ai également le plaisir de remplacer Florian en tant que responsable de la FAQ, contactez-moi pour toute question, suggestion, critique...
Les nouvelles Q/R ont été conçues à partir des questions fréquemment posées sur le forum ; nous espérons ainsi que cette FAQ répondra à vos problèmes les plus courants.

D'autre part n'hésitez pas à poster vos propositions de Questions avec les réponses dans cette enfilade, vous pourrez de cette manière contribuer à son évolution.

[Cordereve]

Excellentissime, ça fait une heure que je cherche une fonction de date.

Je viens de la trouver en 2 minutes...

Bravo et merci!

[star_light]

tres bonne faq qui convient aux debutants qu'aux personnes un peu plus expérimentées je constate avec joie que developpez.com est toujours une source sure pour les recherches

[le lynx]

Salut,


Je regarde cette faq pour la première fois.
J'y voit plein d'infos intéressantes.
J'y voit pas la réponse à mon problème: comment interfacer une appli ASP.NET avec MySQL, quel driver utiliser?
Une info qui pourrait intéresser pas mal de gens!

Philippe

[ren0]

Trés bonne FAQ, relativement complete.
Est-il prévu de rajouter des infos sur MaxDB ?

pour le lynx, il existe un driver ODBC pour MySQL qui te permet d'interfacer MySQL avec une appli .net. Tu peux le trouver ici.

[le lynx]

Oui, et il y a aussi cet article sur une connexion OLEDB
http://morpheus.developpez.com/MySQLDotNet/
A mon avis la FAQ devrait intégrer un pointeur vers ces 2 sources d'info.
Philippe

[Giovanny Temgoua]

Bonjour,

Bon je débute encore avec MYSQL et dans le cadre d'un TP, on doit l'utiliser (sous EasyPHP 1.6) et comme je cherchais comment utiliser les transactions, en fouillant l'aide j'ai touvé cette solution. Voilà si elle vous semble interessante....

Testé sous EasyPHP 1.6 qui utilise la version 3.23.49 de MySQL.

[QR]Utiliser les transactions sous MySQL 3.23.xxx

Le format par défaut des tables crées sous EasyPHP ne supporte pas les transactions (MyISAM). Il faut utiliser un format comme InnoDb qui n'est pas activé par défaut sous MySQL 3.23.xx, par exemple le serveur MySQL fournit avec EasyPHP 1.6 et en général pour les versions inférieures à la 4.1.

Avant toute chose, il convient de connaître les moteurs de stockage supportés par votre serveur. Utilisez la commande

Code :

SHOW STATUS

et regardé la valeur de la variable have_innodb. Si celle-ci vaut No, cà ne vaut pas peine de continuer, si c'est Yes, vous pouvez d'ores et déjà créer des tables de ce format. Le paragraphe qui suit traite du cas où vous aurez la valeur Disabled qui signifie que le serveur supporte cette fonctionnalité mais qu'elle n'est pas activée.

Il existe deux possibilités :
1/se procurer le serveur MySQL-MAX qui est une version de MySQLd compilée avec --with-innodb qui active le support de InnoDb
2/configurer le fichier my.ini situé dans <HOMEDRIVE>\Windows

Pour réaliser la seconde solution, il faut aller dans le fichier my.ini et effacer (si elle existe) la ligne --skip-innodb et la remplacer au moins par l'option innodb_data_file_path qui spécifie le chemin des bases Innodb. par défaut, le repertoire de base sera celui où mysql stocke les données. Sinon utilisez innodb_data_home_dir pour spécifier un repertoire.

Voilà, vous n'avez plus qu'à redémarrer le serveur et utilisez les instructions Begin (pour les versions de MySQL antérieures à la 4.0.11) ou Start transaction, commit pour valider les données et Rollback pour les annuler.

A+

[Maximilian]

FAQ mise à jour avec les Q/R de le lynx, ren0 et King Kaiser.

[Eric Berger]

Proposé par berceker united dans la rubrique PHP

Envoyé par berceker united

Un INSERT comme un UPDATE (Mysql) ?

Les insert sont de cette forme.

Code :

INSERT INTO ma_table (mes_champs) VALUES (mes_valeurs)

Mais vous pouvez le faire a la forme update

Code :

INSERT ma_table SET (mes_champs = mes valeurs)

Attention ceci est propre à Mysql et ne fait pas partie de la Norme SQL

[Giovanny Temgoua]

Moi ce que je voudrais savoir c'est l'avantage de cette méthode au insert traditionnel....

[Eric Berger]

certains trouveront peut-être plus lisible d'avoir des paires champ/valeur plutôt que d'avoir les champs puis les valeurs.... sinon personellement je n'y vois pas d'avantages.

[berceker united]

Il peut y avoir un petit avantage lorsqu'ont souhaite faire des requêtes dynamiquements.
D'un coté il y a la relation champs=valeur et en parametre c'est soit update ou insert pas la peine d'écrire deux fois champs et valeur. Ainsi c'est plus facile pour la maintenance tous est centralisé au même endroit.
Exemple :
$req = "champs1=1,champs2=3,champ3=556";

Code :

1
2
3
 
IF($id>0) mysql_query('UPDATE maTable SET'.$req.' WHERE id='.$i);
else mysql_query('INSERT maTable SET '.$req);

[Marco_SAP]

Bonjour,

Je me permet de vous recommander ce lien:
http://www.digilife.be/quickreferenc...ySQL-4.02a.pdf

Il s'agit des principales commandes Mysql sur une page recto-verso.

Marco

[guidav]

Voici une proposition pour la FAQ

Q :
Comment rendre le champ d'une table dépendante d'une autre (comment lier 2 tables) ?

R :
Pour pouvoir lier 2 champs, il faut d'abord que les 2 conditions suivantes soient réunies :
- les 2 champs doivent constituer la première colonne d'un index
- les 2 champs doivent avoir le même format. Inutile de chercher à lier un champ VARCHAR(10) avec un champ VARCHAR(15). Inutile aussi de chercher à lier deux champs dont l'interclassement est différent (et en plus, c'est une source d'erreur pas facile à trouver).

Selon le type de relation désiré, on peut décider ce qui arrive lorsque l'on effectue une action sur un enregistrement dans la table MERE :
- les actions envisagées sont DELETE et UPDATE
- les conséquences sur la table FILLE sont, pour chaque action : CASCADE (on efface/met à jour aussi la table FILLE), SET NULL (on met à NULL), NO ACTION (on ne fait rien) et RESTRICT (merci à quelqu'un de compléter, j'ignore ce que ça fait).

Ensuite, supposons 2 tables MERE et FILLE.
Pour que le champ NOM_FILLE de la table FILLE dépende du champ NOM_MERE de la table MERE, il faut effectuer la requête

Code :

1
2
ALTER TABLE `FILLE`
  ADD CONSTRAINT `FILLE_contrainte` FOREIGN KEY (`NOM_FILLE`) REFERENCES `MERE` (`NOM_MERE`) ON DELETE CASCADE ON UPDATE CASCADE

Pour plus de théorie sur les bases relationnelles, n'hésitez pas à lire les cours de www.developpez.com

[big_ben3333]

Encore une petite proposition :

J'avais chercher sur le forum et sur la faq comment réccupérer le dernier enregistrement inséré, et je n'ai pas trouvé ce que je cherchais...

Voici ma méthode, qui peux parfois être pratique dans certains cas, le mien est tordu, je dois l'admettre, mais elle peut être utile sur la faq :

J'ai une base de donnée qui contient une clée primaire de référence de livre.

Les enregistrements ne se suivent pas tous et il y a plusieurs catégories de livres.
certains ont leur référence qui est comprise entre 0 et 200000 d'autre entre 300000 et 400000. ect...

Ce n'est pas super, mais cela permet d'identifier rapidement la catégorie du livre selon la référence.

Il n'y a pas d'AUTO_INCREMENT dans ma table, car il faut parfois saisir des livres dans une catégorie, et parfois dans d'autres catégories.

Par défaut, sur une nouvelle fiche d'ouvrage, il est pratique d'avoir la derniere référence saisie incrémenté de 1.

Voici donc les deux requêtes qui permettent de réccupérer le réel dernier enregistrement :

SELECT COUNT(*) FROM `ma_table` WHERE 1;
SELECT mon_dernier_enregistrement FROM `ma_table` LIMIT le_resultat_precedant, 1;

Voila, ca peut toujours servir !

[goldkey]

J'ai été récemment confronté au douleureux probleme de perte du mot de passe ROOT !!

Voici le moyen de changer un mot de passe ROOT perdu:

# Arrêter le serveur MySQL en tapant :
/etc/rc.d/init.d/mysql stop

# Redémarrer le server avec les options ci-dessous:
/usr/bin/safe_mysqld —skip-grant-tables —skip-networking &

# Ce connecter au serveur mysql avec :
mysql mysql

# Taper la ligne suivante (ou ’nouveau_mot_passe’ est le nouveau mot de passe) :
UPDATE user SET password=PASSWORD(’nouveau_mot_passe’) WHERE User="root" AND Host="localhost" ;

# Eteindre le serveur MySQL
mysqladmin shutdown

# Redémarrer le serveur correctement avec :
/etc/rc.d/init.d/mysql start

[berceker united]

L'utilisation d'un limit sur une ou des tables ayant beaucoup d'enregistrements peut énormement plomber le serveur. Surtout si vous retourner des gros contenu avec beaucoup sur des petites intervale de page. Par exemple un forum qui retourne 30 enregistrements et le pire c'est l'ajout de l'ORDER BY qui ici achève le CPU mais qui est quasi obligatoire.

Pour optimiser les performances il faut deux requêtes.
La première requête utilise le LIMIT mais ne retourne que les index.

Code :

SELECT idtopic FROM forum ORDER BY date LIMIT 100,130;

De là, nous avons une suite d'index dans l'ordre.
Dans la second requête vous utilisez la fonction IN(...). IN permet d'insérer un suite de valeur que vous souhaiter retourner.

Code :

SELECT * FROM forum WHERE idtopic IN(100,101,102,103,...);

Sur des gros enregistrements vous sentirez la différence. J'en suis arrivé en faisant des test de volume. Arrivé à 100 000 enregistrements ça rame énormement avec le LIMIT intervale 30 + ORDER BY + champs TEXT et autres. Le temps d'affichage n'est pas acceptable pour le web. Venice 3200+ 1Go Mysql5 XP.

Avec cette méthode c'est totalement liquide.

[Alexandre T]

Excellente méthode berceker united !

Je viens de tester sur une base de données médiocrement modélisée et cela me donne de bons résultats. Par contre, sur une base correctement modélisé (taille d'enregistrement fixe, index ordonné), le gain est nul.

Néanmoins, je changerais les valeurs de votre second exemple. Certains débutants pourrait faussement comprendre qu'il faut remplacer

Code :

 SELECT *  FROM forum LIMIT 100,30

par

Code :

 SELECT * FROM forum WHERE id_topic IN (100, 101, 102, 103...., 128, 129, 130)

Donc je conseillerais ces exemples :

Code :

SELECT idtopic  FROM forum LIMIT 100,30

Code :

SELECT * FROM forum WHERE idtopic IN(100,106,108,110,...,166,170);

en précisant que la première requête à retourner 100,106,108,110,...,166,170

[Alexandre T]

big_ben3333, je ne pense pas que votre solution soit apportée à la FAQ. En effet, elle résulte plus à mon sens d'une réflexion pour contourner des problèmes créés par une base très mal modélisé.

Il existe des bases mal modélisé, et certaines astuces sont utiles, mais votre cas est assez particulier. De plus on peut planter votre méthode dans le cas d'utilisateurs réalisant des opérations simultanément ce qui est fréquent sur le web !

Exemple

Code :

1
2
3
4
12h00m44secondes 034ms - utilisateur 1 insère le livre 1
12h10m44secondes 080ms - utilisateur 1 insère le livre 2
12h15m14secondes 034ms - utilisateur 2 insère le livre 3
12h15m44secondes 041ms - utilisateur 1 insère le livre 4

45 millisecondes après l'insertion du livre 2 vous exécuter votre méthode pour récupérer la valeur du livre 3.
Si l'utilisateur 1 à inséré son livre 4 pendant cet intervalle de 45 millisecondes, votre algorithme retourne 4 et non 3 !
Et la méthode avec LAST_INSERT_ID, elle, permet d'éviter les accès concurrents.

Néanmoins, je vous remercie de votre aide et n'hésitez SURTOUT pas à nous conseiller d'autres questions-réponses

[berceker united]

Envoyé par Alexandre T

Excellente méthode berceker united !

Je viens de tester sur une base de données médiocrement modélisée et cela me donne de bons résultats. Par contre, sur une base correctement modélisé (taille d'enregistrement fixe, index ordonné), le gain est nul.

Néanmoins, je changerais les valeurs de votre second exemple. Certains débutants pourrait faussement comprendre qu'il faut remplacer

Code :

 SELECT *  FROM forum LIMIT 100,30

par

Code :

 SELECT * FROM forum WHERE id_topic IN (100, 101, 102, 103...., 128, 129, 130)

Donc je conseillerais ces exemples :

Code :

SELECT idtopic  FROM forum LIMIT 100,30

Code :

SELECT * FROM forum WHERE idtopic IN(100,106,108,110,...,166,170);

en précisant que la première requête à retourner 100,106,108,110,...,166,170

Oui je comprend que cela puisse préter à confusion avec "idtopic". J'ai fais des test sur une table ayant plus de 100 000 enregistrements avec des champs TEXT de gros volume, j'ai constaté qu'il y a un gain. Sur un autre forum j'ai vu que c'étais une méthode à conseiller sur les forum.
Il faut pas utiliser cette methode à toute les sauces.