Discussion :

[pacmann]

...Note : Utilisation de SQL Server 2005

Effectivement, c'est plutôt SQL Server qui importe dans ce cas...

alaks : ce que je voulais dire un peu plus haut, c'est simplement que si je devais me taper un écran (client lourd où léger) avec 50k lignes, j'aurais du mal à les exploiter d'un seul coup...
Si c'est vraiment juste pour visualiser, on pourrait imaginer un système de pagination où tu envoies tes paquets de IN selon le besoin...

[alaks]

Effectivement, c'est plutôt SQL Server qui importe dans ce cas...

Oui effectivement j'utilises bien SQL server, mais j'étais parti pour chercher l'equivalent du load init de mysql sous sql server.
Donc merci pour l'idée Antoun
Dés demain j'essai avec un bulk insert et je croise les doigts..

alaks : ce que je voulais dire un peu plus haut, c'est simplement que si je devais me taper un écran (client lourd où léger) avec 50k lignes, j'aurais du mal à les exploiter d'un seul coup...
Si c'est vraiment juste pour visualiser, on pourrait imaginer un système de pagination où tu envoies tes paquets de IN selon le besoin...

Oui je serai tout à fait d'accord avec toi dans la mesure ou si c'était moi qui contrôlait le client, or c'est pas le cas. Tous ce que je dois faire c'est lors d'un appel à cette fonction de recherche, je dois retourner tous les résultats.

[Antoun]

désolé, j'étais sur l'idée qu'on faisait du MySQL (ça doit être l'âge).

Merci à ylarvor d'avoir rétabli et donné l'équivalence !

[alaks]

Impressionant le bulk insert, j'ai fait un bulk insert de 5 000 lignes ca a mise 0 secondes (enfin qq millisecondes qd mm); c'est terrible.
Par contre j'ai pas tester le temps que ça prendrait pour créer un fichier de 5000 lignes.

Donc ac cette méthode j'ai pu faire une jointure:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select idref from maTable A, tableCree B, where A.photoid = B.photoid

mais je crois qu'il me manque un index ou qq chose parce qu'elle mets 5 secondes. Je vais voir ça un peu plus en détails.

[Antoun]

mais je crois qu'il me manque un index ou qq chose parce qu'elle mets 5 secondes. Je vais voir ça un peu plus en détails.

Sur tableCree.photoID.

[alaks]

A un moment j'ai révé, mais finalement un peu moins

J'ai fait un script qui effectue toutes les opérations allant de la création de fichier à la jointure en passant par un bulk voici les résultats pour une liste de valeurs de 47000 :

* les temps sont en millisecondes enfin je crois

Temps création fichier : 0.0156
Temps création table : 0.156
Temps bulk insert: 1.01 ( en moyenne 0.550)
Temps création index : 0.260
Temps jointure : ... 8,9

Total : 8.921

Temps du drop : 0.01

C'est dommage que la jointure prennent autant de temps . (jointure entre un ensemble de 3 000 000 et 47 000 valeurs)

[Antoun]

Tu as bien un index sur maTable.idref ?

[Waldar]

Que raconte l'explain plan ?

[alaks]

je retrouve espoir j'y suis presque

Pour la jointure j'utilisais un index cluster, je me suis dit que c'etait pas terrible vu la quantité de données. Et le plan d'execution montrait que 100% des op se faisait sur l'index cluster(index scan).
Alrs j'ai créer un index non cluster sur id et j'ai ajouter idref en colonne incluse (un index bp plus petit que le précedent). La jointure se fait maintenant en 4.76 s, la total des opérations se fait en 5.56s.
Je suis sûr que ca peut être encore amélioré...

En tout cas merci pour vos conseils, qui m'ont été très bénéfique.

[Waldar]

Idéalement il ne faudrait que IdRef dans l'index sur votre table principale, dans ce cadre précis, mais d'autres contraintes font que c'est peut-être impossible.

[pacmann]

Idéalement il ne faudrait que IdRef dans l'index sur votre table principale, dans ce cadre précis, mais d'autres contraintes font que c'est peut-être impossible.

Euh, idRef est la seule colonne dans le select et id la colonne de jointure... je crois que l'index est parfait, non ?

En tous cas, ça m'intéresserait aussi de voir l'explain plan....

[EDIT]

Tiens, je suis peut être complètement à côté de la plaque, mais je testerais bien avec un index sur la TableCree.
Peut être qu'il provoquerait un merge sort join qui irait plus vite...

[alaks]

Voici le plan d'execution :



Comme vous pourrez le voir, il y a un index sur la table TableCree.

Outre l'amélioration des perfs, il me restera plus qu'à tester si c'est possible de faire la même chose avec une table temporaire. Parce que mes tests ont portés jusqu'à présent sur une table "normale".

[Waldar]

Compte-tenu que la TableCree va être intégralement parcourue, il ne faut pas l'indexer.

Mais je ne sais pas si celà va modifier le plan d'exécution ou accélerer la requête.

[pacmann]

Si, ça va changer le plan :
S'il peut obtenir la donnée de l'index, il envisagera plus facilement le MERGE JOIN, car les données sont triables facilement.

Sinon, à mon avis, il aura plus de chance de choisir HASH JOIN...