- 1 1. MySQL TIMESTAMP คืออะไร?
- 2 2. การใช้งานพื้นฐานของ TIMESTAMP
- 3 3. การทำงานกับ TIMESTAMP และโซนเวลา
- 4 4. ปัญหา Year 2038 และผลกระทบของมัน
- 5 5. กรณีการใช้งานจริงของประเภท TIMESTAMP
- 6 6. หมายเหตุสำคัญเมื่อใช้ประเภท TIMESTAMP
- 7 7. สรุปและคำแนะนำ
- 8 8. คำถามที่พบบ่อย (FAQ)
- 8.1 ฉันควรเลือกอย่างไรระหว่าง TIMESTAMP และ DATETIME?
- 8.2 เป็นความจริงหรือที่ TIMESTAMP ไม่สามารถใช้ได้หลังปี 2038?
- 8.3 ฉันสามารถอนุญาตค่า NULL ในคอลัมน์ TIMESTAMP ได้อย่างไร?
- 8.4 หากฉันเปลี่ยนการตั้งค่าโซนเวลา มันจะส่งผลต่อข้อมูล TIMESTAMP ที่มีอยู่หรือไม่?
- 8.5 หากฉันใช้ CURRENT_TIMESTAMP ฉันยังสามารถแทรก datetime เฉพาะได้หรือไม่?
1. MySQL TIMESTAMP คืออะไร?
TIMESTAMP เป็นชนิดข้อมูลใน MySQL ที่ออกแบบมาเพื่อเก็บจุดเวลาเฉพาะในรูปแบบ UTC (Coordinated Universal Time) และจะทำการแปลงโซนเวลาโดยอัตโนมัติเมื่อบันทึกและดึงข้อมูล ชนิดข้อมูลนี้สามารถจัดการวันที่และเวลาได้ในช่วงตั้งแต่ 1 มกราคม 1970 ถึง 19 มกราคม 2038 เมื่อบันทึกข้อมูลลงในฐานข้อมูล TIMESTAMP จะใช้โซนเวลาปัจจุบัน และเมื่อดึงข้อมูลออกมาจะถูกแปลงโดยอัตโนมัติตามโซนเวลาของระบบ
ความแตกต่างระหว่าง TIMESTAMP กับ DATETIME
ชนิดข้อมูล DATETIME มักถูกเปรียบเทียบกับ TIMESTAMP DATETIME จะเก็บค่าที่เป็นวันที่และเวลา “ตามที่บันทึกไว้” ดังนั้นข้อมูลที่บันทึกจะไม่ถูกกระทบจากโซนเวลา ในทางตรงกันข้าม TIMESTAMP จะถูกแปลงเป็น UTC เมื่อบันทึกและจะแปลงกลับเป็นโซนเวลาของระบบเมื่อดึงออกมา ซึ่งช่วยป้องกันการเบี่ยงเบนของเวลาในสภาพแวดล้อมที่ต่างกัน
ตัวอย่างเช่น TIMESTAMP มีประโยชน์เป็นพิเศษในระหว่างการย้ายระบบหรือเมื่อทำงานกับฐานข้อมูลที่กระจายอยู่หลายโซนเวลา DATETIME รองรับช่วงที่กว้างกว่า — ตั้งแต่ปี 1000 ถึง 9999 — จึงมักถูกใช้เพื่อหลีกเลี่ยงปัญหา Year 2038
ตัวอย่างการใช้งาน TIMESTAMP
คุณสามารถสร้างตารางโดยใช้ TIMESTAMP ได้ดังนี้
CREATE TABLE events (
id INT AUTO_INCREMENT PRIMARY KEY,
event_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
ในตัวอย่างนี้ คอลัมน์ event_time จะบันทึกเวลาปัจจุบันโดยอัตโนมัติเมื่อมีการแทรกแถวใหม่ และจะเขียนทับค่านั้นทุกครั้งที่แถวถูกอัปเดต
2. การใช้งานพื้นฐานของ TIMESTAMP
เมื่อใช้ TIMESTAMP ใน MySQL ควรเข้าใจวิธีพื้นฐานในการแทรกและดึงค่า ด้านล่างนี้เป็นวิธีการทั่วไปหลายแบบในการทำงานกับข้อมูล TIMESTAMP
แทรกวันที่และเวลา
เมื่อแทรกข้อมูลลงในคอลัมน์ TIMESTAMP คุณมักจะระบุวันที่และเวลาในรูปแบบสตริง วันที่จะเขียนเป็น “YYYY-MM-DD” และเวลาเป็น “hh:mm:ss”
INSERT INTO events (event_time) VALUES ('2023-10-01 12:30:00');
คำสั่ง SQL นี้จะแทรกเวลา 12:30:00 ของวันที่ 1 ตุลาคม 2023 ลงในคอลัมน์ event_time
แทรกเวลาปัจจุบัน
โดยใช้ฟังก์ชัน NOW() ของ MySQL คุณสามารถดึงวันที่และเวลาปัจจุบันได้อย่างง่ายดาย ฟังก์ชันนี้จะคืนค่าวันที่และเวลาตามโซนเวลาของระบบ และคุณสามารถแทรกค่าเหล่านี้โดยตรงลงในคอลัมน์ TIMESTAMP
INSERT INTO events (event_time) VALUES (NOW());
ในตัวอย่างนี้ เวลาปัจจุบัน ณ ขณะที่ SQL ถูกเรียกใช้จะถูกแทรกโดยอัตโนมัติ
ใช้คุณสมบัติ Auto-Update
หากคุณระบุ ON UPDATE CURRENT_TIMESTAMP ให้กับคอลัมน์ TIMESTAMP เวลาอัปเดตจะถูกบันทึกโดยอัตโนมัติทุกครั้งที่แถวถูกอัปเดต
CREATE TABLE orders (
id INT AUTO_INCREMENT PRIMARY KEY,
order_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
ในตารางนี้ order_time จะตั้งค่าเป็นเวลาปัจจุบันเมื่อแถวถูกสร้าง และจะอัปเดตเป็นเวลาปัจจุบันทุกครั้งที่แถวถูกแก้ไข 
3. การทำงานกับ TIMESTAMP และโซนเวลา
หนึ่งในคุณสมบัติที่สำคัญที่สุดของ TIMESTAMP คือการจัดการโซนเวลา ข้อมูลที่บันทึกจะถูกแปลงเป็น UTC เสมอ และเมื่อคุณดึงข้อมูลจากฐานข้อมูล จะถูกแปลงอีกครั้งให้ตรงกับโซนเวลาของระบบ
วิธีตรวจสอบการตั้งค่าโซนเวลา
ใน MySQL คุณสามารถตั้งค่าโซนเวลาได้ทั้งระดับเซิร์ฟเวอร์และระดับเซสชัน คุณสามารถตรวจสอบการตั้งค่าโซนเวลาโดยใช้คำสั่ง SHOW VARIABLES
SHOW VARIABLES LIKE 'time_zone';
คำสั่งนี้จะคืนค่าโซนเวลาที่กำหนดไว้ในปัจจุบันสำหรับฐานข้อมูล หากต้องการเปลี่ยนโซนเวลา ให้ใช้คำสั่งต่อไปนี้
SET time_zone = '+09:00';
ความแตกต่างของโซนเวลาระหว่าง TIMESTAMP กับ DATETIME
ชนิด DATETIME จะเก็บวันที่และเวลาโดยไม่คำนึงถึงโซนเวลา ในขณะที่ชนิด TIMESTAMP จะถูกแปลงเป็น UTC เมื่อบันทึก ดังนั้นในสภาพแวดล้อมที่มีหลายโซนเวลาอยู่ร่วมกัน TIMESTAMP มักจะเป็นตัวเลือกที่ดีกว่า
4. ปัญหา Year 2038 และผลกระทบของมัน
The Year 2038 problem is caused by the limitation of the TIMESTAMP type on 32-bit systems. MySQL’s TIMESTAMP type is based on the number of seconds since 00:00:00 UTC on January 1, 1970. When it exceeds 03:14:07 UTC on January 19, 2038, this value overflows.
วิธีหลีกเลี่ยงปัญหาปี 2038
เพื่อหลีกเลี่ยงปัญหานี้ แนะนำให้ใช้ระบบ 64‑บิตหรือประเภท DATETIME ที่มีช่วงกว้างกว่า DATETIME สามารถจัดการวันที่และเวลาได้ตั้งแต่ปี 1000 ถึง 9999 ดังนั้นจึงสามารถใช้ได้อย่างปลอดภัยหลังปี 2038
คุณยังสามารถหลีกเลี่ยงปัญหานี้ได้โดยการอัปเกรดระบบของคุณ เนื่องจากระบบ 64‑บิตไม่มีข้อจำกัดของปี 2038 จึงควรพิจารณาอัปเกรดฐานข้อมูลและแอปพลิเคชันของคุณ
5. กรณีการใช้งานจริงของประเภท TIMESTAMP
ประเภท TIMESTAMP ของ MySQL ไม่ได้ใช้เพียงเพื่อเก็บค่าที่เป็นวันที่และเวลาแบบพื้นฐานเท่านั้น แต่ยังรองรับรูปแบบการใช้งานที่หลากหลาย เช่น การแทรกหรืออัปเดตเวลาปัจจุบันโดยอัตโนมัติ ด้านล่างเป็นตัวอย่างการใช้งานขั้นสูงที่พบบ่อย
แทรกเวลาปัจจุบันโดยอัตโนมัติ
เมื่อกำหนดคอลัมน์ TIMESTAMP คุณสามารถตั้งค่า CURRENT_TIMESTAMP เป็นค่าเริ่มต้น เพื่อให้วันที่และเวลาปัจจุบันถูกแทรกโดยอัตโนมัติทุกครั้งที่สร้างแถวใหม่ ตัวอย่างเช่น การสร้างตารางที่บันทึกเวลาที่คำสั่งซื้อเกิดขึ้นโดยอัตโนมัติ สามารถทำได้ดังนี้
CREATE TABLE orders (
id INT AUTO_INCREMENT PRIMARY KEY,
order_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
บันทึกเวลาการอัปเดตโดยอัตโนมัติ
โดยระบุ ON UPDATE CURRENT_TIMESTAMP เวลาการอัปเดตจะถูกบันทึกโดยอัตโนมัติทุกครั้งที่แถวถูกอัปเดต ทำให้การจัดการประวัติการอัปเดตเป็นเรื่องง่ายโดยอัตโนมัติ
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50),
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
การใช้หลายคอลัมน์ TIMESTAMP
ใน MySQL คุณสามารถใส่หลายคอลัมน์ TIMESTAMP ในตารางได้ แต่โดยค่าเริ่มต้นจะมีได้เพียงคอลัมน์เดียวที่สามารถตั้งค่าเริ่มต้นเป็น CURRENT_TIMESTAMP หากต้องการจัดการหลาย timestamp โดยอัตโนมัติ ให้กำหนดค่าตรงสำหรับคอลัมน์อื่น ๆ อย่างชัดเจน หรือใช้ประเภท DATETIME
CREATE TABLE posts (
id INT AUTO_INCREMENT PRIMARY KEY,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
6. หมายเหตุสำคัญเมื่อใช้ประเภท TIMESTAMP
เมื่อใช้ประเภท TIMESTAMP มีข้อควรระวังสำคัญหลายประการที่ควรเข้าใจ การรู้จักข้อเหล่านี้ช่วยป้องกันความไม่สอดคล้องและข้อผิดพลาดที่ไม่คาดคิด
ข้อจำกัด NULL และค่าเริ่มต้น
โดยค่าเริ่มต้น คอลัมน์ TIMESTAMP จะมีข้อจำกัด NOT NULL กล่าวคือ หากต้องการให้รับค่า NULL ต้องระบุ DEFAULT NULL อย่างชัดเจน
CREATE TABLE logs (
id INT AUTO_INCREMENT PRIMARY KEY,
log_time TIMESTAMP DEFAULT NULL
);
คุณยังสามารถระบุ DEFAULT 0 เพื่อกำหนดค่า datetime ที่ไม่ถูกต้องเป็น 0000-00-00 00:00:00 เป็นค่าเริ่มต้น อย่างไรก็ตามไม่แนะนำ ในโหมด SQL ที่เข้มงวดของ MySQL ค่าที่ไม่ถูกต้องนี้อาจทำให้เกิดข้อผิดพลาด
ปัญหากับ 0000-00-00 00:00:00
บางเวอร์ชันของ MySQL รองรับ 0000-00-00 00:00:00 เป็นค่า datetime ที่ไม่ถูกต้อง แต่ค่าเหล่านี้อาจทำให้เกิดปัญหาการทำงานในระบบจริง โดยเฉพาะระบบที่ให้ความสำคัญกับความสมบูรณ์ของข้อมูล ควรหลีกเลี่ยงค่าไม่ถูกต้องเหล่านี้ แทนที่นั้นแนะนำให้ใช้ NULL หรือค่าเริ่มต้นที่เหมาะสม
CREATE TABLE sessions (
id INT AUTO_INCREMENT PRIMARY KEY,
start_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
end_time TIMESTAMP NULL
);
ผลกระทบของโซนเวลาของระบบ
เนื่องจากประเภท TIMESTAMP ถูกจัดเก็บหลังจากแปลงเป็น UTC คุณจึงต้องระมัดระวังเมื่อย้ายฐานข้อมูลข้ามโซนเวลา หากการตั้งค่าโซนเวลาของเซิร์ฟเวอร์เปลี่ยนแปลง เวลาที่ดึงออกมาจะอาจกลายเป็นค่าที่ไม่ต้องการ การจัดการโซนเวลาอย่างแม่นยำจึงเป็นสิ่งสำคัญ
SET time_zone = 'Asia/Tokyo';
คำสั่งนี้กำหนดโซนเวลาของฐานข้อมูลเป็นโตเกียวและช่วยให้การจัดการการแปลงจาก UTC มีความแม่นยำ

7. สรุปและคำแนะนำ
ประเภท TIMESTAMP เป็นเครื่องมือที่ทรงพลังสำหรับการจัดการวันที่และเวลาอย่างมีประสิทธิภาพใน MySQL โดยเฉพาะอย่างยิ่ง การแปลงอัตโนมัติกับโซนเวลาและการบันทึกเวลาอัตโนมัติเมื่อสร้าง/อัปเดตนั้นสะดวกมาก อย่างไรก็ตาม สำคัญที่จะต้องเข้าใจข้อจำกัดและข้อควรระวัง เช่น ปัญหาปี 2038 และวิธีการจัดการค่าของ NULL
เมื่อใดควรใช้ TIMESTAMP
- เมื่อคุณต้องการพฤติกรรมอัปเดตอัตโนมัติ ,
TIMESTAMPเหมาะสมที่สุด—โดยเฉพาะหากคุณต้องการบันทึก timestamp อัตโนมัติทุกครั้งที่อัปเดตเรคคอร์ด - ใน ระบบที่ต้องพิจารณาโซนเวลา , พฤติกรรมการแปลงที่ใช้ UTC ของ
TIMESTAMPมีประโยชน์ - ในทางตรงกันข้าม หากคุณต้องการ ช่วงที่ป้องกันอนาคต หรือต้องจัดการวันที่นอกช่วงที่รองรับ (หลังปี 2038), พิจารณาใช้
DATETIME
สุดท้าย เลือกระหว่าง TIMESTAMP และ DATETIME ตามความต้องการของระบบเพื่อให้มั่นใจในความสมบูรณ์ของข้อมูลและการบำรุงรักษา
8. คำถามที่พบบ่อย (FAQ)
คำถามและปัญหาที่เกี่ยวข้องกับ MySQL TIMESTAMP เป็นเรื่องปกติในหมู่นักพัฒนา ดังนั้นส่วนนี้จึงสรุปคำถามที่พบบ่อย คำถามเหล่านี้ให้เคล็ดลับและโซลูชันที่เป็นประโยชน์สำหรับการจัดการ TIMESTAMP อย่างถูกต้อง
ฉันควรเลือกอย่างไรระหว่าง TIMESTAMP และ DATETIME?
TIMESTAMP แปลงค่าอัตโนมัติตามโซนเวลาโดยใช้ UTC ดังนั้นจึงเหมาะสำหรับแอปพลิเคชันและระบบที่ต้องคำนึงถึงโซนเวลาหลายแห่ง มันยังรองรับการบันทึกค่าของวันที่/เวลาอัตโนมัติเมื่อสร้างหรืออัปเดตเรคคอร์ด ในทางตรงกันข้าม DATETIME เก็บค่าตามที่เป็น ดังนั้นจึงดีกว่าเมื่อคุณต้องการการจัดการ datetime ที่สอดคล้องกันโดยไม่มีการแปลงโซนเวลา
เป็นความจริงหรือที่ TIMESTAMP ไม่สามารถใช้ได้หลังปี 2038?
ใช่ ปัญหาปี 2038 ใช้กับประเภท TIMESTAMP 32 บิต เพราะมันอิงจากจำนวนวินาทีตั้งแต่วันที่ 1 มกราคม 1970 มันจึงไม่สามารถแทน datetime หลังวันที่ 19 มกราคม 2038 เพื่อหลีกเลี่ยงสิ่งนี้ แนะนำให้ย้ายไปยังระบบ 64 บิตหรือใช้ประเภท DATETIME
ฉันสามารถอนุญาตค่า NULL ในคอลัมน์ TIMESTAMP ได้อย่างไร?
เพื่ออนุญาตค่า NULL ในคอลัมน์ TIMESTAMP คุณต้องระบุ DEFAULT NULL อย่างชัดเจนดังที่แสดงด้านล่าง
CREATE TABLE logs (
id INT AUTO_INCREMENT PRIMARY KEY,
log_time TIMESTAMP DEFAULT NULL
);
ด้วยการตั้งค่านี้ หากคุณแทรกเรคคอร์ดโดยไม่ระบุ datetime ค่า NULL จะถูกเก็บไว้
หากฉันเปลี่ยนการตั้งค่าโซนเวลา มันจะส่งผลต่อข้อมูล TIMESTAMP ที่มีอยู่หรือไม่?
เพราะค่าของ TIMESTAMP ถูกแปลงเป็น UTC เมื่อเก็บไว้ การเปลี่ยนการตั้งค่าโซนเวลาจะส่งผลต่อวิธีที่ข้อมูลถูกแสดงเมื่อดึงออก ข้อมูลพื้นฐานยังคงเก็บใน UTC แต่จะถูกแปลงตามโซนเวลาใหม่ ซึ่งเปลี่ยนค่าของเวลาที่ดึงออก เพื่อให้ข้อมูลสอดคล้องกัน สำคัญที่จะต้องทำให้การตั้งค่าโซนเวลาเป็นมาตรฐานทั่วระบบ
หากฉันใช้ CURRENT_TIMESTAMP ฉันยังสามารถแทรก datetime เฉพาะได้หรือไม่?
CURRENT_TIMESTAMP แทรกเวลาปัจจุบันอัตโนมัติเมื่อแทรกเรคคอร์ด แต่คุณยังสามารถแทรก datetime เฉพาะอย่างชัดเจนโดยใช้ NOW() หรือสตริง literal
INSERT INTO events (event_time) VALUES ('2023-10-01 12:30:00');
ด้วยวิธีนี้ คุณสามารถแทรก datetime ด้วยตนเองแม้จะใช้ CURRENT_TIMESTAMP


