La gestion des IP dans MySQL est très simple. Premièrement, il faut savoir que la manière la plus efficace de stocker un IP et de le représenté sous une forme numérique, soit un INT UNSIGNED (donc 4 bytes) plutot qu’un CHAR(15) de 15 bytes.

Il demeure malgré tout possible de manipuler les IP avec leur forme alphanumérique en utilisant 2 function de MySQL: INET_ATON() et INET_NTOA().

mysql> SELECT INET_ATON('192.168.20.76');
+----------------------------+
| INET_ATON('192.168.20.76') |
+----------------------------+
|                 3232240716 |
+----------------------------+

mysql> SELECT INET_NTOA(3232240716);
+-----------------------+
| INET_NTOA(3232240716) |
+-----------------------+
| 192.168.20.76         |
+-----------------------+

Si vous avez voulez savoir si un IP fait parti d’un sous reseaux, vous pouvez faire des manipulations bitwise:

SET @myIP := INET_ATON('192.168.20.76');
SET @theNetMask = …

Je dois régulièrement créer des rapports pour la comptabilité (et d’autres gens moins à l’aise avec des ordinateurs) au boulot. Le moyen facile est de leur envoyer le tout dans un fichier CSV converti en excel par email.

Il y a plusieurs manières de créer un CSV à partir de MySQL. Voici la manière que je qualifie de “standard”:

1. SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
2. FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
3. LINES TERMINATED BY '\n'
4. FROM test_table;

Une manière un peu plus rapide (trouvé en fouillant sur google):

1. mysql -umyUser-p dbName -B -e "SELECT a,b,a+b FROM test_table;" | sed 's/\t/","/g;s/^/"/;s/$/"/;s/\n//g' > filename.csv

Et maintenant.. (roulement de tambour).. “MA” manière!

1. CREATE TABLE test_table_csv SELECT a,b,a+b FROM test_table; ALTER test_table_csv ENGINE = csv; …

Pour plusieurs apprentis en développement Web, MySQL se résume qu’à phpMyAdmin. Plusieurs personnes ne savent pas qu’il existe un client en command line qui s’appelle tout simplement mysql. Pourtant, c’est un client hyper performant et très polyvalent que je recommande à tous.

Sa syntaxe est très simple. Pour se connecter:

1. prompt> mysql -h youdomaine.com -u login -p

On indique ensuite la base de données qu’on souhaite utiliser et hop, on est prêt à exécuter des requêtes:

1. mysql> USE myDatabaseName;

Plutôt simple n’est-ce pas ? Maintenant que vous connaissez le strict minimum pour l’utiliser, voici quelques trucs et astuces que même ceux qui l’utilisent ne savent pas toujours.

Les raccourcis les plus pratiques

\c  - Annule une requête

Lorsqu’on fait une erreur dans une requête, on peut …

Je ne sais pas si je suis le seul à penser ça, mais je trouve qu’il y a peu de ressources (ou alors, je ne les connais pas) distribuant des exemples de procédures stockées, de fonctions, de triggers ou d’events scheduler. Pour pallier ce manque, je viens de publier une page avec le code d’un Event.

Je compte faire une page (et non un post, pour pas que ça tombe archiver avec le temps) avec des exemples de chaque type de routine, avec leurs particularités. Mon Event est donc le premier exemple d’une petite série à venir. Je n’explique pas en détail chaque ligne; je montre les possibilités et j’invite les gens intéressés à consulter la documentation pour mieux apprendre sur chaques features.

Mon exemple se trouve donc ici : http://www.noidea.ca/mysql-event-scheduler/

Un gars sur IRC me demandait l’autre jour quel était “Le book” de MySQL. Il n’est évidemment pas possible de devenir expert en la matière avec un seul livre. Après quelques échanges, j’ai vite compris qu’il cherchait à améliorer l’utilisation qu’il en fait en tant que développeur d’application Web.

Je n’ai pas eu l’occasion (comprendre le temps) de lire des milliers de livres. Par contre dans ceux que je connais, je lui ai suggéré deux qui répondront bien à ce qu’il veut: MySQL 5.0 Certification Study Guide et MySQL Stored Procedure Programming.

Le Certification Study Guide se divise en deux parties distinctes: la …

Aujourd’hui, je vais expliquer comment tirer avantage des index avec certains types de requête.
Nous avons une table client avec un monstrueux index nommé “nom” que voici: nom, prenom, entreprise, telephone. Nous avons un champ de recherche dans une page Web qui nous permet de trouver un client à partir de son prénom ou son nom.

On veut trouver une personne qui a le nom “Phil”:
SELECT SQL_NO_CACHE * FROM client
WHERE groupe = 1
AND ( nom LIKE 'phil%' OR prenom LIKE 'phil%')
---
(490 total, Query took 0.4523 sec)
(490 total, Query took 0.4511 sec)
(490 total, Query took 0.4879 sec)
(490 total, Query took 0.4455 sec)


Dans cette requête, aucun index n’est utilisé. À cause de la condition OR, l’optimiseur estime qu’il est plus efficace de faire un table scan que d’utiliser l’index nom, même si celui-ci possède les champs …

Une des choses à laquelle il faut faire spécialement attention sont les warnings. MySQL est une base de données très permissive et beaucoup d’opérations réussies le sont grâce à la souplesse qu’il permet. J’ai vu des bases de données rouler pendant plusieurs jours, voir années, avec des erreurs sans que personne ne s’en rende compte.

Pourquoi je déteste “show warnings”? Parce que c’est un feature qui manque d’utilité. La documentation qui y fait référence est aussi défaillante. Elle n’indique même pas que le statement est par connexion. C’est un gros manque à mon avis. Si une base de données est exclusivement utilisée via une application, les requêtes sont toujours les mêmes. Pour un DBA en charge de s’assurer que tout fonctionne bien, il faudrait être capable d’obtenir ces warnings.

Je travaillais récemment sur un serveur, connecté avec le client command line. J’effectuais ce que …

On a parfois la mauvaise habitude de faire des SELECT * FROM table; Mon astuce de la semaine va tenter d’expliquer pourquoi il faudrait toujours énumérer les champs qu’on veut sélectionner, même s’il s’agit de la table au complet.

Il y a 3 raisons majeures pour lesquelles il ne faudrait JAMAIS faire de SELECT * FROM dans les requêtes d’une application:

• La description de la table par le biais de la requête est perdue
• Les changements de champs
• La grosseur des champs

Description de la table

Les Q.A vont être d’accord avec moi là-dessus, il n’y a rien de mieux qu’un code avec des noms de variables et de fonctions bien choisis. Et lorsque c’est pas suffisamment explicite, les programmeurs doivent ajouter des commentaires pour aider à la compréhension du code. Les requêtes SQL ne doivent pas faire exceptions à cette règle. Supposons que vous devez …

J?ai fais beaucoup de tests pour m?assurer qu’une base de donnée en production sur MySQL 4 allait avoir le même comportement sur MySQL 5. Voici donc ma conclusion et les recommandations en conséquence.

La première différence que j?ai trouvé concerne les strings qu?on insère dans un champ char/varchar. Si on insère une string qui possède des espaces au début ou à la fin, MySQL4 les trim automatiquement. Ce n?est pas le cas de MySQL5. Il faut donc être spécialement attentif à ce qu?on insère et trimer tout les valeurs avant (c’est ce qu’il faudrait toujours faire de toute façon). Supposons qu?il se glisse accidentellement 2 espaces dans un champs, et qu?il y a 2 000 000 d?enregistrements dans la table. Il y aura donc 3.81 Mo de données et 3.81 Mo d?index (si le champs est indexé) pour stocker des espaces inutiles. Ça peut sembler trivial mais 3.81 Mo d?index, c?est énorme.

Une autre différence concerne …