MySQL에서 datetime 또는 timestamp 데이터 유형을 사용해야 합니까?

질문자 :koni

날짜/시간 또는 타임스탬프 필드를 사용하는 것이 좋으며 그 이유(MySQL 사용)는 무엇입니까?

저는 서버 측에서 PHP로 작업하고 있습니다.

MySQL의 타임스탬프는 일반적으로 레코드 변경 사항을 추적하는 데 사용되며 레코드가 변경될 때마다 업데이트되는 경우가 많습니다. 특정 값을 저장하려면 날짜/시간 필드를 사용해야 합니다.

UNIX 타임스탬프 또는 기본 MySQL 날짜/시간 필드를 사용할 것인지 결정하려는 경우 기본 형식을 사용하십시오. 그런 식으로 MySQL 내에서 계산을 수행할 수 있으며 ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)") 레코드를 쿼리할 때 값의 형식을 UNIX 타임스탬프 ("SELECT UNIX_TIMESTAMP(my_datetime)") PHP로 작업하려는 경우.

blivet

MySQL 5 이상에서 TIMESTAMP 값은 저장을 위해 현재 시간대에서 UTC로 변환되고 검색을 위해 UTC에서 현재 시간대로 다시 변환됩니다. (TIMESTAMP 데이터 유형에서만 발생하며 DATETIME과 같은 다른 유형 에서는 발생하지 않습니다.)

기본적으로 각 연결의 현재 시간대는 서버의 시간입니다. 시간대는 MySQL 서버 시간대 지원에 설명된 대로 연결별로 설정할 수 있습니다.

Nir

저는 항상 행 메타데이터(생성 또는 수정된 날짜) 이외의 모든 것에 DATETIME 필드를 사용합니다.

MySQL 문서에서 언급했듯이:

DATETIME 유형은 날짜 및 시간 정보를 모두 포함하는 값이 필요할 때 사용됩니다. MySQL은 DATETIME 값을 'YYYY-MM-DD HH:MM:SS' 형식으로 검색하고 표시합니다. 지원되는 범위는 '1000-01-01 00:00:00' ~ '9999-12-31 23:59:59'입니다.

...

TIMESTAMP 데이터 유형의 범위는 '1970-01-01 00:00:01' UTC ~ '2038-01-09 03:14:07' UTC입니다. MySQL 버전 및 서버가 실행 중인 SQL 모드에 따라 다양한 속성이 있습니다.

일반적으로 사용되는 TIMESTAMP의 하한선(예: 생년월일 저장)에 도달할 가능성이 큽니다.

scronide

아래 예는 DATETIME 이 변경되지 않은 time-zone to 'america/new_york' TIMESTAMP 날짜 유형이 값을 어떻게 변경했는지 보여줍니다.

 mysql> show variables like '%time_zone%'; +------------------+---------------------+ | Variable_name | Value | +------------------+---------------------+ | system_time_zone | India Standard Time | | time_zone | Asia/Calcutta | +------------------+---------------------+ mysql> create table datedemo( -> mydatetime datetime, -> mytimestamp timestamp -> ); mysql> insert into datedemo values ((now()),(now())); mysql> select * from datedemo; +---------------------+---------------------+ | mydatetime | mytimestamp | +---------------------+---------------------+ | 2011-08-21 14:11:09 | 2011-08-21 14:11:09 | +---------------------+---------------------+ mysql> set time_zone="america/new_york"; mysql> select * from datedemo; +---------------------+---------------------+ | mydatetime | mytimestamp | +---------------------+---------------------+ | 2011-08-21 14:11:09 | 2011-08-21 04:41:09 | +---------------------+---------------------+

더 많은 사람들이 이 유용한 MySQL: Datetime Versus Timestamp Data Types 를 찾을 수 있도록 내 답변을 기사로 변환했습니다.

Vishwanath Dalvi

주요 차이점은 DATETIME은 일정하지만 TIMESTAMP는 time_zone 설정의 영향을 받는다는 것입니다.

따라서 시간대 간에 클러스터를 동기화했거나 미래에 동기화할 수 있는 경우에만 중요합니다.

간단히 말해서: 오스트레일리아에 데이터베이스가 있고 해당 데이터베이스를 덤프하여 미국의 데이터베이스를 동기화/채우면 TIMESTAMP는 새 시간대의 이벤트 실시간을 반영하도록 업데이트되고 DATETIME은 업데이트됩니다. 여전히 au 시간대의 이벤트 시간을 반영합니다 .

TIMESTAMP가 사용되어야 하는 곳에서 DATETIME이 사용된 좋은 예는 Facebook에서 서버가 시간대에 걸쳐 어떤 시간이 발생했는지 확신할 수 없는 곳입니다. 한 번은 메시지가 실제로 전송되기 전에 메시지에 답장했다고 시간이 말하는 대화를 하고 있었습니다. (물론 시간이 동기화되지 않고 게시된 경우 메시징 소프트웨어의 잘못된 시간대 변환으로 인해 발생할 수도 있습니다.)

ekerner

나는 의미론적 기반에서 이 결정을 내린다.

(다소) 고정된 시점을 기록해야 할 때 타임스탬프를 사용합니다. 예를 들어 레코드가 데이터베이스에 삽입된 경우 또는 일부 사용자 작업이 발생한 경우입니다.

날짜/시간을 임의로 설정하고 변경할 수 있는 경우 날짜/시간 필드를 사용합니다. 예를 들어 사용자가 나중에 변경 약속을 저장할 수 있는 경우.

unbeknown

DATETIME 또는 TIMESTAMP 필드를 사용하지 않는 것이 좋습니다. 특정 날짜(예: 생일)를 전체적으로 나타내려면 DATE 유형을 사용하십시오. 시간(일, 주, 월, 년). DATETIME 또는 TIMESTAMP를 사용하는 대신 BIGINT를 사용하고 epoch(Java를 사용하는 경우 System.currentTimeMillis()) 이후의 밀리초 수를 저장하기만 하면 됩니다. 여기에는 몇 가지 장점이 있습니다.

1. 공급업체 종속을 피할 수 있습니다. 거의 모든 데이터베이스는 비교적 유사한 방식으로 정수를 지원합니다. 다른 데이터베이스로 이동하려고 한다고 가정합니다. MySQL의 DATETIME 값과 Oracle이 값을 정의하는 방법 간의 차이점에 대해 걱정하고 싶습니까? 다른 버전의 MySQL에서도 TIMESTAMPS는 정밀도 수준이 다릅니다. 최근에야 MySQL이 타임스탬프에서 밀리초를 지원했습니다.
2. 시간대 문제가 없습니다. 데이터 유형이 다른 시간대에 어떤 일이 발생하는지에 대한 통찰력 있는 설명이 있습니다. 그러나 이것이 일반적인 지식이며 동료 모두가 그것을 배우는 데 시간을 할애할 것입니까? 반면에 BigINT를 java.util.Date로 변경하는 것을 엉망으로 만드는 것은 꽤 어렵습니다. BIGINT를 사용하면 시간대와 관련된 많은 문제가 발생합니다.
3. 범위나 정밀도에 대해 걱정할 필요가 없습니다. 미래 날짜 범위(TIMESTAMP는 2038년으로만 이동)로 인해 단축되는 것에 대해 걱정할 필요가 없습니다.
4. 타사 도구 통합. 정수를 사용하면 타사 도구(예: EclipseLink)가 데이터베이스와 인터페이스하는 것이 간단합니다. 모든 타사 도구가 MySQL과 같은 "날짜/시간"에 대한 이해를 갖고 있는 것은 아닙니다. 이러한 사용자 정의 데이터 유형을 사용하는 경우 java.sql.TimeStamp 또는 java.util.Date 객체를 사용해야 하는지 여부를 Hibernate에서 확인하고 싶으십니까? 기본 데이터 유형을 사용하면 타사 도구를 쉽게 사용할 수 있습니다.

이 문제는 데이터베이스에 금전 가치(예: $1.99)를 저장하는 방법과 밀접하게 관련되어 있습니다. Decimal을 사용해야 합니까, 아니면 데이터베이스의 Money 유형을 사용해야 합니까, 아니면 Double 중에서 최악을 사용해야 합니까? 이 3가지 옵션은 모두 위에 나열된 것과 같은 이유로 끔찍합니다. 해결책은 BIGINT를 사용하여 돈의 가치를 센트로 저장한 다음 사용자에게 가치를 표시할 때 센트를 달러로 변환하는 것입니다. 데이터베이스의 작업은 데이터를 저장하는 것이지 해당 데이터를 해석하는 것이 아닙니다. 데이터베이스(특히 Oracle)에서 볼 수 있는 이러한 모든 멋진 데이터 유형은 거의 추가되지 않으며 공급업체 종속으로 가는 길을 시작합니다.

user64141

1. TIMESTAMP DATETIME 대해 4바이트 대 8바이트입니다.

2. 타임스탬프는 데이터베이스에서 더 가볍고 더 빠르게 인덱싱됩니다.

3. DATETIME 유형은 날짜 및 시간 정보를 모두 포함하는 값이 필요할 때 사용됩니다. YYYY-MM-DD HH:MM:SS 형식으로 DATETIME 값을 검색하고 표시합니다. 지원되는 범위는 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 입니다. TIMESTAMP 데이터 유형의 범위는 1970-01-01 00:00:01 UTC ~ 2038-01-09 03:14:07 UTC 입니다. MySQL 버전 및 서버가 실행 중인 SQL 모드에 따라 다양한 속성이 있습니다.

4. DATETIME 은 일정하지만 TIMESTAMP time_zone 설정의 영향을 받습니다.

Vivek S

TIMESTAMP는 DATETIME의 경우 4바이트와 8바이트입니다.

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

그러나 scronide가 말한 것처럼 1970년의 하한선이 있습니다. 하지만 미래에 일어날 수 있는 모든 일에 좋습니다. ;)

Alex

응용 프로그램에 따라 다릅니다.

사용자가 뉴욕의 서버에 타임스탬프를 설정하여 상하이에서의 약속을 고려하십시오. 이제 사용자가 Sanghai에서 연결할 때 도쿄의 미러링된 서버에서 동일한 약속 타임스탬프에 액세스합니다. 그는 원래 뉴욕 시간에서 오프셋된 도쿄 시간으로 약속을 보게 됩니다.

따라서 약속이나 일정과 같이 사용자 시간을 나타내는 값의 경우 datetime이 더 좋습니다. 서버 설정에 관계없이 사용자가 원하는 정확한 날짜와 시간을 제어할 수 있습니다. 설정 시간은 설정 시간이며 서버의 시간대, 사용자의 시간대 또는 일광 절약 시간이 계산되는 방식의 변경에 영향을 받지 않습니다(예, 변경됩니다).

반면에 지불 거래, 테이블 수정 또는 로깅과 같은 시스템 시간을 나타내는 값의 경우 항상 타임스탬프를 사용합니다. 시스템은 서버를 다른 시간대로 이동하거나 다른 시간대의 서버를 비교할 때 영향을 받지 않습니다.

타임스탬프는 데이터베이스에서 더 가볍고 더 빠르게 인덱싱됩니다.

ianaré

2016 + : 내가 조언하는 것은 Mysql 시간대를 UTC로 설정하고 DATETIME을 사용하는 것입니다.

최신 프론트엔드 프레임워크(Angular 1/2, react, Vue,...)는 UTC 날짜 시간을 현지 시간으로 쉽고 자동으로 변환할 수 있습니다.

추가로:

• 이제 DATETIME을 현재 시간 값 으로 자동 설정할 수 있습니다. MySQL Datetime 열의 기본값은 어떻게 설정합니까?
• 생각하는 것과 달리 DATETIME은 TIMESTAMP보다 빠릅니다 . http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with -미삼/
• TIMESTAMP는 여전히 1970-2038로 제한됩니다.

(서버의 시간대를 변경할 가능성이 없는 경우)

---

AngularJ를 사용한 예

 // back-end: format for angular within the sql query SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")... // font-end Output the localised time {{item.my_datetime | date :'medium' }}

모든 현지화된 시간 형식은 https://docs.angularjs.org/api/ng/filter/date에서 사용할 수 있습니다.

Sebastien Horin

TIMESTAMP는 항상 UTC(즉, UTC로 1970-01-01 이후 경과된 초)이며 MySQL 서버는 이를 연결 시간대의 날짜/시간으로 자동 변환합니다. 장기적으로 TIMESTAMP는 임시 데이터가 항상 UTC에 있다는 것을 알고 있기 때문에 가야 할 길입니다. 예를 들어, 다른 서버로 마이그레이션하거나 서버의 시간대 설정을 변경하더라도 날짜를 망치지 않을 것입니다.

참고: 기본 연결 시간대는 서버 시간대이지만 세션별로 변경할 수 있습니다(반드시 변경되어야 함)( SET time_zone = ... 참조).

Sobes

timestamp datetime 필드의 특수한 경우입니다. 특별한 속성을 갖도록 timestamp 열을 생성할 수 있습니다. 생성 및/또는 업데이트 시 자체 업데이트하도록 설정할 수 있습니다.

"더 큰" 데이터베이스 용어로 timestamp 에는 몇 가지 특수한 경우의 트리거가 있습니다.

옳은 것은 전적으로 당신이하고 싶은 것에 달려 있습니다.

Jeff Warnica

DATETIME, TIMESTAMP 및 DATE 간의 비교

[.fraction]은 무엇입니까?

• DATETIME 또는 TIMESTAMP 값은 최대 마이크로초(6자리) 정밀도의 후행 소수 초 부분을 포함할 수 있습니다. 특히 DATETIME 또는 TIMESTAMP 열에 삽입된 값의 소수 부분은 삭제되지 않고 저장됩니다. 이것은 물론 선택 사항입니다.

출처:

• MySQL 날짜/시간 데이터 유형 참조
• MySQL 스토리지 요구 사항 참조

Dehan

어느 것도 아니다. DATETIME 및 TIMESTAMP 유형은 기본적으로 일반 사용 사례에 적합하지 않습니다. MySQL은 미래에 그것들을 바꿀 것입니다. 다른 것을 사용해야 하는 특별한 이유가 없는 한 BIGINT

특수한 상황들

다음은 선택이 더 쉽고 이 답변에서 분석 및 일반적인 권장 사항이 필요하지 않은 몇 가지 특정 상황입니다.

• 날짜만 — 날짜에만 관심이 있고(예: 다음 설날 날짜, 2022-02-01) 해당 날짜가 적용되는 시간대를 명확하게 이해하고 있는 경우(또는 다음과 같이 상관하지 않는 경우) 음력 설날) 그런 다음 DATE 열 유형을 사용합니다.

• 삽입 시간 기록 — 데이터베이스의 행에 대한 삽입 날짜/시간을 기록하고 애플리케이션 이 향후 17년 내에 중단될 것을 염려하지 않는 경우 계속 진행하고 CURRENT_TIMESTAMP() 와 함께 TIMESTAMP 를 사용하십시오.

TIMESTAMP 깨진 이유는 무엇입니까?

TIMESTAMP 유형은 UTC 시간대의 디스크에 저장됩니다. 즉, 물리적으로 서버를 이동해도 서버가 중단되지 않습니다. 좋네요 ✅ . 그러나 현재 정의된 타임스탬프는 2038년 ❌에 완전히 작동을 멈춥니다.

INSERT INTO 또는 SELECT FROM a TIMESTAMP 열을 사용할 때마다 클라이언트/응용 프로그램 서버의 물리적 위치(예: 시간대 구성)가 고려됩니다. 응용 프로그램 서버를 이동하면 날짜가 ❌ 중단됩니다.

VARCHAR 왜 망가졌나요?

VARCHAR 유형을 사용하면 비로컬 날짜/시간/둘 모두를 ISO 8601 형식으로 명확하게 저장할 수 있으며 2037년 이후의 날짜에 대해 작동합니다. Zulu 시간을 사용하는 것이 일반적이지만 ISO 8601에서는 오프셋을 인코딩할 수 있습니다. 이것은 MySQL 날짜 및 시간 함수가 날짜/시간/둘 다 예상되는 모든 위치에서 입력으로 문자열을 지원하지만 입력이 시간대 오프셋을 사용하는 경우 결과가 올바르지 않기 때문에 덜 유용합니다.

또한 VARCHAR 는 추가 바이트의 스토리지를 사용합니다.

DATETIME 깨진 이유는 무엇입니까?

DATETIME 은 동일한 열에 DATE 와 TIME 을 저장합니다. 시간대를 이해하지 못하면 이 어느 것도 의미가 없고, 시간대는 어디에도 저장되지 않습니다 ❌. 시간대는 데이터와 떼려야 뗄 수 없는 관계에 있으므로 컬럼에 원하는 시간대를 주석으로 넣어야 합니다. 열 주석을 사용하는 사람은 거의 없기 때문에 이것이 일어나기를 기다리는 실수입니다. 애리조나에서 서버를 상속받았으므로 항상 모든 타임스탬프를 애리조나 시간에서 변환한 다음 다른 시간으로 변환해야 합니다.

DATETIME 이 올바른 유일한 상황은 다음 문장을 완성하는 것입니다.

2020년 새해는 정확히 DATETIME("2020-01-01 00:00:00") 합니다.

DATETIME 대한 다른 좋은 용도는 없습니다. 아마도 델라웨어의 시 정부를 위한 웹 서버를 상상할 것입니다. 확실히 이 서버의 시간대와 이 서버에 액세스하는 모든 사람들은 동부 시간대를 사용하여 델라웨어에 있다고 암시할 수 있습니다. 맞죠? 잘못된! 이 천년기에 우리는 모두 서버를 "클라우드"에 존재하는 것으로 생각합니다. 따라서 서버가 언젠가는 이동될 것이기 때문에 특정 시간대에 서버를 생각하는 것은 항상 잘못된 것입니다.

참고: MySQL은 이제 DATETIME 리터럴에서 시간대 오프셋 을 지원합니다( @Marko 덕분에 ). DATETIME 을 삽입하는 것이 더 편리할 수 있지만 데이터의 불완전하고 따라서 쓸모없는 의미를 다루지는 않습니다. 이 치명적인 문제는 위의 ("❌")를 식별합니다.

BIGINT 를 사용하는 방법?

정의하다:

 CREATE TEMPORARY TABLE good_times ( a_time BIGINT )

특정 값 삽입:

 INSERT INTO good_times VALUES ( UNIX_TIMESTAMP(CONVERT_TZ("2014-12-03 12:24:54", '+00:00', @@global.time_zone)) );

또는 물론 다음과 같이 애플리케이션에서 훨씬 더 좋습니다.

 $statement = $myDB->prepare('INSERT INTO good_times VALUES (?)'); $statement->execute([$someTime->getTimestamp()]);

선택하다:

 SELECT a_time FROM good_times;

여기에 범위를 벗어나 상대적 시간 필터링(지난 30일 이내 게시물 선택, 등록 후 10분 이내에 구매한 사용자 찾기)을 위한 기술이 있습니다.

William Entriken

MySQL에서 테이블 열을 생성할 때 아래 라인을 따라 무언가를 사용할 수 있다는 점은 주목할 가치가 있습니다.

 on update CURRENT_TIMESTAMP

이렇게 하면 행을 수정하는 각 인스턴스의 시간이 업데이트되며 저장된 마지막 편집 정보에 매우 유용합니다. 그러나 이것은 datetime이 아닌 타임스탬프에서만 작동합니다.

leejmurphy

저는 MySQL과 PHP로 작업할 때 항상 Unix 타임스탬프를 사용합니다. 이것이 PHP의 기본 날짜 방법인 주된 이유는 타임스탬프를 매개변수로 사용하므로 구문 분석이 필요하지 않습니다.

PHP에서 현재 Unix 타임스탬프를 얻으려면 time();
그리고 MySQL에서는 SELECT UNIX_TIMESTAMP(); .

Mark Davidson

내 경험에 따르면 삽입이 한 번만 발생하는 날짜 필드를 원하고 해당 특정 필드에 대한 업데이트 또는 기타 작업을 원하지 않는 경우 날짜 시간으로 이동하십시오.

예를 들어, REGISTRATION DATE 필드가 user 테이블을 고려하십시오. 해당 user 테이블에서 특정 사용자의 마지막 로그인 시간을 알고 싶다면 타임스탬프 유형의 필드로 이동하여 필드가 업데이트되도록 합니다.

phpMyAdmin 에서 테이블을 생성하는 경우 행 업데이트가 발생하면 기본 설정이 타임스탬프 필드를 업데이트합니다. 타임스탬프 필드가 행 업데이트로 업데이트되지 않는 경우 다음 쿼리를 사용하여 타임스탬프 필드가 자동 업데이트되도록 할 수 있습니다.

 ALTER TABLE your_table MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

Kannan Prasad

타임스탬프 데이터 유형은 날짜와 시간을 저장하지만 datetime처럼 현재 시간대 형식이 아닌 UTC 형식으로 저장합니다. 그리고 데이터를 가져오면 타임스탬프가 이를 다시 현재 시간대 시간으로 변환합니다.

따라서 미국에 있고 미국 시간대가 있는 서버에서 데이터를 가져오고 있다고 가정합니다. 그러면 미국 시간대에 따라 날짜와 시간이 표시됩니다. 타임스탬프 데이터 유형 열은 행이 업데이트될 때 항상 자동으로 업데이트됩니다. 따라서 특정 행이 마지막으로 업데이트된 시간을 추적하는 것이 유용할 수 있습니다.

자세한 내용은 블로그 게시물 Timestamp Vs Datetime을 참조 하세요.

Arvind

나는 항상 유닉스 타임스탬프를 사용하여 많은 날짜/시간 정보를 다룰 때, 특히 시간대 조정, 날짜 추가/빼기 등을 수행할 때 온전함을 유지합니다. 타임스탬프를 비교할 때 복잡한 시간대 요소를 배제하고 더 무거운 날짜-시간 더하기/빼기 대신 가벼운 산술 연산을 사용한다는 점에서 서버 측 처리(애플리케이션 코드 또는 데이터베이스 쿼리이든 상관없음)에서 리소스를 절약할 수 있습니다. 기능.

고려할 가치가 있는 또 다른 사항:

애플리케이션을 구축하는 경우 데이터가 어떻게 사용되어야 하는지 알 수 없습니다. 예를 들어 데이터 세트의 많은 레코드를 타사 API의 항목 무리와 비교하고 이를 시간 순서대로 배치해야 하는 경우 행에 대한 Unix 타임스탬프입니다. MySQL 타임스탬프를 사용하기로 결정한 경우에도 유닉스 타임스탬프를 보험으로 저장하십시오.

Oliver Holmberg

이 기사에서 가져온 참조:

주요 차이점:

TIMESTAMP는 레코드 변경 사항을 추적하고 레코드가 변경될 때마다 업데이트하는 데 사용됩니다. DATETIME은 레코드 변경에 영향을 받지 않는 특정 정적 값을 저장하는 데 사용됩니다.

TIMESTAMP는 다른 TIME ZONE 관련 설정의 영향도 받습니다. DATETIME은 상수입니다.

TIMESTAMP는 내부적으로 현재 시간대를 UTC로 변환하여 저장하고 검색하는 동안 다시 현재 시간대로 변환합니다. DATETIME은 이 작업을 수행할 수 없습니다.

TIMESTAMP 지원 범위: '1970-01-01 00:00:01' UTC ~ '2038-01-19 03:14:07' UTC DATETIME 지원 범위: '1000-01-01 00:00:00' ~ '9999 -12-31 23:59:59′

Anvesh

제 경우에는 시스템, 데이터베이스 서버 등 가능한 모든 것의 시간대를 UTC로 설정했습니다. 고객이 다른 시간대를 요구하는 경우 앱에서 구성합니다.

타임스탬프에는 암시적으로 시간대가 포함되기 때문에 저는 거의 항상 datetime 필드보다 타임스탬프를 선호합니다. 따라서 다른 시간대의 사용자가 앱에 액세스하고 현지 시간대의 날짜와 시간을 보도록 하려는 순간부터 이 필드 유형을 사용하면 데이터가 datetime 필드에 저장된 경우보다 훨씬 쉽게 수행할 수 있습니다. .

게다가 데이터베이스를 다른 시간대의 시스템으로 마이그레이션하는 경우 타임스탬프를 사용하는 것이 더 자신 있게 느껴질 것입니다. 1시간 이하의 정밀도가 필요하고 그 사이에 서머 시간 변화가 있는 두 순간 사이의 차이를 계산할 때 가능한 문제는 말할 것도 없습니다.

요약하자면 저는 타임스탬프의 이점을 중요하게 생각합니다.

• 국제(다중 시간대) 앱에서 바로 사용할 수 있습니다.
• 시간대 간 쉬운 마이그레이션
• 차이를 계산하기가 매우 쉽습니다(두 타임스탬프를 뺍니다)
• 여름 성수기 입/퇴장 날짜에 대해 걱정하지 마십시오.

이러한 모든 이유로 가능한 경우 UTC 및 타임스탬프 필드를 선택합니다. 그리고 나는 두통을 피한다 ;)

Roger Campanera

테이블에서 UPDATE 문을 수행할 때 변경되는 타임스탬프에 주의하십시오. 'Name'(varchar), 'Age'(int) 및 'Date_Added'(timestamp) 열이 있는 테이블이 있고 다음 DML 문을 실행하는 경우

 UPDATE table SET age = 30

그러면 'Date_Added' 열의 모든 단일 값이 현재 타임스탬프로 변경됩니다.

Lloyd Banks

+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+ | TIMESTAMP | DATETIME | +---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+ | TIMESTAMP requires 4 bytes. | DATETIME requires 8 bytes. | | Timestamp is the number of seconds that have elapsed since January 1, 1970 00:00 UTC. | DATETIME is a text displays 'YYYY-MM-DD HH:MM:SS' format. | | TIMESTAMP supported range: '1970-01-01 00:00:01′ UTC to '2038-01-19 03:14:07′ UTC. | DATETIME supported range: '1000-01-01 00:00:00′ to '9999-12-31 23:59:59′ | | TIMESTAMP during retrieval converted back to the current time zone. | DATETIME can not do this. | | TIMESTAMP is used mostly for metadata ie row created/modified and audit purpose. | DATETIME is used mostly for user-data. | +---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

Premraj

불필요한 트리거를 사용하지 않고 현재 시간을 기반으로 자동 업데이트하는 TIMESTAMP의 기능에서 탁월한 유용성을 발견했습니다. TIMESTAMP가 말한 것처럼 UTC이지만 그것은 저입니다.

다른 시간대를 추적할 수 있으므로 예를 들어 상대 시간을 표시해야 하는 경우 UTC 시간이 원하는 것입니다.

Marc DiMillo

DATETIME 대 TIMESTAMP:

TIMESTAMP는 레코드의 변경 사항을 추적하는 데 사용되며 레코드가 변경될 때마다 업데이트됩니다.

DATETIME은 레코드 변경에 영향을 받지 않는 특정 정적 값을 저장하는 데 사용됩니다.

TIMESTAMP는 다른 TIME ZONE 관련 설정의 영향도 받습니다. DATETIME은 상수입니다.

TIMESTAMP는 내부적으로 현재 시간대를 UTC로 변환하여 저장하고 검색하는 동안 다시 현재 시간대로 변환합니다.

DATETIME은 이 작업을 수행할 수 없습니다.

TIMESTAMP는 4바이트이고 DATETIME은 8바이트입니다.

TIMESTAMP 지원 범위: '1970-01-01 00:00:01' UTC ~ '2038-01-19 03:14:07' UTC DATETIME 지원 범위: '1000-01-01 00:00:00' ~ '9999 -12-31 23:59:59′

Rahul Kr Daman

주요 차이점은

• 타임스탬프의 INDEX - 작동
• Datetime의 INDEX - 작동하지 않음

Datetime 인덱싱 관련 문제를 보려면 이 게시물을 참조하세요.

Charles Faiga

Timestamp와 Datetime의 또 다른 차이점은 Timestamp에서 기본값을 NULL로 지정할 수 없다는 것입니다.

ecleel

시간대와 관련된 많은 문제와 버그에 직면한 후 애플리케이션에서 datetime 사용을 중단했습니다. 대부분의 경우 timestamp 사용하는 IMHO datetime 보다 낫습니다 .

시간이 몇시냐고 물으신다면? 그리고 답은 '2019-02-05 21:18:30' 처럼 나오는데 다른 부분이 없어서 완성이 안되고 답변이 정의되지 않았습니다. 어느 시간대인가요? 워싱턴? 모스크바? 베이징 ?

시간대 없이 datetimes를 사용하는 것은 애플리케이션이 1개의 시간대만 처리한다는 것을 의미하지만, 타임스탬프는 datetime 의 이점과 다른 시간대에서 동일한 정확한 시점을 표시할 수 있는 유연성을 제공합니다.

datetime 사용을 후회하고 데이터를 타임스탬프에 저장하고 싶은 경우가 있습니다.

1. 고객의 편의를 위해 계산을 하지 않고 원하는 시간대를 기준으로 시간을 표시하고 시간을 의미 있는 시간대로 변환할 수 있습니다. 시간대를 변경하기만 하면 모든 애플리케이션 코드가 동일해집니다. (사실 항상 애플리케이션 시작 시 시간대를 정의하거나 PHP 애플리케이션의 경우 처리를 요청해야 함)

    SET time_zone = '+2:00';

2. 거주하는 국가를 변경하고 실제 데이터를 변경하지 않고 다른 시간대에서 데이터를 보면서 데이터를 유지 관리하는 작업을 계속합니다.

3. 전 세계의 다른 클라이언트로부터 데이터를 수락하면 각 클라이언트는 자신의 시간대에 시간을 삽입합니다.

요컨대

datetime = 응용 프로그램은 1개의 시간대를 지원합니다(삽입 및 선택 모두)

timestamp = 응용 프로그램이 모든 시간대를 지원합니다(삽입 및 선택 모두)

---

이 답변은 시간대와 관련하여 타임스탬프의 유연성과 용이성을 강조하기 위한 것이며 열 크기나 범위 또는 분수 와 같은 다른 차이점은 다루지 않습니다.

Accountant م

저는 타임스탬프를 사용하여 모든 것을 하나의 공통 원시 형식으로 유지하고 PHP 코드 또는 SQL 쿼리의 데이터 형식을 지정하는 것을 선호합니다. 코드에서 모든 것을 일반 초 단위로 유지하는 것이 편리한 경우가 있습니다.

Hans

출처 : http:www.stackoverflow.com/questions/409286/should-i-use-the-datetime-or-timestamp-data-type-in-mysql