BOnjour,
Est-il possible de faire un index partiel sur une champ date time
en effet je souhaite que l'index ne retienne que aaa-mm-jj (sans les heurs, minutes ...)
Est ce possible ? si oui comment svp ?
Version imprimable
BOnjour,
Est-il possible de faire un index partiel sur une champ date time
en effet je souhaite que l'index ne retienne que aaa-mm-jj (sans les heurs, minutes ...)
Est ce possible ? si oui comment svp ?
Bonjour,
C'est possible avec le mot clef KEY_PART utilisé dans l'instruction CREATE INDEX mais uniquement sur les colonnes de type (var)char.
Et ça n'est pas forcément utile, ça dépend du but recherché
Voici un extrait de la documentation MySQL V8.0 (KEY_PART est applicable aussi avec la V5.7)
Pièce jointe 536030
cf. https://dev.mysql.com/doc/refman/8.0...ate-index.html
merci
mais c'est sur le champ datetime que j'espérais faire une clef partielle, tant pis
OK mais pourquoi vouloir faire cet index partiel, quel est le but recherché ?
j'utilise un champ datetime, j'ai pas mal de requetes qui se base sur ce champ, mais que sur la partie date (aaa-mm-dd)
je souhaite donc indexé ce champ uniquement sur la partie aaaa-mm-dd pour accélerer mes requetes SELECT
mon champ est actuellement indexé mais ça ne sert à rien "tant donné que chaque valeur de datetime est unique (à cause de millisecondes)
Il suffit d'utiliser l'opérateur BETWEEN et votre index sera éligible et efficace, sous réserve qu'il soit filtrant bien sûr ;)
Pas besoin d'index sur une partie de la colonne donc :)
ok, jsuqu'à présent j'utilisais
.... table.datecrea>= datefiltredeb AND table.datecrea<=datefiltrefin...
BETWEEN est donc plus efficace que ci-dessus ?
La plupart du temps, l'optimiseur choisira exactement la même stratégie avec BETWEEN ou la combinaison > et <, à part peut être pour de très vieilles versions de SGBD :weird:
Mais, comme mentionné précédemment, si la plage de dates de la sélection n'est pas filtrante, par exemple si elle correspond à 25% des lignes de la table, alors l'usage de l'index n'a pas d'intérêt et l'optimiseur choisira plutôt un index-scan ou un table-scan selon qu'il y a ou non un index dit "couvrant". Dans les deux cas, c'est un parcours séquentiel de la totalité.
Salut à tous.
Non car la colonne date+time est de type numérique. Plus précisemment, un nombre en seconde qui débute le 1er janvier 1970 à 00 h 00 min 00 s.Citation:
Envoyé par saluts92
Décomposez votre colonne date+time en deux colonnes séparées, l'une étant "date" et l'autre étant "time".Citation:
Envoyé par saluts92
On ne dit pas champ mais colonne. Ce n'est pas une colonne de type "datetime" mais plutôt de type "timestamp".Citation:
Envoyé par saluts92
Pas vraiement. Les deux écritures produisent le même résultat.Citation:
Envoyé par saluts92
Ce que vous avez fait est correcte.
Je n'ai toujours pas compris votre problème.
Avez-vous un problème de performance ?
@+
"On ne dit pas champ mais colonne" on dit aussi champ
"Avez-vous un problème de performance ?"
Oui, sur notre back-office nous avons un formulaire de statistiques, et je souhaite optimiser les requetes SQL (une 15aine) qui se base surtout sur les dates (aaammjj ou aaaamm ou jj)
je sais que l'on pourrait séparé les statistiques, mais bon, ce n'est pas ce que le "patron" veut
Bonsoir saluts92
En fait non : Artemus24 a raison. Bien que le terme "champ" soit souvent rencontré, il est impropre concernant les SGBDR. Ce terme peut être utilisé pour une zone de saisie d'un formulaire ou pour une zone d'édition d'un état ou d'affichage sur un écran. Dans une base de données, il y a des colonnes (au niveau physique ou logique, c'est à dire dans les tables) ou des attributs (au niveau conceptuel).Citation:
Envoyé par saluts92
Si vous avez besoin d'aide pour optimiser vos requêtes, il faut publier les requêtes concernées ainsi que la description exacte des tables et de leurs index.Citation:
Envoyé par saluts92
Vous pouvez aussi utiliser "explain" qui analysera pour vous la stratégie d'accès choisie par l'optimiseur, c'est toujours d'un grand secours ;)
Attention, dans les SGBD, une date c'est une date, c'est à dire stockée dans sa totalité : siècle + année + mois + jour.
Optionnellement vous pouvez choisir un type dateheure ou timestamp qui permet de stocker non seulement la date, mais aussi l'heure, voire les micro ou nanosecondes selon le SGBD.
Mais dans aucun SGBD, la date ne peut se résumer au jour, ou à l'année+le mois
Il ne faut pas confondre le type d'une colonne (date, caractère, caractère variable, décimal etc...) et son format de restitution.
C'est important car les fonctions liées aux types date ne sont applicables qu'aux colonnes de ce type, tout autre type requiert des transformations hasardeuses quant au contenu et qui dégradent très fortement les performances, surtout si on les applique sur les prédicats de filtrage et/ou de jointure
C'est pourquoi j'insiste : publiez les requêtes concernées et le DDL create table et create index ;)