bases-de-donnees
Actualité
Meetup MySQL le 1er février à ParisA l’initiative de SkySQL et LeMug.fr, Colin Charles de Monty Program viendra nous parler de MariaDB demain mercredi 1er février au Patricks Irish Pub à Paris à partir de 18h. Si vous souhaitez en connaître un peu plus sur ce fork de MySQL, n’hésitez pas ! Plus d’infos sur la page officiellle
dbnews.com | 31-janv.-2012 17:03
Comprendre son fichier de configuration – 2ème partie
Pour notre deuxième volet sur les points les plus importants à regarder lors de la configuration d’un serveur MySQL, nous allons nous occuper du cache de requêtes, de la réplication et de la journalisation. En route ! Cache de requêtes Le cache de requêtes est une excellente idée des années 90 pour accélérer les performances des SELECT. Malheureusement ce cache n’est absolument pas scalable en terme de connexions simultanées, ce qui signifie que dans 99,9% des cas, les performances seront meilleures quand le cache est désactivée. Par conséquent, le tuning du cache de requêtes est très simple, il vous suffit d’indiquer dans votre fichier de configuration : query_cache = 0 Pour les plus curieux, sachez que la désactivation du cache de requêtes n’empêche pas le serveur d’utiliser la mutex d’accès au cache de requêtes : même désactivé, le cache de requêtes peut diminuer vos performances !! Dans Percona Server et MySQL 5.5, query_cache = 0 désactive également cette mutex, mais pour les versions antérieures, il vous faudra recompiler le serveur sans support du cache de requêtes pour vous débarasser de cette mutex. Réplication La réplication est tellement utile qu’il est difficile de s’en passer : scale-out, haute disponibilité, aide aux backups, slaves dédiés pour les statistiques… la liste des applications est longue ! Sur toutes les instances impliquées dans un schéma de réplication, il faut absolument que chaque instance ait un server-id unique. Si vous utilisez un système de déploiement de configuration, pensez à faire en sorte que le système de déploiement génère lui-même un id qui soit garanti comme étant unique. Sur le master, il faut également activer le paramètre log_bin pour mettre en route les logs binaires nécessaires à la réplication (et qui sont aussi utiles pour le Point In Time Recovery), par exemple : log_bin = /data/mysql-bin Le serveur s’occupe tout seul de numéroter les fichiers et d’en faire la rotation. A ce propos, il peut être pratique de forcer la rotation quand le fichier atteint une taille plus faible que celle par défaut (1 Go) : max_binlog_size = 100000000 et de purger automatiquement les fichiers au bout d’un certain temps : expire_logs_days = 7 Est également recommandé l’option sync_binlog = 1 qui assure le flush du log binaire à chaque commit (meilleure assurance contre les pertes de données en cas de crash). Sur les slaves, il n’est en général pas nécessaire d’activer les logs binaires, sauf si le slave est lui-même un master. Dans ce cas, il faut penser à ajouter le paramètre log_slave_updates, qui indique au serveur d’écrire dans les logs binaires les écritures reçues par la réplication. La seule autre option vraiment intéressante est read_only = 1, qui empêche tous les utilisateurs n’ayant pas le droit SUPER d’écrire sur le serveur. Cette option peut éviter des gros problèmes de désynchronisations si accidentellement une application tente d’écrire directement sur un slave au lieu d’écrire sur le master. Ne pas oublier également de configurer un compte pour la réplication avec les droits REPLICATION SLAVE et REPLICATION CLIENT. Journalisation Avoir des traces de ce qui se passe dans le serveur est évidemment une très bonne idée, aussi bien pour résoudre les problèmes que pour prendre des mesures préventives. Il existe avec MySQL 3 types de logs : general log pour l’ensemble des connexions et requêtes, slow query log pour les requêtes lentes et error log pour les erreurs et warnings. Il est préférable d’éviter d’activer le general log en production, hormis pour des périodes courtes pour investiguer sur un problème précis, car les performances s’en ressentent lourdement (et que vous risquez de vous retrouver très vite à court d’espace disque). Cela se traduit par : general_log = OFF Le slow query log est particulièrement utile pour repérer les requêtes les plus coûteuses de votre application. Toutes les requêtes au-delà d’un seuil que vous définissez sont écrites et peuvent servir à générer un rapport des requêtes les plus lentes. Une configuration typique est la suivante : slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 0.5 Enfin le log d’erreur devrait être activé, soit par le paramètre log_error soit en écrivant dans syslog, avec le paramètre syslog que vous trouverez généralement dans la section [mysqld_safe]. Sachez que les 2 solutions ont des avantages et des inconvénients, l’inconvénient étant toujours que vous risquez de perdre la trace d’erreurs à cause de la rotation de votre fichier de log. Vous trouverez plus d’informations dans ce billet. Nous verrons dans le dernier article de cet série les paramètres les plus importants pour InnoDB. D’ici là, bonnes fêtes de fin d’année !
planetmysql.org | 22-déc.-2011 16:33
Comprendre son fichier de configuration – 1ère partie
Des outils tels que mysql tuning primer ou mysqltuner proposent de vous aider à configurer correctement votre serveur MySQL. Il est vrai qu’il est facile de se perdre dans la profusion d’options disponibles. Pourtant les recommendations de ces outils sont bien souvent complètement absurdes ! Il est bien plus fiable de connaître les grandes lignes [...]
dbnews.com | 16-déc.-2011 16:26
Meetup Viadeo/LeMug.fr le 16 novembre
Notre ami Olivier organise le mercredi 16 novembre 2011 une rencontre autour de MySQL dans les locaux de Viadeo à Paris. Si vous êtes disponible ce jour-là, n’hésitez pas à vous inscrire et à venir nous dire bonjour ! Le programme de la rencontre est déjà disponible, n’oubliez pas de vous inscrire si vous comptez venir, [...]
dbnews.com | 03-nov.-2011 16:59
Discount code pour Percona Live London
Percona Live est une série de conférences 100% techniques autour de MySQL, organisées par Percona. La prochaine conférence aura lieu à Londres les 24 et 25 octobre et pour tous ceux qui souhaiteraient y assister, dbnewz vous propose un tarif réduit ! Voici le code magique qui vous donnera droit à une réduction de 40£ : [...]
dbnews.com | 07-oct.-2011 15:01
MySQL et ses messages d’erreur
Je suis en généralement plutôt content de MySQL : c’est simple et stable, ça fonctionne bien. Mais il reste encore du travail pour que les messages d’erreur soient explicites. Petit résumé d’une frayeur causée par un message d’erreur approximatif. Une de mes tables a une tendance marquée à la fragmentation, ce qui a pour conséquence de faire gonfler artificiellement sa taille et de faire baisser les performances de certaines requêtes. Je dois donc de temps à autre la défragmenter. Pas de problème : je commence par regarder la taille sur le disque du fichier .ibd (il s’agit d’une table InnoDB sur un serveur pour lequel innodb_file_per_table est activé). Quand la table est défragmentée, elle fait environ 8 Go : # cd /data/mysql/main_revshare # du -sh bris_statistic_video.ibd 11G bris_statistic_video.ibd Pas de doute, une séance de défragmentation s’impose. Je me connecte donc au serveur MySQL pour exécuter un OPTIMIZE TABLE : mysql> OPTIMIZE TABLE bris_statistic_video\G ******** 1. row ******** Table: dailymotion.bris_statistic_video Op: optimize Msg_type: Error Msg_text: Table 'dailymotion.bris_statistic_video' doesn't exist ******** 2. row ******** Table: dailymotion.bris_statistic_video Op: optimize Msg_type: error Msg_text: Corrupt Et là, c’est le drame ! Quoi, ma table est corrompue ? Impossible, l’application fonctionne toujours et la table est utilisée partout ! Comment sortir de ce problème : redémarrer le serveur en espérant qu’InnoDB répare la table, récupérer un backup ? En fait non, il faut simplement rester calme et bien regarder le message : si à la 2ème ligne, MySQL nous annonce que la table est corrompue, à la 1ère MySQL nous annonce que la table n’existe pas … alors que nous avons vu que le fichier .ibd existe bien. Louche cette histoire ! Un tour dans le journal d’erreurs confirme bien qu’il n’existe aucune erreur : il doit donc y avoir une erreur avec la commande OPTIMIZE. Réfléchissons, réfléchissons … ça y est : j’ai exécuté la commande OPTIMIZE dans la base main alors que ma table se trouve dans la base main_revshare. Il suffit donc de se positionner dans main_revshare et de relancer l’OPTIMIZE, avec succès cette fois. Moralité : Mieux vaut se méfier des messages d’erreurs qui ne vous sont pas familiers et bien réfléchir à la cause de l’erreur avant de se lancer dans la correction d’un problème qui n’existe peut-être pas !
planetmysql.org | 13-sept.-2011 16:16
Méthodes de suppression des index inutiles
Les vacances étant terminées, nous allons boucler notre tour de vue des index inutiles en voyant quels outils vont nous aider à découvrir les index qui peuvent être supprimés. Le dernier article présentait en effet des indications qui fonctionnent généralement bien mais qui ont l’inconvénient de demander beaucoup de travail manuel et de laisser de [...]
dbnews.com | 05-sept.-2011 17:59
Index candidats à la suppression
Après avoir constaté dans les articles précédents que les index inutiles causent des baisses de performances non négligeables, nous allons voir dans cet article qu’il n’est pas aussi simple qu’il y paraît de déterminer si un index est utile ou non, même si dans certains cas la réponse semble évidente. A première vue, trois catégories d’index sont bien placés pour être qualifiés d’inutiles : les index en doublon, les index redondants et les index à faible cardinalité. Regardons chaque catégorie en détail. Index en doublon Les index en doublon sont simplement ceux qui sont définis plusieurs fois. Un exemple simple pour commencer : CREATE TABLE t ( id int(11) DEFAULT NULL, KEY a (id), KEY b (id) ); Notons que MySQL n’empêche en aucun cas ce genre de définition erronée. Un autre exemple, un peu plus compliqué : CREATE TABLE u ( id int(11) NOT NULL DEFAULT '0', UNIQUE KEY (id), KEY b (id) ); La logique était : je crée une contrainte d’unicité sur la colonne id, puis un index pour accélérer les requêtes. Sauf qu’avec MySQL, toutes les contraintes sont vérifiées avec des index, ce qui signifie que la création de la contrainte d’unicité crée implicitement un index (idem pour PRIMARY KEY et FOREIGN KEY). Un dernier exemple : CREATE TABLE v ( id int(11) NOT NULL DEFAULT '0', col varchar(10) DEFAULT NULL, PRIMARY KEY (id), KEY a (col), FULLTEXT KEY b (col) ) ENGINE=MyISAM; Ici, nous avons bien deux index sur col, mais ce ne sont pas des index de même type, ils ne sont donc pas en doublon. Attention aux excès de zèle ! Les index en doublon n’apportent rien, il est donc toujours utile de pouvoir les repérer pour ensuite les supprimer. Un bon outil pour ce travail est mk-duplicate-key-checker de Maatkit. L’outil est très simple d’usage et la documentation complète. Par exemple, pour vérifier si notre table u (dans la base test) contient des index en doublon, on peut utiliser la ligne suivante : $ mk-duplicate-key-checker h=localhost,u=root,D=test -t u # ################################## # test.u # ################################## # b is a duplicate of PRIMARY # Key definitions: # KEY `b` (`id`) # PRIMARY KEY (`id`), # Column types: # `id` int(11) not null default '0' # To remove this duplicate index, execute: ALTER TABLE `test`.`u` DROP INDEX `b`; # ################################## # Summary of indexes # ################################## # Size Duplicate Indexes 0 # Total Duplicate Indexes 1 # Total Indexes 2 L’outil suggère avec raison que l’index b est en doublon de la clé primaire et propose sous la forme d’un ALTER TABLE une requête pour supprimer cet index. La même ligne de commande, en version longue : $ mk-duplicate-key-checker --host localhost --user root --databases test --tables t Il est bien sûr possible d’examiner en une seule passe toutes les tables de la base test : $ mk-duplicate-key-checker --host localhost --user root --databases test # ################################## # test.t # ################################## # a is a duplicate of b # Key definitions: # KEY `a` (`id`), # KEY `b` (`id`) # Column types: # `id` int(11) default null # To remove this duplicate index, execute: ALTER TABLE `test`.`t` DROP INDEX `a`; # ################################## # test.u # ################################## # b is a duplicate of id # Key definitions: # KEY `b` (`id`) # UNIQUE KEY `id` (`id`), # Column types: # `id` int(11) not null default '0' # To remove this duplicate index, execute: ALTER TABLE `test`.`u` DROP INDEX `b`; # ################################## # Summary of indexes # ################################## # Size Duplicate Indexes 0 # Total Duplicate Indexes 2 # Total Indexes 7 Parfait, mk-duplicate-key-checker a bien identifié les doublons et ne s’est pas fait piéger par l’index FULLTEXT de la table v. Index redondants Pour les index de type BTREE (c’est-à-dire tous les index sauf les index HASH de Memory et les index FULLTEXT de MyISAM), l’optimiseur de requêtes de MySQL est capable d’utiliser un préfixe gauche d’un index composite. Tous les index portant sur des préfixes gauche d’un index composite ne sont donc théoriquement pas utiles. Pas clair ? Regardez la table suivante : CREATE TABLE w ( id int(11) NOT NULL DEFAULT '0', col varchar(10) DEFAULT NULL, col2 varchar(10) DEFAULT NULL, KEY id (id), KEY id_col (id,col) ); Et considérez la requête suivante : SELECT * FROM w WHERE id = 1 EXPLAIN nous indique que l’index sur id est utilisé : mysql> EXPLAIN SELECT * FROM w WHERE id = 1\G ********* 1. row ******** id: 1 select_type: SIMPLE table: w type: ref possible_keys: id,id_col key: id key_len: 4 ref: const rows: 1 Extra: Mais si on demande à l’optimiseur de ne pas considérer l’index sur id, on voit que la requête va s’exécuter de manière aussi efficace en utilisant l’index sur (id,col) : mysql> EXPLAIN SELECT * FROM w IGNORE INDEX(id) WHERE id = 1\G ******** 1. row ******** id: 1 select_type: SIMPLE table: w type: ref possible_keys: id_col key: id_col key_len: 4 ref: const rows: 1 Extra: On peut donc éliminer sans problème l’index sur id. Faut-il donc systématiquement supprimer les index redondants ? Eh bien non, il convient d’apporter quelques nuances. Disons que la majeure partie du temps, un index redondant est inutile et peut être supprimé, mais qu’il existe des situations où il faudra conserver tous les index. Par exemple, ce sera souvent le cas quand les colonnes indexées sont de grande taille (que ceux qui n’utilisent jamais de VARCHAR(255) lèvent la main ). Pour avoir un cas concret de ce type de situation, vous pouvez lire cet article. Comment savoir si un index redondant est utile ou non ? La seule solution utilisable est bien souvent de faire des tests. Que dit mk-duplicate-key-checker sur les index redondants ? $ mk-duplicate-key-checker h=localhost,u=root,D=test -t w # ################################## # test.w # ################################## # id is a left-prefix of id_col # Key definitions: # KEY `id` (`id`), # KEY `id_col` (`id`,`col`) # Column types: # `id` int(11) not null default '0' # `col` varchar(10) default null # To remove this duplicate index, execute: ALTER TABLE `test`.`w` DROP INDEX `id`; # ################################## # Summary of indexes # ################################## # Size Duplicate Indexes 16 # Total Duplicate Indexes 1 # Total Indexes 2 L’outil considère toujours les index redondants comme candidats à la suppression. A vous de voir s’il vaux mieux le conserver ou non. Index à faible cardinalité Arnaud a déjà parlé en détail de la notion de cardinalité d’un index. En résumé, la cardinalité est le nombre de valeurs uniques de l’index. Plus elle est élevée, plus l’index sera efficace dans son filtrage. Si la cardinalité est faible, l’index perd de son intérêt. D’ailleurs, l’optimiseur de requêtes n’utilisera pas l’index s’il estime qu’il n’est pas utile. Voici donc de bons candidats à la suppression ! Cependant là encore, il convient de nuancer. Imaginez un site de e-commerce avec une table contenant les commandes. Cette table va contenir un champ indiquant le statut des commandes, avec par exemple les valeurs ‘archivée’ et ‘en cours’. Au bout de quelque temps, il est certain que presque toutes les lignes de la table auront le statut ‘archivée’. Cependant, si vous écrivez une requête qui porte sur les commandes ‘en cours’, un index sur la colonne statut sera sûrement utile, même si sa cardinalité sera ridicule (2 en l’occurence). Ce qui joue ici n’est pas seulement la cardinalité de l’index, mais aussi la distribution des valeurs et surtout les requêtes que vous faites. Si avec la même table des commandes, votre voisin ne s’intéresse qu’aux commandes archivées, l’index n’a plus aucun intérêt. C’est d’ailleurs une situation que l’on rencontre fréquemment : les requêtes que l’on peut faire en mode transactionnel ou en mode décisionnel sont radicalement différentes, exigeant souvent d’avoir des installations dédiées avec une indexation différente. Conclusion Cet article a montré que le repérage des index inutiles est loin d’être évident. Mis à part les index en doublon qu’on peut repérer et éliminer facilement, il est nécessaire d’avoir une bonne connaissance des requêtes qui sont exécutées afin de déterminer si un index est inutile. Le prochain article va se concentrer sur des méthodes plus systématiques d’identification des index inutiles.
planetmysql.org | 06-juil.-2011 15:10
Le coût des index inutiles – 2nde partie
Dans l’article précédent, nous nous étions demandés quelle était la dégradation des performances en écriture quand on ajoute des index. On peut élargir la réflexion en se penchant sur les conditions qui améliorent ou diminuent la vitesse d’écriture dans une table. Avant de commencer de nouvelles expérimentations, rappelons les conditions du test. La table utilisée a la structure suivante : CREATE TABLE ( id int(11) NOT NULL AUTO_INCREMENT, col_a varchar(30) NOT NULL DEFAULT '', col_b varchar(30) NOT NULL DEFAULT '', col_c varchar(30) NOT NULL DEFAULT '', PRIMARY KEY (id) ); et nous cherchons à insérer un millions de lignes à l’aide de la commande LOAD DATA INFILE. Rappelons aussi que pour améliorer les performances en écriture dans l’absolu, il existe d’autres pistes que nous n’explorerons pas dans cet article : si la table utilise InnoDB ou XtraDB, modifier certaines variables de configuration (innodb_log_file_size,innodb_flush_log_at_trx_commit, innodb_adaptive_flushing, etc) si la table utilise MyISAM, modifier d’autres variables de configuration (myisam_sort_buffer_size, bulk_insert_buffer_size) faire des insertions multithreadées désactiver les vérifications de clés étrangères ou de clés uniques … Pour commencer nos test, examinons le comportement de MyISAM. Le paramètre clé est la taille du cache d’index (key_buffer_size), nous faisons donc un essai avec un cache d’index suffisamment grand pour pouvoir contenir tous les index et un essai avec un cache trop petit. MyISAM, key_buffer_size grand : Seulement la clé primaire : 4s Clé primaire + index sur col_a : 6,6s Clé primaire + index sur col_b : 9,3s Clé primaire + index sur (col_a,col_b) : 6,8s MyISAM, key_buffer_size petit : Seulement la clé primaire : 4s Clé primaire + index sur col_a : 6,8s Clé primaire + index sur col_b : 9,3s Clé primaire + index sur (col_a,col_b) : 6,8s A comparer avec les résultats obtenus la dernière fois avec InnoDB : Seulement la clé primaire : 15s Clé primaire + index sur col_a : 28,5s Clé primaire + index sur col_a + index sur col_b : 44,5s Clé primaire + index sur (col_a,col_b) : 36,3s Très intéressant ! MyISAM se révèle plus performant qu’InnoDB, et de loin. Attention, ne faisons pas de généralités sur la vitesse de MyISAM ! Ce test se déroule sur un serveur hors production qui n’exécute que les LOAD DATA INFILE. Il est certain que l’écart entre InnoDB et MyISAM ne serait pas aussi important si les insertions étaient multithreadées (verrouillage de toute la table pour MyISAM) et si le serveur recevait également des requêtes en lecture (les écritures seraient peut-être rapides mais les lectures souffriraient sans doute). De plus, on voit que la taille du cache d’index n’influence quasiment pas le temps de chargement, ce qui est plutôt inattendu. Une explication possible serait que les données et index ne soient pas réellement écrits sur le disque, mais restent dans le cache de l’OS. L’hypothèse semble raisonnable puisqu’un coup d’oeil sur iostat pendant les LOAD DATA INFILE montre que les écritures sur le disque sont nettement plus nombreuses quand la table est en InnoDB. Faisons donc un autre test avec MyISAM, pour lequel le cache d’index est petit et la quantité de mémoire disponible pour l’OS est trop faible pour pouvoir contenir les données et les index : Seulement la clé primaire : 6,8s Clé primaire + index sur col_a : 14s Clé primaire + index sur col_b : 24s Clé primaire + index sur (col_a,col_b) : 18s Les performances sont bien moins bonnes qu’avant, mais restent encore supérieures à celles d’InnoDB ! Concentrons nous maintenant sur InnoDB et voyons l’influence du type de clé primaire sur le temps de chargement. Pour simplifier, mettons-nous toujours dans le cas où le buffer_pool est suffisamment grand pour contenir données et index. Dans un premier temps, optons pour une clé primaire composite (id,col_c) : Seulement la clé primaire : 17,8s Clé primaire + index sur col_a : 40s Clé primaire + index sur col_b : 72s Clé primaire + index sur (col_a,col_b) : 51,7s On voit qu’avoir une clé primaire composite a un impact non négligeable lorsqu’il n’existe pas d’autres index (20% de perte de performance) et que cet impact négatif est encore plus important quand on ajoute des index. Ce résultat était attendu, puisqu’avec InnoDB, chaque index secondaire contient la clé primaire : plus la clé primaire est volumineuse, plus les index secondaires sont volumineux et longs à mettre à jour. Dans un second temps, supprimons la clé primaire : Seulement la clé primaire : 14,6s Clé primaire + index sur col_a : 29,2s Clé primaire + index sur col_b : 45,5s Clé primaire + index sur (col_a,col_b) : 38,1s Les temps obtenus sont proches du cas initial où id est la clé primaire. Comment expliquer ce résultat ? InnoDB a besoin d’une clé primaire pour toutes ses tables. Si vous ne la définissez pas vous-même et qu’il n’existe pas d’index unique n’ayant aucune valeur NULL, InnoDB créé une clé primaire cachée sous la forme d’un entier. On se retrouve donc avec une structure du type suivant : CREATE TABLE ( hidden_id int NOT NULL AUTO_INCREMENT, id int(11) NOT NULL, col_a varchar(30) NOT NULL DEFAULT '', col_b varchar(30) NOT NULL DEFAULT '', col_c varchar(30) NOT NULL DEFAULT '', PRIMARY KEY (hidden_id) ); On se retrouve avec la même structure qu’initialement, mais avec une colonne de plus, donc avec une volumétrie un peu plus importante, ce qui explique les résultats similaires mais légèrement inférieurs. Que pouvons-nous conclure de tous ces test ? Tout d’abord, que le moteur de stockage a une grande influence sur les résultats. Si vous avez le choix du moteur, des tests s’imposent pour déterminer lequel est le meilleur, en ayant soin de prendre en compte la charge réelle de l’application (connexions concurrentes, lectures et écritures). Ensuite, que pour InnoDB, le choix de la clé primaire est critique : la clé primaire doit être la plus compacte possible, sous peine de performances très dégradées. Enfin, que pour MyISAM comme pour InnoDB, il vaut mieux limiter le nombre d’index qui ralentissent considérablement toutes les écritures.
planetmysql.org | 27-mai-2011 17:50
Le coût des index inutiles
On vous a tout le temps dit et redit que les index étaient indispensables pour les performances en lecture d’une base de données et vous avez eu droit à des exemples spectaculaires où les temps de réponses sont divisés par 10 000 ou par 1 000 000 rien qu’en ajoutant un index judicieux. Bien. On [...]
dbnews.com | 16-mai-2011 16:48
A quoi sert SQL_NO_CACHE ?
Lorsqu’on essaie d’améliorer une requête, que ce soit en modifiant le plan d’exécution ou en réécrivant la requête, on finit par choisir la variante dont le temps d’exécution est le plus faible. Encore faut-il que ce temps d’exécution ne soit pas falsifié par un quelconque cache. En cherchant comment désactiver les caches de MySQL, vous [...]
dbnews.com | 29-mars-2011 16:35
Rappel : Meeting MySQL le 7 mars
Comme annoncé la semaine dernière, LeMug.fr prépare un meeting le 7 mars au café Dune à Paris à partir de 19h. Ce sera l’occasion d’écouter Morgan de Percona nous parler d’optimisation avec MySQL, mais aussi de discuter de nos différentes expériences autour de MySQL. Voici le lien avec toutes les informations. A lundi !
planetmysql.org | 04-mars-2011 12:05
Meeting avec Morgan Tocker de Percona
LeMug.fr prépare son revival le 7 mars au café Dune à Paris ! Morgan Tocker, consultant et formateur chez Percona, nous fait l’honneur d’une visite, au cours de laquelle il nous parlera bien évidemment de MySQL. Nous aurons l’occasion de reparler ce meeting dans les jours à venir, mais vous pouvez d’ores et déjà bloquer la [...]
dbnews.com | 24-févr.-2011 15:43
Stockage des IP : le mystère de l’adresse 127.255.255.255
Il est assez courant d’avoir besoin de stocker des adresses IP dans une base MySQL et malheureusement il n’est pas très courant que la manière de faire soit optimisée. Cet article vous propose de faire le point sur le sujet, ainsi que sur une erreur qu’on rencontre quand on fait presque bien les choses, mais [...]
dbnews.com | 17-févr.-2011 13:54