เวลาปัจจุบันใน MySQL: NOW(), CURDATE(), UTC_TIMESTAMP(), โซนเวลา, และแนวปฏิบัติที่ดีที่สุด

1. รับเวลาปัจจุบันใน MySQL (สรุปสั้นที่สุดของชีทคำสั่ง SQL)

หากคุณต้องการรับเวลาปัจจุบันใน MySQL มีเพียงไม่กี่ฟังก์ชัน SQL ที่คุณต้องจำ
ด้านล่างเป็น คำตอบสั้นที่สุด สำหรับคีย์เวิร์ดการค้นหา “MySQL get current time”.

1.1 วันที่และเวลาปัจจุบันของ MySQL: NOW() / CURRENT_TIMESTAMP

คืนค่า วันที่ + เวลา ปัจจุบัน (YYYY-MM-DD HH:MM:SS).

SELECT NOW();

SELECT CURRENT_TIMESTAMP;

ตัวอย่างผลลัพธ์

2025-02-01 15:30:45

• NOW() และ CURRENT_TIMESTAMP มักจะคืนค่าผลลัพธ์เดียวกัน
• ทั้งสองคืนค่าวันที่และเวลาปัจจุบัน
• หากคุณต้องการมิลลิวินาที ให้ใช้ต่อไปนี้

  SELECT NOW(3);
  

หมายเหตุ (ข้อผิดพลาดทั่วไป)

• ขึ้นอยู่กับการตั้งค่าโซนเวลาของเซิร์ฟเวอร์
• ในสภาพแวดล้อม UTC คุณอาจได้รับเวลา UTC แทนเวลาญี่ปุ่น
• ระหว่างการดำเนินการคิวรี มันโดยพื้นฐานจะคืนค่าเวลาเดียวกัน (คงที่ภายในคำสั่งเดียว)

1.2 วันที่ปัจจุบันของ MySQL: CURDATE()

คืนค่าเฉพาะวันที่ (ไม่มีเวลา).

SELECT CURDATE();

ตัวอย่างผลลัพธ์

2025-02-01

กรณีการใช้งาน

• คิวรีข้อมูลของวันนี้
• การเปรียบเทียบวันที่ (เช่น กรองเฉพาะบันทึกของวันนี้)

หมายเหตุ

• ค่าที่คืนเป็นประเภท DATE
• ไม่เหมาะสมเมื่อคุณต้องการการประมวลผลตามเวลาของวัน

1.3 เวลา ปัจจุบันของ MySQL: CURTIME()

คืนค่าเฉพาะเวลา.

SELECT CURTIME();

ตัวอย่างผลลัพธ์

15:30:45

กรณีการใช้งาน

• ตรวจสอบชั่วโมงทำการ
• โลจิกการแยกสาขาตามช่วงเวลา

หมายเหตุ

• ไม่รวมข้อมูลวันที่
• ไม่สามารถใช้เปรียบเทียบกับคอลัมน์ประเภท DATE ได้

1.4 เวลา UTC ปัจจุบันของ MySQL: UTC_TIMESTAMP()

คืนค่าเวลาในรูปแบบ UTC (Coordinated Universal Time) โดยไม่คำนึงถึงการตั้งค่าโซนเวลาของเซิร์ฟเวอร์.

SELECT UTC_TIMESTAMP();

ตัวอย่างผลลัพธ์

2025-02-01 06:30:45

เมื่อควรใช้

• บริการระดับโลก
• การออกแบบที่บันทึกล็อกเป็น UTC อย่างสม่ำเสมอ

ข้อผิดพลาดทั่วไป

• การผสมกับ NOW() ทำให้เกิดการชดเชยเวลา
• หากแอปสมมุติว่าเป็น JST คุณจะเห็นความแตกต่าง 9 ชั่วโมง

1.5 เวลา ปัจจุบันของ MySQL พร้อมมิลลิวินาที: NOW(3) / CURRENT_TIMESTAMP(3)

MySQL 5.6 ขึ้นไปรองรับวินาทีเศษส่วน.

SELECT NOW(3);

SELECT CURRENT_TIMESTAMP(3);

ตัวอย่างผลลัพธ์

2025-02-01 15:30:45.123

หมายเหตุสำหรับการจัดเก็บ

คอลัมน์ของคุณต้องรองรับวินาทีเศษส่วนด้วย.

DATETIME(3)
TIMESTAMP(3)

หากคุณบันทึกลงในคอลัมน์ที่ไม่รองรับ ส่วนเศษของวินาทีจะถูกตัดออก.

1.6 ชีทสรุปเร็วตามวัตถุประสงค์

สรุปข้อผิดพลาดทั่วไป

• เวลาเบี่ยงเบนเพราะคุณไม่ได้ตรวจสอบโซนเวลา
• ใช้ NOW(3) โดยไม่มีคอลัมน์ที่รองรับมิลลิวินาที
• ผสม UTC กับเวลาในท้องถิ่น
• ไม่เข้าใจความแตกต่างระหว่าง DATETIME และ TIMESTAMP

ความแตกต่างระหว่าง MySQL DATETIME และ TIMESTAMP (เปรียบเทียบว่ามีการแปลงโซนเวลาหรือไม่)

2. ความแตกต่างระหว่าง MySQL NOW() และ CURRENT_TIMESTAMP

NOW() และ CURRENT_TIMESTAMP ดูคล้ายกัน แต่ การเข้าใจผิดว่าควรใช้ที่ไหนและพฤติกรรมของมันอาจทำให้เกิดบั๊กได้ง่าย ที่นี่เราจะสรุปความแตกต่าง การใช้งานที่ถูกต้อง และข้อผิดพลาดทั่วไป.

2.1 ควรใช้แบบไหน? (การใช้ใน SELECT / การใช้เป็นค่า DEFAULT)

■ เมื่อดึงวันที่/เวลา ปัจจุบันใน SELECT

SELECT NOW();
SELECT CURRENT_TIMESTAMP;

โดยปกติ ทั้งสองคืนค่าผลลัพธ์เดียวกัน.

• พวกมันเทียบเท่ากัน (เป็นคำพ้อง)
• ค่าที่คืนเทียบเท่ากับ DATETIME
• มีผลต่อการตั้งค่าโซนเวลา

ข้อสรุปเชิงปฏิบัติ

• เน้นความอ่านง่าย → NOW()
• เน้นสไตล์ SQL มาตรฐาน → CURRENT_TIMESTAMP

■ เมื่อกำหนดค่าเริ่มต้นให้คอลัมน์

CREATE TABLE logs (
    id INT AUTO_INCREMENT PRIMARY KEY,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

จุดสำคัญที่นี่คือ:

สำหรับค่าเริ่มต้น มักใช้ CURRENT_TIMESTAMP.

บางสภาพแวดล้อมอนุญาตให้ใช้ NOW() ด้วย แต่ พฤติกรรมอาจแตกต่างกันขึ้นอยู่กับเวอร์ชันของ MySQL และโหมด SQL ตัวเลือกที่ปลอดภัยกว่าคือ CURRENT_TIMESTAMP.

2.2 การใช้ DEFAULT / ON UPDATE อย่างถูกต้อง

If you want to auto-update an “updated at” timestamp:

CREATE TABLE logs (
    id INT AUTO_INCREMENT PRIMARY KEY,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
        ON UPDATE CURRENT_TIMESTAMP
);

พฤติกรรม

• On INSERT → ตั้งค่าเวลา ณ ปัจจุบันสำหรับ created_at / updated_at
• On UPDATE → อัปเดตเฉพาะ updated_at

ข้อผิดพลาดทั่วไป

• ไม่ตรงกับความแม่นยำของเศษวินาทีเมื่อใช้ DATETIME
• พบข้อจำกัดของ MySQL รุ่นเก่ากับคอลัมน์ TIMESTAMP หลายคอลัมน์ (MySQL 5.6 และก่อนหน้านั้นมีข้อจำกัด)

2.3 ความแตกต่างระหว่าง NOW() และ SYSDATE() (สำคัญ)

จุดที่มักพลาดง่ายคือความแตกต่างจาก SYSDATE().

SELECT NOW(), SYSDATE();

■ ความแตกต่างของพฤติกรรม

• NOW() → คงที่ตั้งแต่เริ่มต้นคิวรี
• SYSDATE() → คืนค่าเวลาตามที่เรียกใช้งาน ณ ขณะนั้น

ตัวอย่าง:

SELECT NOW(), SLEEP(3), NOW();

NOW() คืนค่าที่เหมือนกัน.

SELECT SYSDATE(), SLEEP(3), SYSDATE();

SYSDATE() แสดงความแตกต่าง 3 วินาที.

2.4 ควรใช้อันไหน?

ทำไม NOW() จึงมักแนะนำในระบบจริง

• รักษาความสอดคล้องภายในทรานแซกชัน (กลไกที่ประมวลผลหลายคำสั่ง SQL ร่วมกัน)
• ปลอดภัยกว่าในสภาพแวดล้อมการทำสำเนา

2.5 ความเข้าใจผิดและปัญหาทั่วไป

❌ “NOW() และ CURRENT_TIMESTAMP เหมือนกันอย่างสิ้นเชิง ดังนั้นคุณไม่ต้องคิดเรื่องนี้.”

→ ความแตกต่างอาจปรากฏในค่าเริ่มต้นหรือพฤติกรรมการอัปเดต ขึ้นอยู่กับสภาพแวดล้อม.

❌ “SYSDATE() มีความแม่นยำมากกว่า ดังนั้นจึงดีกว่าเสมอ.”

→ อาจทำให้เกิดปัญหาในสภาพแวดล้อมการทำสำเนา.

❌ ไม่ตรวจสอบโซนเวลา

SHOW VARIABLES LIKE '%time_zone%';

หากคุณใช้โดยไม่ตรวจสอบ คุณอาจได้รับการชดเชยเวลา.

2.6 แนวทางปฏิบัติที่ดีที่สุด

• การดึงข้อมูลด้วย SELECT → NOW()
• ค่าเริ่มต้นของคอลัมน์ → CURRENT_TIMESTAMP
• การอัปเดตอัตโนมัติ → ON UPDATE CURRENT_TIMESTAMP
• เน้นความสอดคล้อง → ตั้งค่าเริ่มต้นเป็น NOW()
• การออกแบบแบบใช้ UTC → TIMESTAMP + เก็บเป็น UTC

3. MySQL Current Time Formatting (DATE_FORMAT / TIME_FORMAT)
   หลังจากดึงเวลาปัจจุบันใน MySQL มาแล้ว การ เปลี่ยนรูปแบบการแสดงผล เป็นเรื่องที่ทำบ่อยมาก
   สำหรับความต้องการค้นหา “MySQL current time format” ฟังก์ชันที่สำคัญที่สุดคือ DATE_FORMAT()

3.1 MySQL datetime formatting: DATE_FORMAT(NOW(), …)

ไวยากรณ์พื้นฐาน:
SELECT DATE_FORMAT(target_datetime, 'format_string');

ตัวอย่าง: ฟอร์แมตเวลาปัจจุบัน
SELECT DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s');

ผลลัพธ์ตัวอย่าง
2025-02-01 15:30:45

สัญลักษณ์ฟอร์แมตที่ใช้บ่อย

3.2 การแปลงเป็นรูปแบบสไตล์ญี่ปุ่นหรือ 12‑hour

■ รูปแบบสไตล์ญี่ปุ่น
SELECT DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i');

ผลลัพธ์ตัวอย่าง:
2025-02-01 15:30

■ รูปแบบ 12‑hour + AM/PM
SELECT DATE_FORMAT(NOW(), '%Y-%m-%d %h:%i:%s %p');

ผลลัพธ์ตัวอย่าง:
2025-02-01 03:30:45 PM

3.3 MySQL time‑only formatting: TIME_FORMAT()

ฟังก์ชันฟอร์แมตเฉพาะสำหรับข้อมูลชนิด TIME

SELECT TIME_FORMAT(CURTIME(), '%H:%i');

ผลลัพธ์ตัวอย่าง:
15:30

หมายเหตุ
– TIME_FORMAT() ใช้ได้กับชนิด TIME เท่านั้น
– สำหรับ DATETIME ให้ใช้ DATE_FORMAT()

3.4 การแปลง String → datetime: STR_TO_DATE()

เพื่อแปลงข้อความเป็นชนิด datetime

SELECT STR_TO_DATE('2025-02-01 15:30:45', '%Y-%m-%d %H:%i:%s');

ผลลัพธ์ตัวอย่าง:
2025-02-01 15:30:45

ข้อผิดพลาดที่พบบ่อย
– ฟอร์แมตไม่ตรงกันจะคืนค่า NULL
– สับสนระหว่าง %m กับ %c (เดือนที่เติมศูนย์นำหน้า vs ไม่เติม)

3.5 จุดสำคัญในงานผลิต

❌ ห้ามเปรียบเทียบหลังจากฟอร์แมต
ตัวอย่างที่ไม่ดี:
WHERE DATE_FORMAT(created_at, '%Y-%m-%d') = '2025-02-01';

นี่ ไม่แนะนำ เพราะทำให้ดัชนีไม่ทำงาน (ประสิทธิภาพการค้นหาลดลง)

แนะนำ:
WHERE created_at >= '2025-02-01' AND created_at < '2025-02-02';

❌ ห้ามฟอร์แมตเกินความจำเป็นบน DB
ในเว็บแอป การฟอร์แมตเพื่อแสดงผลมักทำได้ยืดหยุ่นที่ระดับแอปพลิเคชัน
ฐานข้อมูลควรเน้นที่ “การเก็บและการคำนวณ”

3.6 ฟอร์แมตพร้อมมิลลิวินาที

SELECT DATE_FORMAT(NOW(3), '%Y-%m-%d %H:%i:%s.%f');

%f แทนไมโครวินาที (6 หลัก)

หมายเหตุ
– หากคอลัมน์ไม่ได้เป็น DATETIME(3) หรือคล้ายกัน ส่วนเศษจะถูกตัดออก
– มีให้ใช้ตั้งแต่ MySQL 5.6 ขึ้นไป

3.7 สรุปตามวัตถุประสงค์การฟอร์แมต

4. MySQL Date and Time Addition/Subtraction (DATE_ADD / DATE_SUB)

แม้คุณจะดึงเวลาปัจจุบันได้แล้ว ก็ยังไม่สามารถใช้ได้อย่างมีประสิทธิภาพในงานผลิตหากไม่มีการคำนวณวัน/เวลา เช่น “X วันต่อมา” หรือ “X ชั่วโมงที่แล้ว”
ต่อไปนี้เป็นวิธีใช้ DATE_ADD() และ DATE_SUB() ร่วมกับเวลาปัจจุบันใน MySQL

4.1 MySQL datetime addition: DATE_ADD()

ไวยากรณ์พื้นฐาน:
SELECT DATE_ADD(base_datetime, INTERVAL value unit);

ตัวอย่าง: 7 วันจากตอนนี้
SELECT DATE_ADD(NOW(), INTERVAL 7 DAY);

ตัวอย่าง: 2 ชั่วโมงต่อมา
SELECT DATE_ADD(NOW(), INTERVAL 2 HOUR);

หน่วยที่ใช้บ่อย

4.2 MySQL datetime subtraction: DATE_SUB()

ไวยากรณ์พื้นฐาน:
SELECT DATE_SUB(base_datetime, INTERVAL value unit);

ตัวอย่าง: 30 วันก่อนหน้า
SELECT DATE_SUB(NOW(), INTERVAL 30 DAY);

ตัวอย่าง: 1 ชั่วโมงก่อนหน้า
SELECT DATE_SUB(NOW(), INTERVAL 1 HOUR);

กรณีใช้งาน
– ตรวจสอบวันหมดอายุ
– ลบบันทึกเก่า
– ดึงข้อมูลล่าสุด

4.3 แพทเทิร์นที่พบบ่อยในงานผลิต

■ ดึงข้อมูลจาก 24 ชั่วโมงล่าสุด
SELECT * FROM logs WHERE created_at >= DATE_SUB(NOW(), INTERVAL 1 DAY);

■ ตั้งกำหนดเวลาสิ้นสุด 7 วันต่อมา
INSERT INTO tasks (deadline) VALUES (DATE_ADD(NOW(), INTERVAL 7 DAY));

4.4 ความผิดพลาดทั่วไปและข้อควรระวัง
❌ การใช้ฟังก์ชันกับคอลัมน์
ตัวอย่างที่ไม่ดี:
WHERE DATE(created_at) = CURDATE();
สิ่งนี้จะทำให้ดัชนีไม่ทำงาน (การเพิ่มประสิทธิภาพการ query)
แนะนำ:
WHERE created_at >= CURDATE() AND created_at < DATE_ADD(CURDATE(), INTERVAL 1 DAY);
❌ การละเลยโซนเวลา
NOW() อิงตามโซนเวลาของเซิร์ฟเวอร์
หากคุณเก็บเป็น UTC ให้ใช้ UTC_TIMESTAMP() เป็นฐาน
ตัวอย่าง:
SELECT DATE_ADD(UTC_TIMESTAMP(), INTERVAL 1 DAY);
❌ ปัญหาในการบวกเดือน
SELECT DATE_ADD('2025-01-31', INTERVAL 1 MONTH);
→ เนื่องจากการปรับตามวันสุดท้ายของเดือน วันที่อาจเปลี่ยนแปลงได้
(ผลลัพธ์อาจเป็น 2025-02-28 ขึ้นอยู่กับสภาพแวดล้อม)
ควรทำความเข้าใจสเปคก่อนใช้การคำนวณแบบเดือน

4.5 การบวกมิลลิวินาที
SELECT DATE_ADD(NOW(3), INTERVAL 500 MILLISECOND);
※ MySQL ไม่รองรับ MILLISECOND โดยตรง
ระบุเป็นไมโครวินาที:
SELECT DATE_ADD(NOW(3), INTERVAL 500000 MICROSECOND);

4.6 แนวปฏิบัติที่ดีที่สุด
มาตรฐานการใช้ NOW() หรือ UTC_TIMESTAMP() เป็นฐานของคุณ
อย่าใช้ฟังก์ชันกับคอลัมน์ในเงื่อนไข WHERE
ทำความเข้าใจพฤติกรรมของการบวกแบบเดือน
หากต้องการความแม่นยำ ให้ใช้ DATETIME(3) หรือสูงกว่า

5. การคำนวณความแตกต่างของวัน/เวลาใน MySQL (DATEDIFF / TIMESTAMPDIFF)

ในระบบการผลิต การดึงเวลาปัจจุบันเพียงอย่างเดียวไม่พอ คุณมักต้องคำนวณ จำนวนวันที่ผ่านไป หรือ จำนวนชั่วโมงที่เหลือ

5.1 การคำนวณความแตกต่างของวัน: DATEDIFF()

DATEDIFF() คำนวณความแตกต่างเป็นวันระหว่างสองวันที่

SELECT DATEDIFF('2025-02-10', '2025-02-01');

ผลลัพธ์

9

จุดสำคัญ

• คืนค่าความแตกต่างเป็น วันเท่านั้น
• ส่วนของเวลาจะถูกละเว้น
• ผลลัพธ์อาจเป็นค่าลบ

ตัวอย่าง: คำนวณจำนวนวันตั้งแต่สร้าง

SELECT DATEDIFF(NOW(), created_at)
FROM users;

5.2 การคำนวณความแตกต่างตามหน่วย: TIMESTAMPDIFF()

TIMESTAMPDIFF() ให้คุณระบุหน่วยที่ต้องการ

SELECT TIMESTAMPDIFF(unit, start_datetime, end_datetime);

ตัวอย่าง: ความแตกต่างเป็นชั่วโมง

SELECT TIMESTAMPDIFF(HOUR, '2025-02-01 10:00:00', '2025-02-01 15:00:00');

ผลลัพธ์

5

หน่วยที่พบบ่อย

ตัวอย่าง: คำนวณนาทีตั้งแต่เข้าสู่ระบบ

SELECT TIMESTAMPDIFF(MINUTE, login_at, NOW())
FROM users;

5.3 กรณีการใช้งานในระบบผลิต

• ตรวจสอบการหมดเวลาเซสชัน
• ตรวจสอบการหมดอายุการสมัครสมาชิก
• คำนวณเวลาที่ผ่านไปในบันทึก
• โลจิกการจำกัดอัตรา (rate limiting)

5.4 ความผิดพลาดทั่วไป

❌ ใช้ DATEDIFF เมื่อจำเป็นต้องมีความแม่นยำของเวลา

DATEDIFF() ไม่สนใจชั่วโมงและนาที

❌ สลับลำดับอาร์กิวเมนต์

ลำดับที่ถูกต้องคือ:

TIMESTAMPDIFF(unit, start, end)

หากสลับกัน ผลลัพธ์จะเป็นค่าลบ

❌ ละเลยโซนเวลา

หากผสม UTC กับเวลาในท้องถิ่น ความแตกต่างอาจไม่ถูกต้อง

5.5 แนวปฏิบัติที่ดีที่สุด

• ใช้ TIMESTAMPDIFF() เมื่อความแม่นยำของเวลามีความสำคัญ
• ใช้ DATEDIFF() สำหรับการคำนวณวันอย่างง่าย
• รักษาการใช้โซนเวลาให้สอดคล้องกัน
• มาตรฐานการใช้ UTC ในระบบกระจาย

6. การค้นหาเรนจ์ของวันที่โดยใช้เวลาปัจจุบัน

หนึ่งในความต้องการที่พบบ่อยที่สุดในโลกจริงคือการดึงข้อมูลที่อยู่ในช่วงเวลาที่กำหนด เช่น:

• รายการของวันนี้
• 7 วันที่ผ่านมา
• 24 ชั่วโมงที่ผ่านมา
• เดือนนี้

6.1 ดึงรายการของวันนี้ (เป็นมิตรกับดัชนี)

SELECT *
FROM logs
WHERE created_at >= CURDATE()
  AND created_at < DATE_ADD(CURDATE(), INTERVAL 1 DAY);

ทำไมวิธีนี้จึงถูกต้อง

• ไม่ได้ใช้ฟังก์ชันกับคอลัมน์
• ดัชนียังคงใช้งานได้
• คำสั่ง query ช่วงเวลามีประสิทธิภาพ

6.2 7 วันที่ผ่านมา

SELECT *
FROM logs
WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY);

6.3 24 ชั่วโมงที่ผ่านมา

SELECT *
FROM logs
WHERE created_at >= DATE_SUB(NOW(), INTERVAL 1 DAY);

6.4 เดือนนี้

SELECT *
FROM logs
WHERE created_at >= DATE_FORMAT(NOW(), '%Y-%m-01')
  AND created_at < DATE_ADD(DATE_FORMAT(NOW(), '%Y-%m-01'), INTERVAL 1 MONTH);

ในระบบการผลิต มักจะดีกว่าที่จะคำนวณขอบเขตบนฝั่งแอปพลิเคชันและส่งผ่านเป็นพารามิเตอร์

6.5 ข้อผิดพลาดด้านประสิทธิภาพทั่วไป

❌ การใช้ฟังก์ชันกับคอลัมน์ที่มีดัชนี

WHERE DATE(created_at) = CURDATE();

นี่จะป้องกันการใช้ดัชนีและทำให้ต้องสแกนตารางทั้งหมด.

❌ การใช้ BETWEEN อย่างไม่ระมัดระวัง

BETWEEN มีการรวมค่าและอาจทำให้เกิดปัญหา off-by-one-second issues.

6.6 สรุปแนวปฏิบัติที่ดีที่สุด

• ใช้เงื่อนไขช่วงเสมอสำหรับการกรองวันที่
• หลีกเลี่ยงการใช้ฟังก์ชันกับคอลัมน์ที่มีดัชนี
• ควรเก็บข้อมูลในรูปแบบ UTC ในระบบทั่วโลก
• ระบุอย่างชัดเจนเกี่ยวกับสมมติฐานโซนเวลา