ตัวอย่างเคส: หน้า Checkout โหลดช้าเพราะ Database หน่วง

หน้า Checkout ที่โหลดช้าคือฝันร้ายของเจ้าของร้านออนไลน์ WooCommerce เพราะทุกวินาทีที่ลูกค้ารอ คือโอกาสที่เขาจะกด X ออกไปซื้อของที่อื่น เคสนี้เกิดขึ้นกับลูกค้าร้านค้าออนไลน์รายหนึ่ง ที่พบว่าหน้า Checkout ใช้เวลาโหลดนานกว่า 10 วินาที ทั้งที่หน้าอื่น ๆ บนเว็บยังปกติดี หลังตรวจสอบเชิงลึก พบว่าต้นเหตุอยู่ที่ฐานข้อมูล (Database) ที่หน่วงและบวมขึ้นเรื่อย ๆ โดยไม่มีใครรู้ตัว

nn

อาการที่พบ

n

ลูกค้าร้องเรียนว่าหน้า Checkout โหลดนาน บางครั้งวนค้างไม่ยอมแสดงผล ทดสอบด้วย Chrome DevTools พบว่า TTFB (Time To First Byte) สูงถึง 8–12 วินาที ทั้งที่หน้าสินค้าหรือหน้าแรกปกติ ไม่พบ error ใน log ชัดเจน แต่หากเปิด Query Monitor plugin จะเห็นว่ามี SQL query บางตัวใช้เวลาสูงถึง 3–5 วินาทีต่อ query เพียงแค่หน้าเดียว

n

nn

สาเหตุที่แท้จริง

n

หลังตรวจสอบพบปัญหาหลัก 3 ประการที่ทับซ้อนกัน:

n

n
• ตาราง wp_options บวมอย่างหนัก — มีข้อมูล transient cache ที่หมดอายุแล้วสะสมอยู่กว่า 80,000 แถว ทำให้ทุก query ที่ต้องอ่านค่า option ช้าลงมาก

n

• ตาราง wp_woocommerce_sessions ไม่เคยถูก cleanup — มี session ของลูกค้าเก่าสะสมกว่า 200,000 แถว WooCommerce ต้องสแกนตารางนี้ทุกครั้งที่โหลดหน้า Checkout

n

• ไม่มี Index ที่เหมาะสม — ตาราง wp_postmeta ถูก query แบบ full table scan เพราะ plugin บางตัวเขียน meta key ในรูปแบบที่ไม่ได้ใช้ index

n

nn

วิธีตรวจสอบด้วยตัวเอง

n

ก่อนแก้ไข ควรยืนยันว่าปัญหาอยู่ที่ Database จริง ๆ ด้วยขั้นตอนดังนี้:

n

n
• ติดตั้ง Query Monitor plugin แล้วเปิดหน้า Checkout — ดูที่แถบ “Queries” ถ้าพบ query ที่ใช้เวลาเกิน 0.5 วินาที นั่นคือสัญญาณอันตราย

n

• เข้า phpMyAdmin แล้วดูขนาดตาราง หากตาราง wp_options หรือ wp_woocommerce_sessions มีขนาดเกิน 50 MB ให้ถือว่าผิดปกติ

n

• รัน SQL นี้เพื่อนับ transient หมดอายุ: SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP();

n

• ใช้เครื่องมือออนไลน์อย่าง GTmetrix หรือ WebPageTest วัด TTFB เฉพาะหน้า Checkout — ถ้า TTFB สูงกว่า 2 วินาที แสดงว่าปัญหาอยู่ที่ server-side ไม่ใช่ frontend

n

n

nn

วิธีแก้ไขทีละขั้นตอน

n

แนะนำให้ทำตามลำดับนี้ และ สำรองข้อมูล (backup) ก่อนทุกครั้ง:

n

n
• ขั้นที่ 1 — ล้าง Transient หมดอายุ: ใช้ plugin WP-Optimize หรือรัน SQL โดยตรง: DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_name LIKE '%timeout%' AND option_value < UNIX_TIMESTAMP(); แล้วตามด้วยการลบ transient ที่ค้างอยู่

n

• ขั้นที่ 2 — Cleanup WooCommerce Sessions: ไปที่ WooCommerce → Status → Tools แล้วกด “Clear customer sessions” หรือใช้ WP-CLI: wp wc tool run clear_sessions --user=1

n

• ขั้นที่ 3 — Optimize ตาราง Database: ใน phpMyAdmin เลือกตารางทั้งหมด แล้วรัน “Optimize Table” หรือใช้ WP-Optimize ในโหมด Database Optimize เพื่อ defragment และ rebuild index

n

• ขั้นที่ 4 — เพิ่ม Object Cache: หากโฮสต์รองรับ ให้เปิดใช้ Redis หรือ Memcached เพื่อให้ WordPress cache ผล query ไว้ในหน่วยความจำ ลด Database hit ลงอย่างมาก

n

• ขั้นที่ 5 — ตรวจสอบ Plugin ที่เขียน Database บ่อย: ใช้ Query Monitor ดูว่า plugin ตัวไหนยิง query มากที่สุด พิจารณาเปลี่ยนหรืออัปเดต plugin นั้น

n

nn

nn

วิธีป้องกันไม่ให้เกิดซ้ำ

n

การแก้ปัญหาครั้งเดียวไม่เพียงพอ หากไม่มีระบบดูแลต่อเนื่อง ปัญหาจะวนกลับมาภายใน 2–3 เดือน:

n

n
• ตั้ง Scheduled Cleanup ด้วย WP-Optimize หรือ Advanced Database Cleaner ให้ทำงานอัตโนมัติทุกสัปดาห์

n

• ใช้ Object Caching (Redis/Memcached) ถาวร เพื่อลดภาระ Database ในระยะยาว

n

• ตั้งค่า WooCommerce Session Expiry ให้สั้นลง และเปิดใช้ Cron cleanup ใน WooCommerce settings

n

• ติดตาม Database size ผ่าน hosting control panel อย่างน้อยเดือนละครั้ง หากขนาดโตผิดปกติให้ตรวจสอบทันที

n

• อัปเดต WordPress, WooCommerce และ plugin ให้เป็น version ล่าสุดอยู่เสมอ เพราะ update มักมาพร้อม query optimization — อ่านเพิ่มเติมเรื่องนี้ได้ที่ WooCommerce Checkout ไม่ได้

n

nn

เมื่อไหร่ควรเรียกผู้เชี่ยวชาญ

n

บางกรณีการแก้ไขด้วยตัวเองอาจไม่เพียงพอ โดยเฉพาะเมื่อ:

n

n
• ทำตามขั้นตอนข้างต้นแล้วแต่ยังช้าอยู่ หรือช้าลงเรื่อย ๆ อีกครั้งภายในเวลาสั้น อาจมีสาเหตุซ่อนอยู่ลึกกว่า เช่น Malware ที่คอยเขียนข้อมูลลง Database — ดูอาการเพิ่มเติมได้ที่บทความ อาการ WordPress ติดมัลแวร์

n

• ไม่มีสิทธิ์เข้าถึง phpMyAdmin หรือ WP-CLI โดยตรง ซึ่งจำเป็นสำหรับการ optimize ระดับ Database

n

• เว็บเคยมีปัญหา Error 500 ร่วมด้วย ซึ่งอาจเป็นสัญญาณว่ามีปัญหาหลายจุดพร้อมกัน อ่านวิธีรับมือได้ที่ เคส WordPress Error 500 หลังอัปเดต Plugin

n

• ร้านค้ามียอดขายสูง และการ downtime หรือ checkout ช้า 1 ชั่วโมงมีผลกระทบต่อรายได้โดยตรง

n

n

ในกรณีเหล่านี้ ทีม บริการล้างไวรัสและซ่อม WordPress ของเราพร้อมเข้าตรวจสอบและแก้ไขให้ตรงจุด รวมถึงวาง checklist ป้องกันระยะยาวตาม Checklist ความปลอดภัย WordPress ให้ด้วย

คำถามที่พบบ่อย

หน้า Checkout โหลดช้า แต่หน้าอื่นปกติ เกิดจากอะไร?

ส่วนใหญ่เกิดจาก Database หน่วง โดยเฉพาะตาราง wp_options ที่มี transient cache สะสม และตาราง wp_woocommerce_sessions ที่ไม่เคย cleanup เพราะหน้า Checkout เรียกใช้ Database มากกว่าหน้าอื่น จึงได้รับผลกระทบก่อน

ต้องลบข้อมูลใน Database ไหม? กลัวข้อมูลหาย

ที่ลบคือ transient หมดอายุและ session เก่าที่ไม่มีประโยชน์แล้ว ไม่ใช่ข้อมูลสินค้าหรือออเดอร์ แต่ควร backup ก่อนทุกครั้งเพื่อความปลอดภัย

ใช้ plugin cache อยู่แล้ว ทำไมยังช้า?

Page cache ช่วยหน้าที่เป็น static ได้ดี แต่หน้า Checkout จะถูก bypass cache เสมอเพราะเป็นหน้า dynamic ที่ต้องตรวจสอบ session และข้อมูลเรียลไทม์ ดังนั้นต้องแก้ที่ Database โดยตรงหรือใช้ Object Cache แทน

ทำ Database Optimize เสร็จแล้ว ต้องทำซ้ำบ่อยแค่ไหน?

แนะนำให้ตั้งให้ทำงานอัตโนมัติทุกสัปดาห์หรืออย่างน้อยเดือนละครั้ง สำหรับร้านที่มียอดขายสูงและมี traffic มาก ควรทำทุกสัปดาห์เพื่อป้องกันไม่ให้ตารางบวมใหม่