Pour assurer l’intégrité référentielle entre 2 tables, on crée une clé étrangère. Actuellement avec MySQL, InnoDB et PBXT sont capables de gérer ces clés étrangères. Jusque là, rien de bien nouveau… Très souvent, on ajoute dans la définition de la clé étrangère l’instruction ON DELETE CASCADE ON UPDATE CASCADE de manière à ce qu’une mise à jour ou une suppression dans la table parente soit impactée dans la table enfant. Il existe pourtant d’autres actions, c’est ce que je vous propose de découvrir (ou de redécouvrir) dans cet article.
Archive pour la catégorie ‘MySQL’
Clés étrangères et actions de suppression/mise à jour
Mercredi 13 janvier 2010Comment réécrire une requête SQL ? Partie 2
Lundi 21 décembre 2009Dans le précédent post, nous avons optimisé une requête en abandonnant un des principes du SQL (dire au SGBD ce qu’on souhaite faire, mais pas comment le faire). Ici nous allons voir un exemple où le fait de penser en SQL va nous permettre de rendre performante une requête difficile à améliorer.
Comment réécrire une requête SQL ? Partie 1
Jeudi 26 novembre 2009Que faire quand une requête est lente ? Tout le monde vous dira qu’il faut commencer par regarder ce que dit EXPLAIN, puis ajouter ou modifier des index et s’il n’y a aucune amélioration, alors il faut essayer de réécrire la requête.
Déterminer quels sont les index à poser pour optimiser la requête est une tâche relativement simple avec un peu d’habitude, mais que peut bien signifier la notion de réécriture d’une requête ?
Bien souvent, cette notion se limite à triturer les conditions de la clause WHERE de manière à isoler une colonne pour qu’un index soit utilisé. Et pourtant, il y a bien d’autres choses à imaginer, ce que nous allons aborder dans cet article.
Conférences MySQL au Forum PHP
Mardi 20 octobre 2009Le MUG est partenaire du Forum PHP, qui se tient les 12 et 13 novembre 2009, à la Cité des Sciences et de l’Industrie.
Au programme des conférences dédiées à MySQL et MariaDB :
- mysqlnd / « MySQL native driver for PHP » : Les améliorations de la stack
- Au secours, ma base de données fait ramer mon application !
- LeMug : MariaDB, the future of MySQL avec Michael Widenius aka Monty
- Retour d’expérience sur l’utilisation de MySQL Chez Orange
- Réplication MySQL : retours d’expérience
Participez à cet événement et bénéficiez d’une offre exceptionnelle :
les deux journées du Forum PHP
+
l’adhésion 2009/2010 au MySQL User Group France
pour 140 euros au lieu de 200 euros!
InnoDB, verrouillage, transactions et index
Mercredi 30 septembre 2009Bin voyons, tout ça en un seul post ! On se rapproche doucement de Noël, mais quand même !
Je m’explique…
Je me suis intéressé récemment aux instructions SELECT … LOCK IN SHARE MODE et SELECT … FOR UPDATE, qui sont censées permettre de verrouiller explicitement des lignes pour les tables InnoDB.
On comprend maintenant les deux premiers termes du titre 
Securich – Darren Cassar
Dimanche 23 août 2009Darren s’est occupé récemment d’une migration de Sybase vers MySQL. Et il s’est aperçu à cette occasion que la gestion des utilisateurs sous MySQL n’est pas sans défaut. Par exemple, il n’est pas possible de créer des rôles, il n’est pas possible de donner à un utilisateur des droits sur toutes les tables sauf une, il n’est pas possible de connaître le degré de complexité d’un mot de passe…
Pour essayer de pallier à tous ces défauts, Darren a créé un outil : Securich, installable sur tout serveur MySQL 5.1. Cet outil permet, à l’aide d’appels à des procédures stockées, de manipuler les utilisateurs et leurs droits. Attention tout de même, le développement de Securich a commencé il y a peu de temps et le code est encore expérimental. Il reste pas mal de fonctionnalités que Darren voudrait implémenter et quelques bugs gênants : par exemple, si vous installez Securich sur un serveur contenant des utilisateurs, Securich va effacer tous les utilisateurs sans vous en avertir…
L’initiative est en tout cas intéressante car il reste effectivement pas mal de travail pour que MySQL présente autant de fonctionnalités sur les utilisateurs et les droits que d’autres produits.
MySQL Sandbox 3 – Giuseppe Maxia
Dimanche 23 août 2009Nous avons tous régulièrement besoin de monter rapidement un ou plusieurs serveurs MySQL pour tester telle ou telle fonctionnalité. Et évidemment, c’est toujours quand on veut aller vite qu’on fait des erreurs et qu’on se retrouve avec des serveurs qui ne démarrent pas. MySQL Sandbox a été créée pour nous aider dans cette situation. Giuseppe s’est en effet trouvé de nombreuses fois dans la situation où il perdait énormément de temps à monter des environnements jetables et il a imaginé un script permettant d’automatiser cette création d’environnements jetables.
Sans entrer dans le détail des commandes (voir pour cela la page sur Launchpad), MySQL Sandbox permet de créer en une ligne de commande des environnements complets et variés : un serveur, plusieurs serveurs indépendants, un maître-plusieurs esclaves…Il est même possible de créer, toujours en une seule ligne, une réplication circulaire entre N serveurs ! Le script permet également de démarrer, arrêter, effacer chacun des serveurs ainsi créés ou de faire une opération pour tous les serveurs à la fois.
Ca faisait un moment que je voulais prendre un peu de temps pour voir ce qu’il était possible de faire avec MySQL Sandbox, maintenant c’est sûr : je vais m’y mettre !
A voir également sur le sujet : un précédent article d’Arnaud, sur dbnewz bien sûr !
A better MySQLTuner – Sheeri K. Cabral
Samedi 22 août 2009MySQLTuner est un script Perl qui produit un rapport sur la configuration de votre serveur MySQL et donne des pistes d’optimisation. On peut bien sûr s’interroger sur la manière dont l’analyse est faite et surtout sur la pertinence des recommendations. C’est exactement l’exercice qu’a fait Sheeri pour nous, en examinant le script sur toutes ses coutures.
Il en ressort que pas mal d’affirmations et de recommendations sont hardcodées et ne tiennent absolument pas compte des spécificités de votre base. Un exemple ? Si le cache de requêtes est désactivé, alors le script va systématiquement vous remonter qu’il s’agit d’un problème, même si vous avez sciemment désactivé ce cache.
A partir de toutes ces constatations, Sheeri a commencé à faire évoluer le script, en ajoutant pour l’instant quelques options intéressantes, comme celle permettant de formater le rapport de manière à le rendre facilement lisible par un tableur : il devient ainsi plus facile de voir l’évolution de certains indicateurs dans le temps en lançant le script à intervalles réguliers. A suivre !
OpenSQLCamp : Sharding for the masses
Samedi 22 août 2009Ce week-end a lieu à côté de Bonn l’OpenSQLCamp, en parallèle de la FrOSCon. Giuseppe Maxia nous parle aujourd’hui d’une technique utilisée dans certaines applications à fort trafic : le sharding. Mais à quoi sert le sharding ?
Quand on commence une application, un seul serveur SQL suffit généralement à absorber la charge. Si le trafic augmente et que les performances du serveur commencent à s’écrouler, on peut utiliser la réplication. Mais la réplication ne permet que d’augmenter le nombre de lectures possibles (read scaling) et pas le nombre d’écritures (write scaling). Cette limitation provient du fonctionnement même de la réplication car toutes les écritures doivent arriver sur le serveur maître. On peut alors imaginer de séparer les données selon certaines règles (dépendantes de l’application) de manière à avoir plusieurs masters sur lesquels on peut utiliser la réplication. Et voilà, nous venons d’inventer le sharding.
Giuseppe nous explique que le sharding est simple à mettre en place : il suffit de créer des règles permettant de dispatcher les données entre les différents masters. Malheureusement, le sharding est fragile : si, par exemple, vous changez les règles de dispatch, vous risquez de casser vos shards ! Pour simplifier le sharding, il existe un moteur de stockage récent, installable en tant que plugin pour MySQL 5.1 : Spider. Spider est basé sur le partitionnement et permet de créer des tables sur un serveur dont les données seront stockées sur des hosts distants. En gros, on utilise une pincée de partitionnement et une pincée de Federated…
Les démonstrations faites par Giuseppe montrent quand même que si Spider peut nous simplifier la tâche du sharding, la mise en place de tables avec Spider n’est pas si simple et demande un peu de doigté et de réflexion…
Désactiver les clés étrangères
Mercredi 15 juillet 2009Une petite « astuce » pour se remettre dans le bain du blogging… Comme vous avez pu le constater la fréquence de mise à jour a un peu diminuée depuis notre retour de la MySQL Conf, corrigeons cela avec cette petite remise en jambe à classer dans la catégorie « pratique ».
La désactivation du contrôle des clés étrangères est intéressante lorsque vous devez exécuter sur votre serveur MySQL un script de création de tables par exemple. Il se peut dans ce cas que l’ordre de création des différentes tables ne soit pas « logique ».
J’entends par là qu’une table A peut contenir une contrainte basée sur une clé étrangère référençant le champ d’une table B… qui n’existe pas encore ! La « logique » voudrait que les tables soient inscrites dans le script selon les liens qui existent entre elles mais cela n’est pas toujours le cas.
Cette opération de classement pouvant s’avérer fastidieuse à effectuer manuellement, vous pouvez vous affranchir des vérifications effectuées par le SGBD concernant les clés étrangères en utilisant la commande suivante :
mysql> SET foreign_key_checks = 0;
Vous êtes ainsi tranquille le temps de créer vos tables. Réactiver ce contrôle n’est pas plus compliqué :
mysql> SET foreign_key_checks = 1;
Le chapitre de la documentation correspondant aux foreign keys nous indique que c’est d’ailleurs la technique employée par mysqldump.