Est-ce une bonne idée d'indexer le champ datetime dans mysql?

137

Je travaille sur la conception d'une grande base de données. Dans mon application, j'aurai de nombreuses lignes par exemple, j'ai actuellement une table avec 4 millions d'enregistrements. La plupart de mes requêtes utilisent la clause datetime pour sélectionner des données. Est-ce une bonne idée d'indexer les champs datetime dans la base de données mysql?

Select field1, field2,.....,field15
from table where field 20 between now() and now + 30 days

J'essaie de faire en sorte que ma base de données fonctionne correctement et que les requêtes soient exécutées correctement

De plus, quelle idée pensez-vous que je devrais avoir pour créer une base de données à haute efficacité?

mysql indexing

— Jaylen
source

Quoi field 20?

— AlikElzin-kilaka

Réponses:

164

MySQL recommande d'utiliser les index pour diverses raisons, y compris l'élimination des lignes entre les conditions: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

Cela fait de votre colonne datetime un excellent candidat pour un index si vous comptez l'utiliser fréquemment dans des requêtes. Si votre seule condition est BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 30 DAY)et que vous n'avez pas d'autre index dans la condition, MySQL devra effectuer une analyse complète de la table sur chaque requête. Je ne sais pas combien de lignes sont générées en 30 jours, mais tant que c'est moins d'environ 1/3 du nombre total de lignes, il sera plus efficace d'utiliser un index sur la colonne.

Votre question sur la création d'une base de données efficace est très large. Je dirais simplement de s'assurer qu'il est normalisé et que toutes les colonnes appropriées sont indexées (c'est-à-dire celles utilisées dans les jointures et les clauses where).

— Pilules d'explosion
source

Merci pour l'explication. Cela aide vraiment. Je suis sûr que j'aurai plus de filtres. Je veux juste m'assurer que l'indexation du champ datetime est une bonne idée ou non car nous pouvons avoir une date en double. mais vous répondez expliqué :) Merci

— Jaylen

+1 pour 'ceux utilisés dans les jointures et les clauses where'. Une bonne règle de base pour une stratégie d'indexation. Évident maintenant, j'y pense, mais je ne m'étais pas venu à l'

— esprit

Mais si vous interrogez les données avec une plage de dates , telle que la plage de données allant de "2017-01-01 11:20" à "2018-01-03 12:12", cela ne rend pas la SELECTrequête plus rapide même si j'ai indexé la date timecolonne. .. index rend la requête rapide lorsque j'utilise l' equalopération .. Ai-je raison?

— user3595632

Que diriez-vous si l'interrogation des champs datetime avec des fonctions d'heure comme DAY (datetime) ou HOUR (datetime). L'index aidera-t-il ou gênera-t-il dans ce cas?

— cronoklee

salut @Explosion Pills, si je n'ai besoin que d'interroger la base de la table sur l'année et le mois, obtiendrai-je de meilleures performances si j'ai créé une nouvelle colonne avec seulement l'année et le mois, puis l'indexe, au lieu de créer directement un index de la colonne datetime ? Comme ça, je crée une colonne dont la valeur est comme 201801.

— Woods Chen

Ici, les tests effectués par l'auteur ont montré que l'horodatage unix entier est meilleur que DateTime. Notez qu'il a utilisé MySql. Mais je pense que quel que soit le moteur de base de données que vous utilisez, la comparaison des entiers est légèrement plus rapide que la comparaison des dates, donc l'index int est meilleur que l'index DateTime. Prenez T1 - temps de comparaison de 2 dates, T2 - temps de comparaison de 2 entiers. La recherche sur un champ indexé prend environ O (log (lignes)) temps parce que l'index est basé sur un arbre équilibré - il peut être différent pour différents moteurs de base de données, mais de toute façon Log (lignes) est une estimation courante. (si vous n'utilisez pas de masque de bits ou d'index basé sur r-tree). La différence est donc (T2-T1) * Log (lignes) - peut jouer un rôle si vous effectuez votre requête souvent.

— Baurzhan
source

Je vous remercie. Je pensais à cela comme une option mais je ne savais pas comment l'aborder. Je crois que vous avez absolument raison, les entiers sont toujours plus rapides.

— Jaylen

Mieux? Je doute qu'un horodatage unix soit meilleur dans tous les cas. Oui, stocker un entier est généralement plus rapide que stocker une chaîne, mais qu'en est-il de toutes les fonctions DateTime que MySQL expose? Leur mise en œuvre vous-même aurait un effet négatif sur les performances ou les fonctionnalités.

— Greg du