유닉스 타임 스탬프를 부호없는 정수로 저장하면 어떤 이점이 있습니까?

Question

나는 DATETIME 대 TIMESTAMP 대 INT 사이에 프로 또는 콘트라의 다른 토론을 시작하고 싶지 않습니다. (이미 Using MySQL's TIMESTAMP vs storing timestamps directly과 같은 기사를 읽었습니다.)

가끔 INT 데이터 형식을 사용하여 유닉스 타임 스탬프를 데이터베이스에 저장합니다. 그 이유는 내 응용 프로그램에서 날짜 및 시간 계산이 유닉스 타임 스탬프 (예 : 세션 시간 초과 및 토큰 만료)를 사용했기 때문입니다. 또한 WHERE 절의 정수 값을 간단히 비교할 수있을 때 DATETIME을 사용하는 것보다 데이터베이스에서의 데이터 선택이 빠릅니다. 이 4 바이트가 실제로 작은 크기로 인해 디스크와 메모리에 저장 공간을 절약 할 수있는 10 백만 행 (최대 1 억)이있는 테이블은 거의 없습니다.

는 Y2K38 문제에 관해서는, 나는 UNIX_TIMESTAMP있는 MySQL PHP의 time() 향후 64 비트 값을 반환되므로, 응용 프로그램 자체에서 뭔가를 변경할 필요가 없을 것, 가정 (그래서 희망). 요점은, 나는이 모든 정수형 타임 스탬프를 부호없는 정수 (즉, INT이 아닌 BIGINT)로 MySQL에 저장했습니다. 물론, 지금은 부호없는 정수의 타임 스탬프는 올해 2106에 오버플로,하지만 2038

내 질문보다 조금 더 시간 : UNIX_TIMESTAMP 자체가 2038 이후에 작동 할 것이라고 가정까지 MySQL과/또는 PHP에 문제가있을 수 이 타임 스탬프가 MySQL에서 부호없는 정수로 저장되면 2106? (과 논쟁하지 마십시오 : 2038까지, 나는 더 이상 접촉하지 않는 응용 프로그램의 관점에서이 문제를 명확히 할 것을 해결하기 위해 많은 시간이있을 것이다)

편집 : 질문이 와서 때문에 : 저는이 칼럼에 현재 타임 스탬프 만 저장합니다. 생년월일도 미래 날짜도 저장하지 않습니다. 현재의 타임 스탬프 만 있으므로 2038 년 이후에 작동하는지 명확히하고 싶습니다.

Answer 1

UNIX_TIMESTAMP()를 둘러싼 가정은 큰 것입니다.

현재 UNIX_TIMESTAMP는 더 이상 32 비트보다의 INT의 저장이 작동하지만 당신은 UNIX_TIMESTAMP (INT64)의 구현이 어떻게 작동하는지에 대해 뭔가를 알고하지 않는 한 다음,

mysql> select unix_timestamp("2038-01-19"); 
+-------------------------------+ 
| unix_timestamp("2038-01-19") | 
+-------------------------------+ 
|     2147468400 | 
+-------------------------------+ 
1 row in set (0.00 sec) 

mysql> select unix_timestamp("2038-01-20"); 
+------------------------------+ 
| unix_timestamp("2038-01-20") | 
+------------------------------+ 
|       0 | 
+------------------------------+ 
1 row in set (0.00 sec) 

하려고하면 0을 반환 질문은 사실보다 더 추측입니다.

이것은 당신이하는 모든 정수 연산이 여전히 64 비트 정수로 유효하므로 만료 된 세션 (타임 스탬프 + 타임 아웃 < (64 비트에서 1970 년 이후 초))을 찾는 데 여전히 효과가 있음을 의미합니다. from_unixtime() 및 unix_timestamp() 함수에 의존 할 수 있는지 여부는 솔루션이 64 비트로 올라갈 지 아니면 다음 20 년이되는 세상이 새로운 에포크를 설정할지 결정합니다.

아무도 모릅니다.