Discussion :

[fpouget]

Bonjour,

J'ai dans une table 59842 enregistrements avec pour chacun les coordonnees X, Y (latitude et longitude).

J'ai une requete du type :

Code :

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

SELECT name, latitude, longitude FROM cities WHERE longitude>= 0 and longitude <=10 and latitude >=40 and latitude <=50

Comment opimiser mes indexs ?
Dois-je creer un index pour latitude et un pour longitude, ou vaut-il mieux creer un multi-index sur ces des champs?

Cardinalite de l'index latitude : 1870
Cardinalite de l'index longitude : 2601
Cadinalite du multi-index : 59842

Merci

PS mon SGBD est Mysql, mais j'imagine que cela pas d'incidence pour ce genre d'index ....

[rsc]

Dans la mesure où tes 2 champs interviennent indépendamment, je créerais deux index.

Petite remarque : pourquoi n'écris-tu pas :

Code :

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

WHERE (longitude BETWEEN 0 and 10) and (latitude BETWEEN 40 and 50)

Je ne pense pas que ça change quoi que ce soit à la requête, mais c'est tellement plus lisible !

[Médiat]

Je suis de l'avis de rsc, et comme là tu utilises tes champs de façon dépendante l'un de l'autre (ce qui semble naturel pour des coordonnées), je créerais donc un index double (Longitude, Latitude).

[fpouget]

Médiat, rsc,

Merci pour vos reponses, mais comme vous vous contredisez j'ai un peu de mal a comprendre ... Pouvez-vous dire en quoi vous ete d'accorr et en quoi vous ne l'etes pas ?

[Médiat]

Je donnais raison à rsc sur son raisonnement, mais pas sur sa conclusion, tu utilises tes champs de façon dépendante l'un de l'autre donc il te faut un index composé. Sinon le moteur risque d'utiliser l'un des index simples puis de parcourir complètement ce sous ensemble pour chercher les lignes qui vérifient la deuxième condition
Si le premier champ était extrêmement discriminant, un index composé serait inutile.

De toute façon, le moyen le plus simple est de faire les tests, il faut quelques secondes pour créer des index...

[cortex93]

Si le premier champ était extrêmement discriminant, un index composé serait inutile.

N'est-ce pas plutôt le contraire, si le premier champ est extrêmement discriminant, alors il ne resterait plus bcp de donnée à parcourir dans la deuxième clé. Dans le cas contraire, si l'index composé revient à du 1 pour 1, il n'ait plus utile puisqu'il y aura autant de possibilité dans la deuxieme clé que dans l'index de la deuxieme colonne seul.
Me trompe-je ?

[Médiat]

N'est-ce pas plutôt le contraire, si le premier champ est extrêmement discriminant, alors il ne resterait plus bcp de donnée à parcourir dans la deuxième clé

Comme il ne reste pas grand-chose à parcourir, pas besoin d'index...

Pour être clair
Table avec 1 millions de lignes
Si le premier critère permet d'en sélectionner 20, inutile d'avoir un index composé.
Si le premier critère permet d'en sélectionner 100 000, il est intéressant (vital) d'avoir un index composé

[rsc]

Je défends mon point de vue :
Latitude et longitude sont employées de manière indépendante, même si évidemment elles le sont souvent simultanément. C'est-à-dire que latitude et longitude ne dépendent pas l'une de l'autre, et qu'il n'y a pas de hiérarchie entre les deux. Ici, un index composite ne me semble pas intéressant.
De plus, s'agissant de nombres réels, le 2ème critère ne sera en fait pratiquement pas classé : par exemple, si tu choisis comme index "latitude + longitude", ne seront classés entre eux sur la longitude que les points qui ont exactement la même latitude, c'est-à-dire virtuellement aucun pour peu que tes latitudes soient précises !

[Médiat]

La seule chose dont je sois certain :

De toute façon, le moyen le plus simple est de faire les tests, il faut quelques secondes pour créer des index...

J'ai eu à optimiser un problème très similaire il y a peu, mais il est vrai que les données n'étaient pas des réels...

[rsc]

Si tu fais des tests, tiens-nous au courant des résultats, ça m'intéresse !

[SQLpro]

En fonction de la sélectivité l'index sera utilisé ou pas.. Le basculement se fait avec une sélectivité de l'ordre de 10%. En dessous index, au dessus full scan.
Ré écrivez votre requête avec des BETWEEN ce sera plus efficace en optimisation !

Code :

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

1
2
3
4
SELECT name, latitude, longitude 
FROM   cities 
WHERE  longitude BETWEEN 0  AND 10 
  AND  latitude  BETWEEN 40 AND 50

A +

[fpouget]

Ben j'avais fait qqs tests avant de poser la question en fait et comme je n'avais rien de concluants ....

Un leger avantage tout de meme au double index, mais la difference est tellement faible que je ne peux pas l'affirmer.


Merci pour vos reponses