Discussion :

[saluts92]

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 ?

[escartefigue]

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

[saluts92]

merci

mais c'est sur le champ datetime que j'espérais faire une clef partielle, tant pis

[escartefigue]

OK mais pourquoi vouloir faire cet index partiel, quel est le but recherché ?

[saluts92]

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)

[escartefigue]

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

[Artemus24]

Salut à tous.

Est-il possible de faire un index partiel sur une champ date time

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.

en effet je souhaite que l'index ne retienne que aaa-mm-jj (sans les heurs, minutes ...)

Décomposez votre colonne date+time en deux colonnes séparées, l'une étant "date" et l'autre étant "time".

mon champ est actuellement indexé mais ça ne sert à rien "tant donné que chaque valeur de datetime est unique (à cause de millisecondes)

On ne dit pas champ mais colonne. Ce n'est pas une colonne de type "datetime" mais plutôt de type "timestamp".

BETWEEN est donc plus efficace que ci-dessus ?

Pas vraiement. Les deux écritures produisent le même résultat.

Ce que vous avez fait est correcte.
Je n'ai toujours pas compris votre problème.
Avez-vous un problème de performance ?

@+

[saluts92]

"On ne dit pas champ mais colonne" on dit aussi champ

[saluts92]

"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

[escartefigue]

Bonsoir saluts92

"On ne dit pas champ mais colonne" on dit aussi champ

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).

"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

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.
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