optimisation recherche dans une table [Résolu]

[clod83]

bonjour

j'ai une table qui enregistre les données au fur et a mesure et sans les supprimer(donc pas de récupération de la place avec une autre donnée qui ne serais pas séquentielle)

je sais donc ou commence année1 , année2 , année3 etc

si je veut rechercher sur année2 je peut avec offset ne pas balayer année1 pour rien ; mais comment arreter la recherche en arrivant a offset année3 pour ne pas balayer le reste de la table?

je pourais partitionner la table ok
mais une question avec la partition garde t'on la table d'origine?

de plus pourquoi partitionner avec mysql ?
si je cré une table annéexxxx au début de chaque année cela ne reviens t'il pas au mème?

[SLE]

crée un index sur année...

[clod83]

je dois comprendre une table avec des pointeurs sur la table principale ou se trouvent les enregistrements de l'année convoitée ? ok c'est valable

mais ça fais une table de plus par an a gerer ;

je vais peut etre me rabatre l'option une table par an directement

mais d' une maniere générale j'aurais quand meme aimé trouver une façon de sortir de la recherche lorsque j'ai trouvé mon enregistrement.
en effet si ce que je cherche est le deuxieme enregistrement d'une table pourquoi tester les 1000 suivants ....

[SLE]

un index, ce n'est pas une table en plus par année. C'est un moyen d'optimiser les recherches sur un champ d'une table pour éviter un parcours de toute la table. Il n'y a pas de table supplémentaire à créer.

[clod83]

oui je suis entierement d'accord mais cela ne me dit pas comment je sort de ma recherche une fois toutes mes infos trouvées;

je vais me retrouver avec mes années triées en ordre avec l'index mais je vais parcourir celui-ci entierement

de plus pas besoin d'index dans mon cas car les données sont déjas dans l'ordre

[skuatamad]

je vais me retrouver avec mes années triées en ordre avec l'index

Non sans clause ORDER BY aucune garantie, même si avec toutes les lignes stockées dans l'ordre le résultat aura souvent l'air ordonné, mais je le redis aucune garantie sans ORDER BY.

mais je vais parcourir celui-ci entierement

Non le SGBD gère de part la structure de l'index comment le lire, il ne lis pas tout l'index.

de plus pas besoin d'index dans mon cas car les données sont déjas dans l'ordre

Tout dépend du nombre de données par année et du nombre d'année, si la requête sur une année renvoie un faible pourcentage des lignes de la table alors l'index sera pertinant, sinon non.

de plus pourquoi partitionner avec mysql ?
si je cré une table annéexxxx au début de chaque année cela ne reviens t'il pas au mème?

Une table partitionnée ça reste une seule table, avoir plein de tables préfixées par l'année est une bidouille très contraignante niveau modélisation et dev.

[clod83]

je pense que je vais me tourner vers la partition ;je vais étudier ça.
mais pendant que j'y suis otez moi d'un doute est-ce que peut procéder comme ca:

- on partitionne qu"une seule fois (ça reste sur le serveur)

- pour l'année courante qui par nature est modifiée j'utilise offset j'usqu'a la
fin du fichier
- si je recherche sur année précédante j' utilise les tables partitionnées

- a la fin de l'année je fais un ALTER TABLE ou une recréation

[skuatamad]

Je ne connais pas particulièrement les spécificitées liées au partitionnement surtout sur MySql, je te laisse regarder dans la doc :
Chapter 17. Partitioning

Et d'autres pourront sûrement mieux répondre à tes questions.

[clod83]

lorsque j'utilisais des fichiers j'avais une liste ordonnée dans laquelle je faisais une recherche dicotomique(ultra rapide) pour trouver mon premier enregistrement. je suivais ensuite la liste en séquence jusqu'a mon critère de fin et je sortais de la recherche.

je vais tacher de faire pareil.
je garde ID de la primaryKey du début des différentes années

et je fais

Code :

 WHERE primaryID BETWEEN 'ID année recherchée' AND ' ID année suivante

le moteur de recherche doit bien savoir qu'il travaille sur un index unique et doit proceder un peut comme je faisais; et arreter ses recherches une fois la limite atteinte.

ainsi pas de partition et c'est simple a gerer
si je n'ai pas de réponse sur cette maniere de faire, je créerais une grosse table et je ferais un test de temps avec et sans partition .j'aimerais bien en avoir le coeur net

[SLE]

Pourquoi vouloir passer par la PK et mémoriser les id correspondant à une date ?
Vous créez un index sur la date et ça fera la même chose.
Le moteur de la db va utiliser l'index pour récupérer les infos, sans parcourir tout séquentiellement.

Code :

SELECT ... FROM LaTable WHERE LeChampDate BETWEEN data1 AND date2

Faut pas chercher à réinventer la roue !

[clod83]

ben oui mais pourquoi faire simple si on peut faire compliqué ? ou serais le plaisir ?

disons que je suis partis sur un truc tordu et compliqué au départ et que je n'ai plu vu l'évidence apres

merci