[MySQL] BETWEEN sur une table de 250.000 entrées minimum

[Argorate]

Oxman : si le where est corect (WHERE (map2.x >= 10 AND map2.x <= 40) AND (map2.y >= -30 AND map2.y <= 0))

30*30*4 = 3600 int

EDIT holy:

oui, j'ai fait pareil de mon coté, clé primaire double sur (x,y).
Sinon, si c'est donnée sont pas trié on s'en fou completement puisque derriere il n'a qu'a récup les choses:

while($row = fetch)
{
$dataMap[$row['x']][$row['y']] = $row;
}

et là il a tout dans l'ordre, et il s'économise un trie en SQL a chaque requête... même si c'est pas très long, c'est toujours ça^^

[Ter Rowan]

Sinon la structure de ta table indique des "KEY" pas des "INDEX", donc je voulais être sur...

y a un truc qui me perturbe du coup... J'étais persuadé que KEY définissait un index (du coup un peu synonyme entre les deux)

Je me plante ?

[Holy]

EDIT holy:

oui, j'ai fait pareil de mon coté, clé primaire double sur (x,y).
Sinon, si c'est donnée sont pas trié on s'en fou completement puisque derriere il n'a qu'a récup les choses:

while($row = fetch)

{

      $dataMap[$row['x']][$row['y']] = $row;

}

Y a rien qui dit que les champs y seront dans l'ordre, pas plus que les x. Y a pas de tri automatique sur les tableaux php.

$array[2] = 'hop';

$array[1] = 'hip';



print_r($array);// Affichera d'abord $array[2]

Donc au mieux, il faut ajouter deux ksort() là dedans, comme ceci :

while($row = fetch) {

  $dataMap[$row['x']][$row['y']] = $row;

  ksort($dataMap[$row['x']]);

}

ksort($dataMap);

[Argorate]

Oui mais vu qu'on parcourt les x et les y linéairement dans des boucles imbriqués, on est assuré de l'ordre. A moins que tu utilises une autre méthode de parcours?

[Holy]

Oui mais vu qu'on parcourt les x et les y linéairement dans des boucles imbriqués, on est assuré de l'ordre. A moins que tu utilises une autre méthode de parcours?

En général j'aurais tendance à utiliser un foreach sur les tableaux plutôt qu'un for. Mais tu as raison, si on utilise un for, pas besoin d'order by.

Cela dit, si on utilise d'emblée la boucle de la requête, là y en a besoin .

[niahoo]

les gars vous vous prenez la tête pour rien (même si ce que vous dites est vrai), attendez de voir comment il s'en sert de ses données.

De plus, est ce qu'un tri en PHP va plus vite qu'un Order By sur mysql ? je n'en suis pas sur.

[srm]

Ça dépend le volume de données et si on a un index sur la colonne de tri :p

[php_addict]

Ça dépend le volume de données et si on a un index sur la colonne de tri :p

le volume est vraiment minime pour cette requete qui m'interesse:

count($donnees) = 961

SELECT map2.x,

		map2.y,

		map2.contenu,

		map2.x1,

		map2.y1

FROM map2

 

WHERE (map2.x >= 10 AND map2.x <= 40) AND (map2.y >= -30 AND map2.y <= 0) 

	ORDER BY map2.y ASC, map2.x ASC ");



$donnees=$result->fetchall(PDO::FETCH_ASSOC);

Ma clause WHERE ne change jamais mais:

quand je récupère x et y -->Time : 23.8ms ( SELECT map2.x, map2.y )
quand je récupère x1 et y1 -->Time : 177ms ( SELECT map2.x1, map2.y1 )

c'est incompréhensible pour moi que le temps varie à ce point selon que l'on récupère telles ou telles données sans jamais changer la clause

pour info j'ai besoin de x1 et y1 comme coordonnées alternatives à x et y car ma map est un plan projeté

[Myrina]

tu as essayé avec deux index unique (en plus de la primary key)?:
- un index sur X et Y
- un index sur X1 et Y1

Je m'avance peut être mais je verrai bien comme explication de la différence de temps que dans le premier SELECT, la lecture de l'index suffit pour obtenir les informations alors que dans le second, après la lecture des index, il faut extraire les tuples correspondant de la table.

[Argorate]

Si tu met en pièce jointe le sql de la table et des données de celle-ci, on pourrait tester et comparer de notre coté si tu veux?