Kioob

Pour la première question oui, dès lors qu'il y a des indexes qui correspondent à la clause en question. Un "explain" de la requête indique le nombre d'enregistrements que MySQL parcours dans chacune des tables ; c'est assez pratique pour vérifier l'utilisation (ou non) des indexes. Pour ce qui est du cas du forum, il faudrait regarder comment procèdent des forums "biens faits" tels que Phorum (ou phpBBv3 je suppose, bien que je n'ai jamais regardé le code). Pour ma part, je ne suis pas certain que mettre en place une solution différente de LIMIT soit nécessaire dans ce cas : avoir plusieurs milliers de messages par sujet me semble assez rare non ? A l'époque où je maintenais mon propre forum, la requête qui posait problème était plutôt celle qui listait les sujets d'une catégorie. Là le volume peut être très conséquent, et c'est un affichage très fréquent avec peu de mise en cache possible... il faut donc trouver une solution adaptée. Pour ce cas particulier je pense que j'essayerais de maintenir un champ "position" (indexé), en prenant garde qu'il soit le moins souvent possible mis à jour, et que les éventuels problèmes de doublon ne soient pas bloquants. Ainsi il suffirait de deux requêtes "simples" : (j'ai remplacé l'arobase par un dollars, vu que le forum colle des _AT_ partout ) - select $pos := max(position) from sujet; - select XXXX from sujet where position between $pos - 20 and $pos order by position desc; Reste à maintenir efficacement ce champ "position". Là encore, ce n'est qu'une approche possible "à chaud". Je pense que les gros forums se sont penché sur la question depuis longtemps.

Il n'y a pas vraiment d'autre manière d'écrire le "LIMIT" : c'est l'approche qui n'est pas optimale. Pour se faire une idée, prend un livre sur une étagère et fait la liste des 20 premiers mots après les 2743 premiers. Pour pouvoir les lister tu vas être obligé de lire un grand nombre de "pages", et de compter les mots de chacune d'elle... cela va te prendre beaucoup de temps. Ce qu'il faut donc c'est un moyen de très fortement réduire l'espace de recherche. Par exemple si je te dis que la page n°240 de ton livre commence par le mot 2509, tu vas gagner beaucoup de temps non ? Le problème est donc de trouver une autre approche pour arriver à ce résultat. Mais ça, ça dépend essentiellement de tes données, et ce n'est pas toujours possible. C'est pour ça qu'à moins d'avoir un volume de données conséquent, on se contente bien souvent d'une approche via LIMIT qui bien que "pas super propre" est très simple à mettre en place. Pour le coup je me rend d'ailleurs compte que le lien que je t'ai indiqué ne répond même pas à cette problématique, mais à celle du "nombre de pages". Dans toutes les solutions proposées dans cet article le "LIMIT" est toujours utilisé. Désolé pour la confusion. Bref, prenons un de tes cas : "Sélection des X derniers lignes d'une table SQL" et admettons qu'il s'agit d'une table "news" dont tu veux extraire les 5 dernières entrées. Cette table contient 3 ans d'historique et quelques 800 enregistrements. Soit en moyenne 22 entrées par mois. Le champ "dateNews" est évidement indexé. Avec un "order by dateNews desc limit 5", MySQL va être amené à travailler sur la totalité des 800 enregistrements (1) ; puis n'en conservera que 5. Pour l'aider on peut indiquer une clause de type "where" et indiquer de ne chercher que parmi les enregistrements des 30 derniers jours ("where dateNews > curdate() - interval 30 day order by dateNews desc limit 5"), et MySQL ne travaillera cette fois que sur la vingtaine d'enregistrements concernés, soit 40 fois moins de données à traiter (jointures, tris, etc). L'inconvénient c'est qu'on suppose ici qu'il y aura toujours au moins 5 news par période de 30 jours, sinon cela ne fonctionnera pas... C'est une des approches possibles, il y en a évidement d'autres, mais chacune est spécifique aux données qu'il y a derrière. (1) ce n'est pas forcément vrai pour un cas aussi simple, mais peux très vite varier selon le tri, les clauses et les jointures.

Index ou pas, quand il y a 50 millions d'enregistrements dans la table, un "LIMIT" a tendance à pédaler sec.

Hello, en fait pour être exact les IP sont des nombres entiers de 32bits justement, bien qu'on voit plus souvent la notation "lisible pour l'homme". Il existe d'ailleurs des fonctions en PHP pour faire la conversion : http://fr.php.net/ip2long Mais le stockage sous forme de chaine peut parfois être plus pratique.

bonjour, essaye d'enlever l'espace après le COUNT : SELECT repertoire, COUNT(*) FROM compteur GROUP BY repertoire

Hello, un peu de lecture à ce sujet, ou du moins sur la pagination de manière générale : http://www.mysqlperformanceblog.com/2008/0...nated-displays/

Exactement. C'est du "95% percentile", la méthode de comptage des hébergeurs : http://fr.wikipedia.org/wiki/95e_centile Les "pics" sont donc exclus du calcul. Le prix. Car même à 900 HT/mois le surplus de BP, OVH reste très compétitif.

Bonsoir, le message d'erreur en question veut dire que ton $result ne correspond pas à un résultat "valide" de mysql_query(). Bref, il y a probablement eu une erreur durant l'exécution de ta requête SQL (ce qui ne m'étonnerait pas vu ton code SQL ). Affiche donc les erreurs de MySQL, tu auras le message d'erreur exact de MySQL. Il te suffira ensuite de corriger ta requête.

Merci pour vos encouragements Arlette : promis dès que je mets un site en place, je t'en ferais part

En fait je trouve RoundCube surtout beaucoup plus léger/simple de configuration. Mais c'est peut être affaire de goût.

Ouf De rien donc, et à la prochaine à Lyon alors

Je ne connais pas suphp (lui préférant fastcgi+suexec), mais pour le dossier au mauvais endroit tu devrais pouvoir régler cela avec un lien symbolique. Par exemple : ln -s /usr/share/horde /var/www Ensuite il faut modifier la configuration d'Apache afin qu'il aille chercher horde à cet endroit. Pour ce qui est du user id, via fastcgi+suexec ce sont les droits du wrapper qui sont vérifiés, donc je ne pourrais guère t'aider plus quant à la manière de contourner (fichier de config, changer le propriétaire des fichiers, etc). Mais je suppose que d'autres personnes ici seront plus familiarisées, surtout qu'il me semble que SuPHP est maintenant installé en standard sur les distribs OVH. Pour ce qui est de la webmail à proprement parlé, pour ma part je préfère de loin RoundCube :wink: bon courage.

Le propriétaire d'un "exécutable" n'est pas forcément lié au propriétaire du fichier en question. Une très grande partie des fichiers qu'on trouve sur un serveur a pour propriétaire "root" ; c'est notamment le cas de tous les exécutables "communs", des fichiers de configuration, et des fichiers de documentation. Surtout pour tout ce qui est dans "/usr/share" justement. Bref, ce n'est pas lié, et il y a vraiment très peu de chance pour que Horde nécessite les droits root pour tourner.

Hello, tu es certain que Horde tourne sous l'utilisateur root ? Ca me semble vraiment curieux, d'autant plus qu'il fonctionne aussi avec un PHP "classique" en module Apache et dans ce cas il tourne sous l'utilisateur Apache, www-data, ou encore nobody...

Tes données actuelles en base semblent corrompues ; dans quand tu fais tes tests tu recrées bien un jeu de données propre ? Y a pas 36 étapes : 1) tu crées une table avec un interclassement UTF-8 2) via une connexion UTF-8 (ton script ou phpmyadmin par exemple) tu ajoutes tes données dans la table (sans chercher à faire la moindre conversion, on est en full utf8). A partir de là, via n'importe quelle connexion en UTF-8 (ton script ou phpmyadmin par exemple), tu devrais pouvoir récupérer correctement tes données, toujours sans la moindre conversion. EDIT: pour le "character_set_server", il ne sert qu'à déterminer le charset utilisé par défaut quand non précisé. Perso je ne le modifie pas.

'lut, chez Gandi tu peux booter à partir de n'importe quelle image ; et il me semble qu'OVH a prévu ça depuis un moment également. Sinon de manière générale si l'OS fourni une installation exécutable depuis un autre OS (comme c'est le cas de Debian par exemple, via debootstrap) ; tu peux l'installer chez n'importe quelle hébergeur.

Pour les connexions simultannées tu devrais regarder via un "show processlist" dans ces heures, il y a de fortes chances que le problème vienne de verrous (plein de requêtes à l'état "Locked"). Dans ce cas il peut s'agir de requêtes manquant d'index et qui font donc "inutilement" appel à des tables temporaires. J'en ai sûrement déjà parlé ici, je maintiens des sites avec un trafic bien supérieur à cela et qui ne dépassent que rarement les 5 ou 10 connexions simultanées. Mais chaque site est différent donc ça peut aussi être justifié. Coté matériel sinon si tu cherches quelque chose de très souple pour le moment tu peux aussi regarder du coté de l'hébergement Gandi. Par contre c'est évidement plus cher que du low cost.

Je ne l'ai pas utilisé, mais ce serait idiot de la part d'un soft cherchant à réduire la taille des fichiers de convertir du 8bits en 32bits, non ?

J'ai mal compris ou bien ici tu disais que ta table de test était en latin1 ? Quand tu sélectionnes une base de données tu obtiens la liste de ses tables, et là il y a une jolie colonne "Interclassement"... Pour changer ça, tu sélectionnes la table, puis tu vas dans Opérations et de là tu changes l'Interclassement.

Et tu as bien passé ta table en UTF-8 ? Parce que les caractères russes sont typiquement le genre de caractères qui sautent lors d'un passage à l'iso-8859-1.

Si tu dois utiliser utf8_decode, c'est que tu as effectivement un soucis. Nous pour passer la connexion MySQL en UTF-8 on utilise ça : SET CHARACTER SET UTF8

Pour n'avoir aucune perte, il faut qu'à aucun moment de la chaine les données soient converties en ISO. Donc tes tables doivent être en UTF-8, ainsi que ta connexion, et ton affichage ; ainsi les données seront en UTF-8 du début à la fin. La "base" en UTF-8, il me semble que ça ne sert que de valeur par défaut lors de la création d'une nouvelle table. Ca sert peut être aussi pour les tables temporaires d'ailleurs, aucune idée. Ca c'est ce que phpMyAdmin affiche... il annonce fièrement qu'il se connecte en UTF-8, mais ce n'est pas le cas de ton script à toi.

Euh au contraire phpMyAdmin est même en UTF-8 par défaut. Si les données ne sont pas rendues correctement à l'affichage, c'est très probablement qu'il y a un soucis en base. Edit : un test "simple", insérer en base un mot avec des accents du genre Adélaïde. Puis faire un select sur cette table avec pour clause where champ = 'adelaide' (sans aucun accent donc). Si MySQL retrouve le champ, c'est que les données sont correctement encodées.

re, il faut te connecter à MySQL en UTF-8 également, sinon les données sont traitées comme de l'ISO à l'insertion, et converties de l'UTF-8 à l'ISO lors du select.

Oui, regarde l'exemple 2 de la doc. Ca fait partie de la "magie de PHP", une fonction qui a un nom très explicite et un comportement fortement différent en fonction des paramètres... super simple à débuger.