Dolphin Finger

Finalement, c’est peu être un bon moyen d’augmenter la popularité de MySQL chez la gente féminine, cependant je n’arrive pas bien à voir où placer cette image dans ma présentation…

Rappel: Offre LeMug / forum PHP: http://dasini.net/blog/2009/10/20/conferences-mysql-au-forum-php/

Vous apprendrez entre autres, les principes bases tels que:

• L'installation
• La configuration
• La sécurité

Nous vous expliquerons aussi comment utiliser les différents outils MySQL sur Windows, et notamment:

• Le MySQL Workbench
• Le MySQL Enterprise Monitor avec le nouveau Query Analyzer

Ne manquez surtout pas ce séminaire web consacré au déploiement de MySQL sous Windows.

http://sldn.softlayer.com/09/2009/building-the-data-warehouse/

Disponible en anglais uniquement…

Au programme des conférences dédiées à MySQL et MariaDB :

• mysqlnd / « MySQL native driver for PHP » : Les améliorations de la stack avec Serge Frezefond
• Au secours, ma base de données fait ramer mon application ! avec Stéphane Combaudon
• MariaDB, the future of MySQL avec Michael Widenius aka Monty
• Retour d’expérience sur l’utilisation de MySQL Chez Orange Business Services avec Olivier DASINI
• Réplication MySQL : retours d’expérience avec Jean-François Bustarret

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 !*

Suivez ce lien pour adhérer au MUG et recevoir votre badge pour le Forum PHP

*Tarif normal de l’accès deux jours au Forum PHP 180 euros + Adhésion annuelle au MySQL User Group 20 euros.

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!

Néanmoins, la variable SQL_MODE permet de contrôler ce comportement. Plusieurs niveaux de validation peuvent donc être assignés, partant d’une validation quasi absente (par défaut) à une validation très stricte. Ce qui peut paraître comme une bonne affaire me parait plutôt comme une très mauvaise idée.

Le problème avec le SQL_MODE c’est que par défaut, la valeur est vide (oui oui!). Il n’y a pas de mode prédéfinie ce qui donne un comportement très souple. Plusieurs personnes ne savent pas que cette variable existe et construisent une application qui repose malheureusement sur cette souplesse. Lorsque votre application finie par en dépendre, c’est-à-dire qu’elle se comporte “normalement” avec cette absence de validation de données, vous risquez gros.

On peut insérer des dates impossibles comme le 31 février ou 0000-00-00 , des divisions par 0 dans des opérations mathématiques et des valeurs qui dépassent largement la limite possible des champs.  Votre application fait peut-être tout ça, sans même que vous le sachiez! Elle ne produit aucune erreur puisque du côté de MySQL, il n’y a que des Warnings.

Imaginez le scénario: vous désirez loguer des transactions bancaires, mais un bug idiot fait que toutes les dates des transactions sont insérées avec un string quelconque, 1-janvier-2009 par exemple, ce que MySQL converti en 0000-00-00. Le champ pour stocker l’IP de la personne qui fait la transaction est un SMALLINT, tous vos IP atteignent la valeur maximum et  sont convertis en 32767.

Un bon conseil: si vous débutez un nouveau projet, assurez-vous de mettre un SQL_MODE strict pour vous éviter des problèmes tôt ou tard ! Essayez-le sur une application existante pour voir comme elle réagit!

Le SQL_MODE peut être modifié par session ou globalement pour l’ensemble des usagés. Parmi les plus stricts, on retrouve

strict_trans_table: Si une valeur n’a pas pu être insérée dans une table transactionnelle sans modification, la commande est annulée. Pour une table non-transactionnelle, la commande est annulée si cela survient dans une ligne unique ou dans la première ligne d’une insertion multiple

traditional: MySQL se comporte comme un système SQL “traditionnel”. Une description simple est que ce mode “émet une erreur et non pas une alerte” lors de l’insertion d’une valeur incorrecte dans une colonne. Note : si vous utilisez un moteur de table non-transactionnel, les commandes INSERT/UPDATE s’arrêteront dès que l’erreur est repérée.

Alors ce séminaire web est pour vous! Vous bénéficierez de conseils d'experts pour vous aider à obtenir de meilleures performances!

Nous aborderons les sujets suivants:

• Concepts et recommandations de profiling & benchmarking
• Optimisation des schémas
• Sélection et optimisation des index
• Techniques de tuning du SQL
• Optimisation des paramètres du serveur

• Visualisez les activités liées aux requêtes pour obtenir un meilleur aperçu des performances au-delà des statistiques des requêtes
• Filtrez les requêtes lors des phases de ralentissement des performances et procédez à une résolution plus rapide et aisée des problèmes qui en découlent

Nous parlerons aussi des nouvelles règles de conseil pour l'administration, la mise à jour, les schémas et les performances.

Ne manquez surtout pas ce séminaire web!

En tant que boulimique de MySQL, je me promène souvent sur la toile à la recherche d’informations, de bonnes et de moins bonnes…

Je suis tombé sur un article traitant du cache de requêtes de MySQL (MySQL Query Cache) sur le blogue de Patrick Lafontaine (http://www.noidea.ca/)

Je me permet de faire quelques commentaires ici.

En préambule, quelques informations nécessaires sur le cache de requêtes:

Système de cache interne à MySQL qui ne stocke que les requêtes SELECT et leur résultat ie pas d’INSERT, UPDATE, DELETE…

Les requêtes ( SELECT donc) doivent être strictement identiques ie même casse, mêmes espaces entre les mots,…

Ex 3 requêtes différentes pour le cache :

Le cache est toujours à jour car en cas de modification d’une table, toutes les requêtes en relations avec cette table sont invalidées.

Le cache de requêtes est en général utile lorsque:

• Les modifications sur les tables ne sont pas très fréquentes
• Beaucoup de requêtes de lectures identiques
• Utilisation de tables MyISAM. Moins intéressant pour InnoDB

Pour rebondir sur l’article de Patrick Lafontaine

« puisqu’elle est activée par défaut. »

Le cache de requêtes n’est pas activé par défaut, car la variable query_cache_size vaut 0. Si vous voulez vous en servir, il faut lui donner une taille en octet. Mettez le tout dans votre fichier de configuration. Assurez vous également que la variable query_cache_type est différente de OFF

« c’est-à-dire que la ou les applications qui s’en servent n’ont pas besoin d’être modifiées »

Pour une optimisation optimale, il est parfois nécessaire de modifier les requêtes SELECT avec SQL_CACHE ou SQL_NO_CACHE. On choisit alors quelles requêtes seront mis en cache.

« Si quelqu’un modifie la valeur directement dans MySQL, la cache possèdera la vieille valeur jusqu’à ce qu’un processus l’invalide. »

Sur une machine de production, ce type de manipulation reste quand même exceptionnel, sinon c’est qu’il y a des choses à revoir dans les process.

« Puisque les données ne changent pratiquement jamais, je ne me casserais pas la tête à réinventer la roue. MySQL fait déjà pour vous ce que APC ferait, sans le moindre effort. »

Si le contenu ne change JAMAIS, il n’a à priori rien à faire en base ! Il vaut mieux utiliser un menu statique et laisser la base faire son boulot avec du contenu dynamique. Dans le même ordre d’idée, plus le cache est éloigné du disque plus il est performant. En d’autres termes, le goulet d’étranglement est souvent (parfois) la base de données, de plus elle est souvent (parfois) plus difficilement scalable que le reste. L’utilisation d’un cache applicatif est rarement une mauvaise idée (il suffit de connaître l’identité du plus gros consommateur de memcached au monde http://www.facebook.com/note.php?note_id=39391378919)

« Il est donc plus avantageux de cacher les processus lourds que les légers. »

Malheureusement, avec le cache de requêtes ce n’est pas aussi simple. Admettons qu’une requête renvoyant un gros résultat prenne plus de temps qu’une renvoyant un plus petit. Si cette grosse requête vire toutes les autres requêtes du cache, l’apport du cache pour les autres requêtes est perdu, elle devront être misent à nouveau dans le cache ca qui implique des recherches inutiles dans le caches et de nouveaux accès disque…

« Lorsque la Query Cache de MySQL est activée, le processus de cacher les résultats et de les invalider s’effectue tout seul de manière invisible. Ainsi, d’autres requêtes que vous ne soupçonnez même pas bénéficient de la cache »

L’efficacité du cache de requêtes est vraiment lié à l’application. Il dépend du type de requêtes SELECT, de leur fréquence et de la fréquence des écritures dans les tables. Le gain n’est pas évident et est loin d’être immédiat, car pour chaque requête « cachable » MySQL devra l’analyser, devra la hacher, devra vérifier s’il elle est dans le cache ou non. Et ceci à un coût…

Vous pouvez calculer le taux d’efficacité du cache de requêtes avec la formule suivant:

Qcache_hits / (Qcache_hits + Com_select )

Pour finir, quelques paramètres et commandes

Paramètres principaux:

query_cache_size: Doit être différent de zéro pour activer le cache

query_cache_type:

• ON: les requêtes select sont misent en cache

  • Sauf (SQL_NO_CACHE, result set trop grand, fonction non déterministe..)

• DEMAND: SELECT SQL_CACHE…

• OFF

Commandes principales:

FLUSH QUERY CACHE

• Défragmente le cache de requêtes

• Ne vide pas le cache

Vider le cache de requêtes:

• RESET QUERY CACHE

• FLUSH TABLES

• Redémarrer le serveur

Variables d’état: SHOW STATUS LIKE ‘Qcache%’ ;

Qcache_free_blocks : nombre de blocs libres

Qcache_free_memory : mémoire libre

Qcache_hits : nombre de fois qu’il a servi

Qcache_inserts : nombre de requêtes insérées

Qcache_lowmem_prunes : nombre de requêtes supprimées car plus de place

Qcache_not_cached : nombre de requêtes non « cachables »

Qcache_queries_in_cache : nombre de requêtes dans le cache

Qcache_total_blocks : nombre de blocs de mémoire

PlanetMySQL Voting: Vote UP / Vote DOWN]]> Mon, 12 Oct 2009 15:21:50 +0000 Olivier Dasini MySQL optimisation query cache tag:moosh.et.son.brol.be,2009-10-12:/blog/1023 http://moosh.et.son.brol.be/blog/index.php/2009/10/12/1023-les-mots-reserves-de-mysql ADD ALL ALTER ANALYZE AND AS ASC ASENSITIVE BEFORE BETWEEN BIGINT BINARY BLOB BOTH BY CALL CASCADE CASE CHANGE CHAR CHARACTER CHECK COLLATE COLUMN CONDITION CONNECTION CONSTRAINT CONTINUE CONVERT CREATE CROSS CURRENT_DATE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR DATABASE DATABASES DAY_HOUR DAY_MICROSECOND DAY_MINUTE DAY_SECOND DEC DECIMAL DECLARE DEFAULT DELAYED DELETE DESC DESCRIBE DETERMINISTIC DISTINCT DISTINCTROW DIV DOUBLE DROP DUAL EACH ELSE ELSEIF ENCLOSED ESCAPED EXISTS EXIT EXPLAIN FALSE FETCH FLOAT FLOAT4 FLOAT8 FOR FORCE FOREIGN FROM FULLTEXT GOTO GRANT GROUP HAVING HIGH_PRIORITY HOUR_MICROSECOND HOUR_MINUTE HOUR_SECOND IF IGNORE IN INDEX INFILE INNER INOUT INSENSITIVE INSERT INT INT1 INT2 INT3 INT4 INT8 INTEGER INTERVAL INTO IS ITERATE JOIN KEY KEYS KILL LABEL LEADING LEAVE LEFT LIKE LIMIT LINES LOAD LOCALTIME LOCALTIMESTAMP LOCK LONG LONGBLOB LONGTEXT LOOP LOW_PRIORITY MATCH MEDIUMBLOB MEDIUMINT MEDIUMTEXT MIDDLEINT MINUTE_MICROSECOND MINUTE_SECOND MOD MODIFIES NATURAL NOT NO_WRITE_TO_BINLOG NULL NUMERIC ON OPTIMIZE OPTION OPTIONALLY OR ORDER OUT OUTER OUTFILE PRECISION PRIMARY PROCEDURE PURGE RAID0 READ READS REAL REFERENCES REGEXP RELEASE RENAME REPEAT REPLACE REQUIRE RESTRICT RETURN REVOKE RIGHT RLIKE SCHEMA SCHEMAS SECOND_MICROSECOND SELECT SENSITIVE SEPARATOR SET SHOW SMALLINT SONAME SPATIAL SPECIFIC SQL SQLEXCEPTION SQLSTATE SQLWARNING SQL_BIG_RESULT SQL_CALC_FOUND_ROWS SQL_SMALL_RESULT SSL STARTING STRAIGHT_JOIN TABLE TERMINATED THEN TINYBLOB TINYINT TINYTEXT TO TRAILING TRIGGER TRUE UNDO UNION UNIQUE UNLOCK UNSIGNED UPDATE UPGRADE USAGE USE USING UTC_DATE UTC_TIME UTC_TIMESTAMP VALUES VARBINARY VARCHAR VARCHARACTER VARYING WHEN WHERE WHILE WITH WRITE X509 XOR YEAR_MONTH ZEROFILL Je l'avais déjà posté mais j'en ai eu besoin aujourd'hui. Donc comme c'est toujours utile, je le rappelle. ADD ALL ALTER ANALYZE AND AS ASC ASENSITIVE BEFORE BETWEEN BIGINT BINARY BLOB BOTH BY CALL CASCADE CASE CHANGE CHAR CHARACTER CHECK COLLATE COLUMN CONDITION CONNECTION CONSTRAINT CONTINUE CONVERT CREATE CROSS CURRENT_DATE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR DATABASE DATABASES DAY_HOUR DAY_MICROSECOND DAY_MINUTE DAY_SECOND DEC DECIMAL DECLARE DEFAULT DELAYED DELETE DESC DESCRIBE DETERMINISTIC DISTINCT DISTINCTROW DIV DOUBLE DROP DUAL EACH ELSE ELSEIF ENCLOSED ESCAPED EXISTS EXIT EXPLAIN FALSE FETCH FLOAT FLOAT4 FLOAT8 FOR FORCE FOREIGN FROM FULLTEXT GOTO GRANT GROUP HAVING HIGH_PRIORITY HOUR_MICROSECOND HOUR_MINUTE HOUR_SECOND IF IGNORE IN INDEX INFILE INNER INOUT INSENSITIVE INSERT INT INT1 INT2 INT3 INT4 INT8 INTEGER INTERVAL INTO IS ITERATE JOIN KEY KEYS KILL LABEL LEADING LEAVE LEFT LIKE LIMIT LINES LOAD LOCALTIME LOCALTIMESTAMP LOCK LONG LONGBLOB LONGTEXT LOOP LOW_PRIORITY MATCH MEDIUMBLOB MEDIUMINT MEDIUMTEXT MIDDLEINT MINUTE_MICROSECOND MINUTE_SECOND MOD MODIFIES NATURAL NOT NO_WRITE_TO_BINLOG NULL NUMERIC ON OPTIMIZE OPTION OPTIONALLY OR ORDER OUT OUTER OUTFILE PRECISION PRIMARY PROCEDURE PURGE RAID0 READ READS REAL REFERENCES REGEXP RELEASE RENAME REPEAT REPLACE REQUIRE RESTRICT RETURN REVOKE RIGHT RLIKE SCHEMA SCHEMAS SECOND_MICROSECOND SELECT SENSITIVE SEPARATOR SET SHOW SMALLINT SONAME SPATIAL SPECIFIC SQL SQLEXCEPTION SQLSTATE SQLWARNING SQL_BIG_RESULT SQL_CALC_FOUND_ROWS SQL_SMALL_RESULT SSL STARTING STRAIGHT_JOIN TABLE TERMINATED THEN TINYBLOB TINYINT TINYTEXT TO TRAILING TRIGGER TRUE UNDO UNION UNIQUE UNLOCK UNSIGNED UPDATE UPGRADE USAGE USE USING UTC_DATE UTC_TIME UTC_TIMESTAMP VALUES VARBINARY VARCHAR VARCHARACTER VARYING WHEN WHERE WHILE WITH WRITE X509 XOR YEAR_MONTH ZEROFILL Je l'avais déjà posté mais j'en ai eu besoin aujourd'hui. Donc comme c'est toujours utile, je le rappelle.
PlanetMySQL Voting: Vote UP / Vote DOWN]]> Mon, 12 Oct 2009 13:21:41 +0000 Christophe Gesché Mysql http://www.nexen.net/actualites/php/19281-120_possibilites_autour_de_mysqlnd.php http://www.nexen.net/actualites/php/19281-120_possibilites_autour_de_mysqlnd.php Pour rappel, MySQLND est une bibliothèque qui remplace libmysql dans les versions récentes de PHP, permettant d'inclure une nouvelle approche pour accélérer les transferts. Le site internet Super Hero propose une liste très complète autour de MySQLND avec PHP avec 120 possibilités offertes. En voici quelques unes : packets_sent, packets_received bytes_received_eof_packets, packets_received_eof bytes_received_rset_field_meta_packet, packets_received_rset_field_metabytes_received_change_user_packet, packets_received_change_user result_set_queries slow_queries flushed_normal_sets, flushed_ps_sets rows_fetched_from_client_ps_cursor connect_success, connect_failure in_middle_of_command_close command_buffer_too_small PHP: 120 tuning screws for mysqlnd (0 visite)

J’ai recu la semaine passée la question suivante (je résume):

Je souhaite utiliser une cache pour le menu de mon site afin de le rendre plus performant. Puisque le contenu du menu ne change pratiquement jamais, est-il plus avantageux d’utiliser APC Cache que la Query Cache de MySQL puisque la communication s’effectue selon un schéma comme:

php -> cache_apc (ram)
php -> mysql -> query_cache (ram)

Je souhaite réduire au minimum les requêtes SQL exécutées.

Personnellement, j’utiliserais la cache de MySQL. Tout d’abord, il faut savoir qu’il y a une énorme différence entre les 2 caches.

MySQL Query Cache est centralisée sur le serveur MySQL, c’est-à-dire qu’elle utilise la RAM de la machine du serveur MySQL. Elle possède un mécanisme d’invalidation basique, mais efficace. L’invalidation se produit lorsque des valeurs d’une table sont en cache, et que ces valeurs sont mise à jour par une application ou manuellement par un utilisateur.

APC Cache est centralisée sur le serveur Web, c’est-à-dire qu’elle utilise la RAM disponible sur le serveur qui roule Apache et PHP (en supposant que vous utilisez Apache). Vous serez responsable d’invalider la cache lorsque nécessaire. Si quelqu’un modifie la valeur directement dans MySQL, la cache possèdera la vieille valeur jusqu’à ce qu’un processus l’invalide.

Puisque les données ne changent pratiquement jamais, je ne me casserais pas la tête à réinventer la roue. MySQL fait déjà pour vous ce que APC ferait, sans le moindre effort. De plus, il est plus ou moins vrai de dire que d’appeler la cache correspond à une requête. Oui, la string SQL est nécessairement envoyé à MySQL, mais lorsque celui-ci la reçoit et valide que cette requête est cachée, il retourne immédiatement le résultat sans rien “processer”. C’est comme ça que fonctionne APC aussi, il lui faut un identifiant unique pour associer le résultat, tout comme fait MySQL avec le HASH de la requête.

Les caches (peu importe laquelle) sont tout aussi efficaces avec une petite requête qui consomme peu de ressource qu’avec une grosse qui en demande beaucoup. Il est donc plus avantageux de cacher les processus lourds que les légers.

Ce qu’il faut surtout se soucier lorsqu’on utilise une cache, c’est comment et à quelle fréquence il faut l’invalider. Lorsque la Query Cache de MySQL est activée, le processus de cacher les résultats et de les invalider s’effectue tout seul de manière invisible. Ainsi, d’autres requêtes que vous ne soupçonnez même pas bénéficient de la cache. À l’inverse, il faut modifier le code pour chaque requête que vous souhaitez cacher avec APC.