New bug found in google

http://maps.google.com/maps?.....6738&om=1

ALICE AU CORE DE MySQL-5.1 :PART2: L'Optimiseur | The Optimizer

Dans la documentation officielle de MySQL on trouve dans le chapitre "7.2.4. Comment MySQL optimise les clauses WHERE" que "Cette section est incomplète. MySQL fait de très nombreuses optimisations, et nous n'avons pas eu le temps de toutes les documenter.". Alors on va la reprendre les posts qui viennent, dans l'objectif de mettre un point sur les inconvénients d'une requête mal écrite ou très complexes pour MySQL. Par ce que, même si le temps de l'évaluation de la condition "WHERE" est relativement négligeable, il semble qu'il est très utile de le supprimer!

L'optimisation des requêtes SELECT se fait dans le fichier sql_select.cc et certaines des optimisations effectuées par MYSQL sont :

• Si une dans une requête, un champ "field = constante", alors elle change toute les références de "field" à "constante" : "a=b AND b=c AND c=1" devient "b=1 AND a=1 AND c=1"
• Suppression des conditions constantes ou inutiles : ( 1 = 1, b = b, ..).
• Suppression des conditions impossibles : "item IS NULL" alors que "item" ne s'annule jamais.
• Retourne "Impossible WHERE" ou MySQL détecte rapidement les commandes SELECT impossibles (WHERE 1 = 2) et ne retourne aucune ligne.
• Suppression des parentheses inutiles: ((a AND b) AND c OR (((a AND b) AND (c AND d)))).
• Retourne le COUNT(*) sans "WHERE" d'une table simple directement depuis les informations de la table.
• etc..
  

Mais le plus important à savoir, reste comment MySQL optimise ce genre de requêtes afin de pouvoir en déduire les meilleures façons d'écrire nos requêtes et plus généralement la meilleure façon de concevoir ses bases de données.

Une balade dans le fichier sql_select.cc fera l'affaire :

Une définition étroite de l'OPTIMISEUR : est l'ensemble de routines qui décident quel methode d'exécution le SGBD devrait prendre pour les requetes. MySQL change ces routines fréquemment, ainsi vous devriez comparer ce qui est dit ici avec ce qu'est dans le code source. Pour faciliter les choses, cette description inclut des notes se rapportant à la routine appropriée, par exemple "/sql/select_cc, optimize_cond()". Quand une reqeute est changée en une autre reqeute qui fournit le même résultat, c'est la TRANSFORMATION. La plupart des transformations sont moins évidentes, mais quelques unes peuvent rendre l'exécution plus rapide.

Par exemple, MySQL peut changer :

 SELECT ... WHERE 5 = a

en

 SELECT ...WHERE a = 5

Voici le diagramme montrant la structure de code du handle_select() dans /sql/sql_select.cc, le code du serveur qui manipule les requetes :

   handle_select()
  mysql_select()
    JOIN::prepare()
      setup_fields()
 
    //{{{ L'optimisation commence ici ... 
    JOIN::optimize()       
      optimize_cond()
      opt_sum_query()
      make_join_statistics()
        get_quick_record_count()
        choose_plan()
          /* Trouve la meilleur fcon d'acces aux tables spécifié par l'utilisateur  */
          optimize_straight_join()
            best_access_path()
          /* Trouvez les plans les plus optimaux parmi le sous-ensemble de tous les 
               combinaisons possibles des requetes                                    */
          greedy_search()
            best_extension_by_limited_search()
              best_access_path()
          /* Exécutez une recherche approfondie du plan optimal */
          find_best()
      make_join_select()
    // }}} L'optimisation s'arrete ici

    JOIN::exec()

• Bien que le mot "JOIN" apparaisse, ses routines d'optimiseur sont les memes pour pour toutes les requetes.
• L'identation dans l'expositions du diagramme la methodes d'appel. Ainsi vous pouvez voir que handle_select() appelle mysql_select() qui appelle JOIN::prepare() qui appelle le setup_fields(), et ainsi de suite.
• La première partie de mysql_select() est JOIN::prepare() pour l'analyse du contexte, l'identification des metadata, et la transformations de quelques sous requetes.
• L'optimiseur est JOIN::optimize() et toutes les routines subalternes.
• Quand l'optimiseur finit son travail, JOIN::exec() execute ce que JOIN::optimize() vient de décidé .
• Les routines optimize_cond() et opt_sum_query() font les transformations.
  
• La routine make_join_statistics() remonte toute les informations qu'elle trouve au sujet des index qui pourraient être utiles pour accéder aux tables de la requete.

ALICE AU CORE DE MySQL

Avez vous jamais mis les pieds dans le code du MySQL ?

Moi je trouve que c'est très amusent même. Premièrement, par curiosité parce que en tant que développeur je me demandent toujours a quoi ressemble le core d'un SGBD pareil; deuxièmement et du point de vue technique, la simple lecture du code n'est pas inutile ! Pas de tout!

En fait, MySQL est programmé en C++, qui est un langage de programmation super puissant et trop rapide du coté exécution. Et la Rapidité, Puissance, Stabilité, sont les choses qui hérite MySQL du sont ancêtre. En plus, le C++ est l'un des langages de programmation les plus populaires dans l'industrie informatique et par suite le plus connu chez les développeurs du monde entier. La chose qui rend une balade dans le core de MySQL, loin d'être réservée a une bande d'élites!.

En lisant la documentation des dev (disponible ici[en]) ou le code source, on peut profiter de deux choses :

1. On peut chopper pas mal de trucs signalés par les développeurs de MySQL dans les fichiers sources /* en tant que notes dans les commentaires */ et qui n'existent pas dans le manuel de d'utilisateur final.


2. En lisant les algorithmes utilisés par MySQL, on pourra bien comprendre comment MySQL gère et répond à nos requêtes, et par suite comment les améliorer, les meilleus choses a faire, les raccourcis a prendre, etc...

Le code source de MySQL est disponible pour ceux souhaitant et c'est par ici : http://www.mysql.com

En passant par la

Et en arrivant jusqu'a la

La version "Tarball (in 5.1 both Unix & Windows, tar.gz)" contient le répertoire mysql-5.0.24a par ses 91,4 Mo, 5093 fichiers et 304 répertoires.

The wrong way to upgrade MySQL

Friday, May 19th, 2006

Expect a longer post in the near future on upgrade procedures. For now enjoy this quote from a gentoo user illustrating the worst way to upgrade.

linolium: is there a way to wipe every single table and start over from scratch?
linolium: ( the upgrade from mysql 4 to 5 didn’t go as smoothly as planned
me: did you read the upgrade notes?
linolium: no, I just hoped that portage would be kind enough to do those things for me

http://ebergen.net/wordpress/category/geek/mysql/

Ca me rappel quelqu'un..

America is revealed as one nation under four faces of God

By Tim Reid A survey shows that the way Americans see the Almighty is closely linked to their political beliefs

NINE in ten Americans believe in God but how they vote, or regard the Iraq war, depends on the very different views they have about His personality, according to a detailed survey of religion in the US. It found that Americans hold four different images of God — Authoritarian, Benevolent, Critical or Distant — and these views are far more powerful indicators about their political, social and moral attitudes than any of the traditional categories such as Protestant, Catholic or Evangelical. http://www.timesonline.co.uk/article/0,,3-2355486,00.html

State of Web Development 2006

State of Web Development 2006

Entre le 15 juin et 15 juillet 2006 SitePoint et Ektron ont conduit une enquête sur le developpement Web. Plus de 5000 developpeurs Web ont participés en répondant à une enquête détaillé au sujet de leur travail.

Les résultats montrent l'état de l'industrie aujourd'hui, et aussi les tendances principales que peuvent nous attendre dans les 12 mois à venir.

Télécharger un rapport et une analyse des résultats de l'enquête au format PDF

Your email address:

Pour le plus drill-down d'analyse des résultats, garder un oeil sur leur blog de technologie Web et leur press room.

MySQL Consulting

Aujourd'hui je me suis trouvé face a face avec la base de donneés du plus grand client X de notre société Y (plus de 60 Gega de conneries de tout genre). Ou on ma demandé de livrer une étude statistique qui touche toute la base. Pas seulement ca, mais en cadeau j'ai eu la spec tech du notre chere consultant certifié en pas mal de choses (je suppose), ou il me propose ses best practices en matiere de bases de données et la maitrise de mySql, l'une d'elle consiste de faire des jointures entre des tables de 4 +/- millions de lignes, une autre calcule le cumul des champs par periode et par type d'une table de 70 +/- millions d'enregistrements 4 millions de fois dans la même boucle et a mettre le resultat en une seule table...

... et merci de faire ca vite!!

mais ca va pas la tête ou quoi ??