Reprise du message précédent :
j'ai mis une balise < captain obvious proof

sans la fermer, le post est vide

ALTER TABLE user ADD INDEX(email);
ALTER TABLE ad ADD INDEX(email);
 
Ca devrait aller mieux là

Ouais, c'est ce que j'ai dit plus haut déjà.

 
De toute façon, en SQL, jamais de jointure sur des champs non indexés !

C'est ptet captain obvious proof, mais apparement c'est pas jocebug proof

[b]

Edit :

<captain obvious proof>
question

comprends pas là.

Non
Si ton équivalent est dire: "les résultats remontés par les deux requêtes sont identiques" alors oui.
Néanmoins le sgbd ne traite pas la requête de la même façon.
Avec distinct il applique un filtre, avec group by il fait une agrégation (qui est "légèrement" plus  lente).
Dans le plan de ton optimizer tu n'auras pas non plus la même chose.
Donc je réfute cette équivalence
 
 

<captain obvious proof>

Muriel, menteuse.

je retest, en fait mes settings d'encoding etait different...

ah ouais

edit: j'avais mon browser (safari) sur encoding Western Iso latin, pas default, pour un test et j'avais pas enlevé le settings, en postant ça a merdé le truc, mais pourquoi je sais pas.

 
Oui, bien sur. Par exemple: dans schema.yml, defini deux class Parent et Enfant, avec dans enfant un champs parent_id. Et bien ce con transforme parent_id en un champs de type varchar alors que l'id de parent est un integer. Et si tu lui indique le type, alors il perd completement de vue que c'est une reference, et donc tu dois tout redefinir a la main, super pratique...

Euh oué nan mais regarde son BBCode aussi Poster un message vide tout le monde sait le faire depuis lgtps avec ta technique

Ah ouais merde c'est la classe

 
Ça prend combien de temps d'ajouter un index sur des grosses tables ? (plusieurs dizaines de milliers d'enregistrement).
 
Car ma base en local ne contient qu'un échantillon de la base du serveur, qui elle est toujours en prod actuellement.
 
Aucun risque, aucun changement pour le site actuel ? Ça risque pas de cause quelque problème que ce soit ? Sinon y'a le chef qui risquerait de pas être content
 
Je n'ai jamais eu à ajouter un index sur une base aussi grosse. Mes index sont tjs créé à la création des tables, ou quelques temps après si je me rends compte que j'ai oublié... mais jamais sur une table de plusieurs dizaines de milliers d'enregistrement
 

Grosse comment les tables (en taille physique j'entends ) ?
T'as testé déjà sur tes tables en local pour voir si ça marche mieux ?
Que donne l'explain avec les 2 index en question ?

Ouaip j'ai testé en local :
(5 873 total, traitement: 0.0244 sec.)

Pour la taille physique des tables, je ne peux pas te dire, je n'y ai pas accès. (pour info elles ne sont pas super énorme non plus ... ça doit tourner à ~10.000 enregistrements pour la table "ad" et ~ 30.000 pour la table user)

Pour le EXPLAIN :

je cherchais pas a le faire hein
 j'avais juste oublier de changer l'encoding dans mon browser, et je vois pas en quoi ça pose probleme d'ailleurs

 
J'ai bien compris oui J'expliquais juste à theredled que tu n'avais pas utilisé sa "tecnique" pour poster un message vide

ah ok, pardon

/30000 c'est pas mal comme optimisation

Tu peux le faire en prod ça devrait pas poser de souci (faut juste garder à l'esprit que pendant la durée du ALTER, la table est lockée en écriture par MySQL)

Ok merci
 
Je lui dirai de faire ça tard ce soir alors

Dites les gros, j'aurais besoin d'un "disque de progression", vous savez les pétÿtes barres disposées en cercle qu'on voit généralement lors du chargement d'un composant web (via Ajax, ou alors en Flache) avec une barre en noir et les autres en gris.
Vous auriez des idées de recherche sur Gougueule (ou, mieux, un site où y en a plein) ?

Genre ça : http://www.loadinfo.net/

En plus j'étais déjà allé sur ce site, je l'avais juste pas bouquemarqué

moi j'aime bien celui la http://www.ajaxload.info/

Ah yaisse, aussi ouais

Pourquoi ça :

Et ça

ça donne pas le même résultat.
Je remplace le onChange par un onKeyDown et ça m'affiche plus rien

Le onchange ne s'active que lorsque le champ perd le focus

Effectivement , j'ai remplacé par un onKeyUp

Pourquoi une sous-requete (simple) dans la partie SELECT d'un SELECT peut diviser les perfs par 6 (alors que j'ai un LIMIT 15)

Si il était pas con il devrait exécuter cette sous-requete 15 fois seulement

Sous-Select = caca sous mysql je crois

limit ça limite les résultats après le fetch.
Donc grosso modo il remonte tout et ensuite ne prends que le morceau qui l'interesse.
 
Tu peux pas jointer sur la-dite sous-requête plutot?

J'ai fait mieux : 2 requetes SQL
Enfin nan : 16 (1+15) requetes mais ça divise le temps par 3.5 déja (en fait la perte de perf c'était pas 6 c'était 4 )

Jointer sur la sous-requete qqch me dit que ce serait long nan ?

J'aimerais tant savoir utiliser explain

je persiste en disant que ça sent le paté tout ça
Généralement quand ce genre de chose va plus vite dans le code qu'en sql, c'est aux choix:

• une conception de base pourrie
• une "administration" de la base inexistante (entre autre absence d'index)

ça dépend
Mais cela doit être plus rapide que le sous-select dans le select

en même temps l'explain de mysql, il est super limité...
 

Ouais bah bilan, 40 secondes avec ta méthode contre 1.6 avec ma méthode et 6.8 avec sous-select

Absolument pas, pas cette fois

Ca c'est plausible

C'est possible d'ajouter une propriété à une définition CSS ?
 
Par exemple si dans mon fichier CSS j'ai ça :
 
div.toto{ background-color: red; }
 
Pouvoir rajouter un "color: blue" à div.toto, dans la feuille de style, avant le chargement du contenu de la page...