Reprise du message précédent :
que ce soit une grosse table ou plusieures petites, le volume d'index aura la meme taille. Je pense meme que plusieurs petits est plus efficace lorsque ca devient vraiment tres gros.

ben deja une table par cat, ca evite la clause "where cat=XXX", donc ca optimise la requete, ensuite ca fait un index de moins sur la cat "cat" puisque qu'elle n'existe pas, donc aussi un gain de place.

De toute facon c'est inévitable non?
Une table postforum avec 20 miullions de lignes serait très très grosse!
Si ou fait select post12321 from postforum la requete mettrait plusieurs minutes à ettre executée non?

non pas du tout

sais tu ce que c'est un index ?

20 millions de lignes pour une table c'est pas énorme hein.

J'ai pourtant fait un test.
1 million de lignes, genre
id, nom, groupe
 
J'ai mis un index sur groupe
Quand je fais SELECT id,nom,groupe WHERE groupe=$_GET['groupe'] la requete met presque une minute à s'executer
 
Sois j'ai mal fait ma requetes, sois j'ai mal mis mon index.

tu as combien de groupe ?
 
faut mettre un "limit" aussi, car si tu recupere des millions de ligne, c'est sur que ca va etre lent.
 

Donald Knuth: "Premature optimization is the root of all evil".

 
j'ai une petite question, c'est a propos de mes requetes, j'aimerais savoir s'il est préférable de faire des requêtes à rallonge ou plusieurs requêtes simples?
 
De plus je me suis toujours posé la question sur la bonne façon de m'y prendre, exemple sur cette requête :
 

 
- Niveau guillemets, c'est bon ou il est possible de simplifier ou autre?
- Dans cette requete, j'ai des champs du genre cats.last_poster et topics.last_poster qui ont la même variable à insérer, y a t'il un moyen de grouper pour les deux?
- Est il préférable de faire un requete pour chacune des tables à mettre à jour, qu'est ce qui est le + rapide?  
 
Merci de m'éclairer ne serait-ce qu'un minimum là dessus J'ai des doutes à propos de ce que je fais...

J'ai une trentaine de groupe.
Mais j'avais oublié de préciser, j'ai fais ce select et ca m'affiche une trentaine de lignes cherchées dans un million  
C'est plus clair

 
met "explain" devant ta requete pour voir ce que ca donne.
 
Sinon, meme avant que tu me donne ces resultats, on peut faire un petit calcul:
 
1000 000 / 30 = 33 333
 
Donc en moyenne, il te faudra parcourir 33 000 lignes a chaque requetes avec un index, cela depend combiens d'enregistrements il y a dans tes groupes.
Sans index, il aurait été possible qu'il parcour les millions d'enregistrements s'il trouve moins de 30 resultats.
 
donc, on peut comprendre la lenteur de ta requete.
 

Fabien, tu connais la recherche par dichotomie?

t'es sur que l'optimiseur de mysql marche comme ca ?
a mon avis, si l'index sert persque a rien, il parcourt toute la table.
tu devrais tester avec une colone ou il y a trés peu d'enregistrements different.
 
Mais bon, j'aimerai bien voir son explain, pour voir ce qui ralenti sa requete et comment reagit l'optimiseur de mysql.

Non mais je veux dire, il va pas se casser le cul à parcourir tout l'index s'il peut utiliser une technique qui lui permettra de parcourir quelques éléments de l'index seulement

ben reste a voir si cette technique existe dans l'optimiseur de mysql.
C'est un peu comme si je donnais une solution de faire deux requete et que toi tu arrive derriere en me disant "les requetes imbriqués tu connais? " .  

Normalement, l'index devrait lui donner immédiatement les 30 valeurs ou groupe=$_GET['groupe'], le résultat devrait être persque immédiat  

ben la dichotomie est une technique assez accessible pour ne pas dire de base Maintenant ils peuvent avoir mis au point un truc plus rapide, je ne sais pas

Ah en fait je viens de voir ce qui n'allait pas.
Je mettais AND accept='oui' dans la clause where.  
J'avais pas mis d'index sur acept

pourquoi ne pas utiliser un entier (1 ou 0) pour ce genre de colonnes bolléennes  ?

 
quand tu auras tout dit
 
Sinon, je viens de faire un tests sur une table(id, nom, groupe) de 1 200 000 lignes.
Req sans index : 1.7s
Création de l'index : 26s
Req avec index : 0.046s
 
Par contre :

 
J'espère pour lui que c'est au moins un ENUM.

 
Rajoute un ORDER BY quelconque, le mythe s'écroule

 
   
Si le ORDER BY s'applique sur les 30 lignes retournées, ça va pas être beaucoup plus lent.

Bah tested and disaprooved maintes fois

Le ORDER BY s'applique à la totalité de la table.
 
Si tu fais un
SELECT nom FROM matable ORDER BY nom DESC LIMIT 30
Si tu as 300.000 noms, il va bien classer d'abord l'intégralité des noms pour te donner tes 30 noms en Z (par exemple), il ne va pas faire un tri dans les 30 premiers résultats.

D'où la grosse baisse de perfs

 
Dans ce cas là, ok, mais c'est un problème de LIMIT pas d'ORDER BY
 
Si tu fais SELECT nom FROM matable WHERE groupe=2 ORDER BY nom et qu'il n'y a que 30 résultats, ça va pas changer grand chose qu'il y est un ORDER ou pas.

parce que un ENUM c'est mieux

Comment remédier a cela alors?

 
pour ce genre de colonne, ou j'ai le choix entre 1 et 0 j'utilise TINYINT(1), c'est pas la meilleure solution?
 
(Etant donné que je suis nul en optimisation de tables Mysql, bah euh je voulais savoir ... )

 
Ca je savais pas
 
'fin j'y mettrai quand même 0 et 1 comme valeurs, juste pour faciliter le code après...

 
Faut pas utiliser de ORDER BY avec du LIMIT quand ça demande trop de ressource.
 
Sur un forum par exemple, il ne faut pas pour afficher les 30 posts de la page x faire :
 
SELECT (....) WHERE (...) ORDER BY datePost LIMIT 30*x, 30*(x+1)
 
mais ajouter un champ numéro post et faire  
 
SELECT (....) WHERE (...) noPost BETWEEN  30*x AND 30*(x+1)
 
...et gérer les suppressions de post en mettant à jour les noPost.
 

 
Nan. C'est une mise en cache mémoire des informations de la base sous forme structurée (un genre de memcached en plus efficient mais aussi en plus limité).
 

 
Non plus. Les principaux inconvénients de mon bousin, c'est:
1°) trop de code et de couches à maintenir
2°) archi trop complexe et donc chiante à débuguer
3°) archi difficilement distribuable sur plusieurs serveurs en l'état
4°) du code très crade par endroits (genre mon générateur de code)
5°) manque de temps et de motivation pour remettre tout ça au propre (j'ai envie de le passer en opensource mais j'aurais le rouge de la honte au front si on voyait ce que j'ai fait par endroits)

 
pis avec un boinc qui tourne en permanence sur le serveur

First post needs update : my website has changed its location, it's now reachable at http://skyforum.ayzo.net/liste.html !
 
A+

hello
 
why your stats "nedstats" are broken ?
and why you don't have a page to download your board ?
 
thank you

Hello,
 
nedstats is broken 'cause they mailed me about my counter : its was on many pages instead of legally one. strange... so I stopped my account, useless. Webaliser, which is installed over ayzo's server, is more accurate.  
There's no download 'cause I stopped development, and v5 will be out soon...
For v4 downloads, simply check this board : forum.le-node.net
 
A+

De toutes façons, Netstats, ça existe plus, c'est devenu Web4you et ça rajoute des popups au site, bouhhhh...

Shakespear loose, Moliere win....