Comment les horodatages Unix doivent-ils être stockés dans des colonnes int?
J'ai une table de journalisation qui contiendra des millions d'écritures pour des raisons statistiques. Toutes les colonnes sont des clés étrangères int. Je vais également ajouter une colonne d'horodatage pour chaque ligne. Étant donné que DATETIME prend 8 bits - j'utiliserai int(10) unsigned pour réduire de moitié l'espace de stockage (et l'index sur cette colonne).
Cependant, je me demande quand cette colonne ne fonctionnera plus. À 19 h 14 min 07 s le 19 janvier 2038, la valeur 9 999 999 999 sera un problème pour les horodatages UNIX - mais un entier non signé dans MySQL ne peut contenir que 4 294 967 295 et l'horodatage 4294967295 affiche un nombre non valide dans mon PHP application.
Alors qu'est-ce que cela signifie? La fin du stockage des horodatages int dans MySQL se fera-t-elle en 2021 car elle ne peut pas se rendre jusqu'à 9999999999?
Réponse:
- 2147483647 est 2038 (pas 9999999999) donc il n'y a pas de problème.
unsignedn'est pas nécessaire car 2147483647 s'intègre parfaitement dans un int MySQL signé.
Les horodatages UNIX standard sont un entier 32 bits signé, qui dans MySQL est une colonne "int" régulière. Il n'y a aucun moyen de stocker 9 999 999 999, car c'est bien en dehors de la plage de représentation - le plus haut un 32 bits peut être de 4 294 967 295. Le plus haut 32 bits signé est de 2.147.483.647.
Si/quand les horodatages UNIX passent à un type de données 64 bits, vous devrez utiliser un "bigint" MySQL pour les stocker.
Quant à int(10), le (10) portion est uniquement à des fins d'affichage. MySQL utilisera toujours un 32 bits complet en interne pour stocker le numéro, mais n'affichera que 10 chaque fois que vous effectuez une sélection sur la table.