dbnewz

Déjà trois semaines d’écoulées depuis que certains d’entre vous, les “héros”, ont posé leurs questions (oui il est possible de devenir un héros rien qu’en lisant dbnewz ! Les véritables héros sont d’ailleurs abonnés au tout nouveau flux feedburner )

Trois semaines d’attente, cela mérite un billet digne de ce nom, c’est parti.

Indexer, pourquoi ?

L’indexation peut avoir plusieurs buts :
- Accéder à ses données plus rapidement, les index sont en effet l’outil le plus puissant pour accélérer les temps d’exécution de vos requêtes jusqu’à parfois plusieurs centaines de % !
- Définir le degré d’unicité d’une colonne donnée : chaque champ doit-il être unique ? les doublons sont-ils autorisés ?

Principe de fonctionnement

Lorsque vous envoyez une requête à votre serveur MySQL, celle-ci est d’abord confiée au “parseur” SQL qui a pour but de vérifier si la syntaxe de votre demande est correcte. Cette étape franchie, la requête passe par “l’optimiseur”. Il s’agit ici de déterminer le plan d’exécution de la requête afin que celle-ci s’exécute le plus rapidement possible.

L’optimiseur détecte si d’éventuels index sont disponibles, si c’est le cas il décidera de s’en servir… ou pas : il est parfois plus rapide de ne pas se servir d’un index ! Nous verrons pourquoi au cours de cette série d’articles.

Une fois le plan d’exécution achevé, c’est le moteur de stockage qui prend le relais, celui-ci peut être vu comme un “module” de MySQL :

(more…)

Disposer d’un MCD (modèle conceptuel de données) lorsqu’on travaille sur une requête SQL impliquant différentes tables représente un gain de temps.
Il est en effet plus rapide de jeter un coup d’oeil sur un MCD afin de repérer quels sont les champs qui lient une table à une autre plutôt que d’enchaîner les “DESC ma_table”, puis repérer la clé primaire et les éventuelles clés étrangères, et rebolote sur la ou les tables de destination…

La prochaine série d’articles sur les index MySQL va nous amener à enchaîner quelques requêtes sur une des deux bases d’exemple disponibles sur le site de MySQL : world et sakila, le prétexte est donc tout trouvé pour évoquer ici la solution que j’ai retenu pour obtenir le MCD de ces tables : DBDesigner 4.

Cet outil n’est pas nouveau, son successeur officiel est même déjà connu, il s’agit de MySQL Workbench. Celui-ci n’étant pas encore disponible sous linux, nous utiliserons son ancêtre et plus particulièrement sa fonctionnalité de “reverse engineering” : une fois connecté à votre base, DBDesigner 4 va générer sous forme graphique vos tables, leurs descriptions, et si tout se passe bien, les relations entre vos tables.

(more…)

Un titre sans doute bien étrange pour certains et qui rappelera des souvenirs à d’autres, surtout à ceux qui ont déjà parcouru un de ces livres “dont vous êtes le héros“…

Afin que les choses soient claires pour tout le monde, je vous propose en fait de participer à la conception du sommaire de la future série d’articles sur les index qui sera publiée prochainement sur dbnewz.

L’indexation est en effet un thème auquel il faut absolument s’intéresser, tout d’abord pour éviter des catastrophes et bien sûr pour optimiser les performances !

(more…)

Voici mon problème du jour : Comment lancer un script (de maintenance par exemple) qui fait appel à mysql, sans stocker en dur le nom de l’utilisateur et le mot de passe (ce qui est mal, très très mal). Le but est que seul un utilisateur privilégié (je n’ai pas forcément dit root ! je pense plutôt à un compte système comme mysql par exemple) puisse lancer ce script.

C’est plutôt facile, et je fournis trois solutions pour la peine :

1. Avoir un fichier de configuration pour le script accessible seulement par l’utilisateur privilégiéOn définit dans le fichier de configuration des variables d’environnement, une pour le user, une autre pour le mot de passe. Dans le script il ne reste qu’à utiliser la commande source pour récuperer ses variables (seul l’utilisateur privilégié pourra lire le fichier). Simple et efficace.
2. Avoir un fichier de configuration pour mysql accessible seulement par l’utilisateur privilégiéVariante de la précédente : on crée un fichier de configuration spécifique pour mysql (que l’on pourra mettre par exemple dans /etc/mysql mais il n’y a aucune obligation). Et on utilise l’option –defaults-file pour que mysql lise le contenu du fichier (il lit notamment les sections [client] et [mysql]). Exemple de fichier:
   
[client]
host = localhost
user = votre_user
password = votre_mot_de_passe
socket = /var/run/mysqld/mysqld.sock

   Bonus : on peut spécifier d’autres options pour influer sur mysql (en vrac, le nom de serveur, le jeu de caractères…).
3. Pour ceux qui ont plusieurs scripts mais qui ont des options qui diffèrent légèrementVous avez des scripts quasiment identiques mais les options diffèrent légèrement (ou vous voulez centraliser tout en un seul fichier) : c’est possible. C’est une variante du cas précedent : on écrit un fichier de configuration mysql que l’on découpe en plusieurs sections. Ensuite, on fait appel au programme my_print_defaults ! my_print_defaults examine le fichier de configuration (option -c pour spécifier le votre…) et donne en sortie les paramètres à passer à mysql sous forme d’argument. Exemple :
   
$ my_print_defaults -c /etc/mysql/maconf.cnf client
--host=localhost
--user=votre_user
--password=votre_mot_de_passe
--socket=/var/run/mysqld/mysqld.sock

   Il ne reste plus qu’à passer cela à mysql en récuperant la sortie dans une variable (ou en utilisant cette petite merveille de xargs).