Merci JP, j'espère contribuer à ton site exemplair 
 De Laurent Decorps - Lundi 11 Mars 2002 à 17:50

J'ai fait ce petit article pour permettre à chacun de pouvoir optimiser ses requêtes. Ce sont nos hébergeurs mutualisés vont être contents !
Sérieusement, je passe pas mal de temps sur le forum de phpInfo et je pense que cet article va pouvoir aider la majorité des 'posteurs'.

Aux puristes et aux pro, j'adresse un petit message : en effet cet article n'est pas exhaustif, oui il doit y avoir quelques points qui méritent d’être discutés, oui en effet, un tel sujet pourrait faire l’objet d’un bouquin de 800 pages… J’espère que les anglophones iront directement à la source (l’article contient autant de liens que possibles vers la documentation officielle) et que les pros me pardonneront les raccourcis empruntés ici.

  Re: Merci JP, j'espère contribuer à ton site exemp 
 De Théo :o) - Mardi 12 Mars 2002 à 09:40

Merci Laurent ;o)

Un sujet qui restait toujours plus ou moins flou, je pense que chacun d'entre nous qui avait pris le soin de lire un minimum la documentation avait une petite et vague idée de comment optimiser ses requêtes et son utilisation de MySQL. Personnellement j'avais acquis quelques petites (et mauvaises)habitudes de travail ...

Ton article les a mis en exergue, et je t'en remercie ! Plus encore, j'avais une petite analyse et un MCD à faire ce matin, gràce à toi mon MPD sera nickel cette après midi ;o)

  Faudra m'expliquer 
 De Sebastien Buysse - Mardi 12 Mars 2002 à 00:17

"pour un auto-increment, utiliser MEDIUMINT UNSIGNED qui permet d'identifier 16 777 215 enregistrements en ne consommant que 3 bits. "

3 bits? :-D

  Re: Faudra m'expliquer 
 De Laurent Decorps - Mardi 12 Mars 2002 à 00:27

Oui ... par enregistrement...
On peut identifier 16 777 215 enregistrements avec une clé de 3 bits soit 3 * 16 777 215 bits pour la clé.

  Re: Faudra m'expliquer 
 De Sebastien Buysse - Jeudi 14 Mars 2002 à 18:25

Mince alors, c'est qu'il insiste...

3 bits = 1->8, de 000 à 111!

1 bit = 0 ou 1.

Ils sont forts si ils arrivent a identifier >16 millions d'enregistrements avec 8 valeurs!

Très fort :)

  Re: Faudra m'expliquer 
 De Sebastien Buysse - Jeudi 14 Mars 2002 à 18:28

Excellent, ca a été corrigé dans l'article... Quand même hein :)

  Merci :) 
 De Laurent Decorps - Jeudi 14 Mars 2002 à 20:46

Ouais là j'avoue j'ai un peu fais l'amalgame !

  Beuh? 
 De Sebastien Buysse - Mardi 12 Mars 2002 à 00:20

"un mot tout de même sur l'unique différence entre un champ de type BLOB et un champ de type TEXT : BLOB est sensible à la casse alors que TEXT est insensible à la casse. "

La j'ai pas capté... Pourquoi un TEXT n'as pas sensible a la casse? C'est nouveau? Si c'est vrai, faudra me dire dans quel cas...

  Re: Beuh? 
 De Laurent Decorps - Mardi 12 Mars 2002 à 00:42

select * order by CHAMP pour un text peut rendre
A, b, C
alors que pour un BLOB, ça donnerait A, C, b

  Re: Beuh? 
 De Sebastien Buysse - Jeudi 14 Mars 2002 à 18:25

Ah?

Autant pour moi :)

  Et les formes normales ? 
 De Mikaël BARBERO - Mardi 12 Mars 2002 à 07:23

Pourquoi n'abordes-tu pas le sujet des formes normales permettant déjà d'avoir une bonne base propre ?
Surtout que la 3ème n'est pas compliqué a comprendre ni a mettre en oeuvre sur mysql (alors que la 5ème est casi irréalliste avec)...

  Re: Et les formes normales ? 
 De Laurent Decorps - Mardi 12 Mars 2002 à 08:26

Ouais j'ai hesité longement... J'ai le sentiment que c'est déjà un poil trop abstrait pour le cadre de cet article. Mais c'est vrai qu'avec un bon exemple...
Cela pourrait faire l'objet d'un autre article ?

  Mise à jour de la doc Officielle 
 De Laurent Decorps - Mardi 12 Mars 2002 à 09:01

La doc chez http://www.mysql.com/doc/ vient tout juste d'être mise à jour... j'espère que ce que je raconte là est toujours valable !
A priori oui, il y a simplement plus de détails et plus de renvois.

  Bravo ! 
 De Thomas Dubois - Mardi 12 Mars 2002 à 20:59

Vraiment un superbe article, qui m'a permis d'y voir plus clair pour les optimisations .
Il ne manque plus qu'un article complet sur les differents types de jointure, et ca sera parfait :)

  Table HEAP 
 De Théo :o) - Mercredi 13 Mars 2002 à 09:03

Une url en français ....

http://dev.nexen.net/docs/mysql/charge.php?doc=zc

  Ca aussi c'est dur a avaler... 
 De Sebastien Buysse - Jeudi 14 Mars 2002 à 18:30

"PHP ne faisant pas de différence entre 0 et NULL, autant déclarer tous les champs NOT NULL, on gagne ainsi 1 bit par champ et par enregistrement"

Désolé, mais quand je lis ca, je m'étrangle...

  Je suis encore allé un peu vite là dessus ? 
 De Laurent Decorps - Jeudi 14 Mars 2002 à 20:43

Je te remercie de ta pugnacité !

Je suppose que tu lis l'anglais ?
Zieute le troisème point :
http://www.mysql.com/doc/D/a/Data_size.html
Si c'est toujours pas clair pour toi, on en rediscute !

  Re: Je suis encore allé un peu vite là dessus ? 
 De Sebastien Buysse - Jeudi 14 Mars 2002 à 20:51

Ce n'est pas parce qu'ils disent que tu y gagnes une valeur que ca ne reste pas une abération...

Sérieux, c'est à deux doigts de dire "fais toi un fichier binaire toi même, ca ira plus vite"

Et la ils parlent de réduire la taille, pas d'augmenter les performances ni de rester cohérent, pour moi c'est une situation extrème à n'utiliser qu'en cas de problème immense, mais pas a conseiller comme ca pour tout, c'est à la limite du délire :)

:)

  Re: Je suis encore allé un peu vite là dessus ? 
 De Laurent Decorps - Jeudi 14 Mars 2002 à 21:16

Ils disent quand même 'It makes everything faster and you save one bit per column' ...
Et puis je trouve qu'avec PHP, ça devient très utile : comme il n'y a aucun moyen de tester qu'un champ est null, autant essayer de trouver une valeur de type 'unknown' en guise de null. Celle-ci, tu peux la tester dans ton script.
Je convient que c'est un peu limite en théorie mais bon, des champs NULL, c'est pas top à gérer dans une base de donnée, (c'est mon expérience professionnelle qui parle) alors tout compte fait, coller les champs not null quand c'est possible permet, à mon sens, d'être cohérent, de sauver de la place, d'optimiser sa base quoi !

  Re: Je suis encore allé un peu vite là dessus ? 
 De Sebastien Buysse - Jeudi 14 Mars 2002 à 21:54

Désolé, mais le NULL est très facile a gérer, professionellement ou pas... Et t'es vraiment sur que PHP supporte pas le NULL, j'ai un doute quand même... Mais la je mettrais pas ma main a couper.

Et si c le cas, ca m'attriste quand même de voir qu'on massacre une DB parce que le langage qu'on utilise ne supporte pas cette fonctionnalité, c'est contraire à toute méthodologie, et quid du jour ou tu voudras remplacer PHP par autre chose.

Non, sérieux, faut pas pousser les gens à ne jamais utiliser le NULL parce que MySQL trouve que ca va un peu plus vite.

Enfin soit, c'est ton avis, mais cet article est lu par des centaines de gens, et probablement des débutants, je ne trouve pas cela très sage de leur dire de ne pas utiliser le NULL...

  Re: Je suis encore allé un peu vite là dessus ? 
 De Laurent Decorps - Jeudi 14 Mars 2002 à 22:05

Espérons qu'ils lisent également cette discussion et qu'ils choisiront en fonction de nos arguments réciproques...

  Merci 
 De Benjamin Chalande - Mercredi 20 Mars 2002 à 23:47

Mon niveau est encore un peu léger pour tout comprendre, mais cela répond a beaucoup de questions déjà.
Merci !

  question 
 De Benjamin Chalande - Vendredi 22 Mars 2002 à 10:18

Je voudrais juste une explication suplémentaire: pourquoi favoriser les champs var aux varchars.
Cela est-il vrai tout le temps?

  Re: question 
 De Laurent Decorps - Vendredi 22 Mars 2002 à 12:02

Bein tu vois, le sujet a été discuté dans les commentaires (merci Sébastien Buysse)...
Les char valent le coup pour les tables qui subissent de nombreuses modifications (delete / update). Moi, concrètement, pour tout ce qui est traitement, je banni les champs à longueur variable.
Les champs varchar et text sont utilisés pour les tables qui stockent des info à afficher (de type news).
Il y a 2 inconvénients majeurs à l'utilisation des champs 'fixes' :
- 255 caractères max
- la place gaspillée au sein de l'enregistrement.
à toi de mesurer l'impact de ces 2 restrictions.
C'est good ?

  Re: question 
 De Benjamin Chalande - Vendredi 22 Mars 2002 à 12:38

thanx.

  SGBD pas SGBDR 
 De Arnaud Limbourg - Jeudi 25 Avril 2002 à 17:42

Tu indiques "[...] merveilleux SGBDR[...]"

Mysql est un SGBD, pas un SGBDR ...

  Re: SGBD pas SGBDR 
 De Laurent Decorps - Jeudi 25 Avril 2002 à 18:04

Ouais, bein avec l'arrivée des clés étrangères, on pourra considérer MySQL comme un SGBDR ...

  Re: SGBD pas SGBDR 
 De Arnaud Limbourg - Jeudi 25 Avril 2002 à 21:50

il a encore quelques progrès a faire ;)))

ps: je n'avais pas de smiley mais mon premier message n'était pas aggressif ;)))

  range ou index ? 
 De Arga Balala - Samedi 7 Septembre 2002 à 16:01

hello,

j'ai une requête très simple sur une base.
Il s'agit de compter le nombre de lignes ayant la colonne status dans un ensemble de valeurs donné.
J'ai un index sur status.

Si j'écris :
EXPLAIN SELECT COUNT(*) FROM subscriber WHERE status = 'N' OR status = 'R'

j'obtiens type=ranged et j'ai bien using index.

si j'écris (elle n'est pas équivalente, il faudrait lister les status, mais c'est pour simplifier l'exemple):
EXPLAIN SELECT COUNT(*) FROM subscriber WHERE status != 'N' AND status != 'R'

j'obtiens type=index et j'ai toujours using index.
J'ai un souvenir qui me vient de je ne sais où, qui m'incite à ne pas utiliser OR quand je peux. Est-ce vrai en général, et est-ce vrai dans le cas de cette requête ?

Très bon article par ailleurs :)

  Re: range ou index ? 
 De Laurent Decorps - Dimanche 8 Septembre 2002 à 12:08

Range est une lecture par intervalle de l'index... tu ne dois donc pas te demander si tu dois utiliser l'une ou l'autre des syntaxe, garde ton range, pas de soucis !
Sinon, :
EXPLAIN SELECT COUNT(*) FROM subscriber WHERE status not in (N', 'R')
c'est plus simple je trouve.

@+