PostgreSQL หรือ MySQL: ผลทดสอบเร็วกว่า 6.6 เท่าไม่ได้ตอบทุกระบบ

ในการทดสอบ sysbench เมื่อเดือนมีนาคม 2026 ผล benchmark ของ ComputingForGeeks วัด throughput งานอ่านเขียนผสมของ PostgreSQL 17.9 ได้สูงกว่า MySQL 8.4.8 ประมาณ 6.6 เท่า บนเครื่องและชุดคำสั่งที่ผู้ทดสอบกำหนดไว้ หากระบบต้องอ่านและแก้ไขข้อมูลพร้อมกันมาก PostgreSQL จึงมีเหตุผลด้านประสิทธิภาพให้พิจารณาอย่างจริงจัง แต่ผลนี้ยังบอกไม่ได้ว่าระบบธุรกรรมทุกระบบจะเร็วขึ้นในสัดส่วนเดียวกัน

คำตอบในการเลือกระหว่างฐานข้อมูลทั้งสองคือดูว่าธุรกรรมของแอปพลิเคชันประกอบด้วยคำสั่งใด ใช้ข้อมูลและดัชนีแบบไหน และต้องรักษาเวลาตอบสนองเมื่อมีงานพร้อมกันมากเพียงใด ผลอ่านล้วนในชุดทดสอบเดียวกันห่างกันน้อยกว่างานอ่านเขียนผสมมาก ส่วนงานเพิ่มแถวให้ภาพอีกแบบหนึ่ง การนำตัวเลขจากงานประเภทเดียวไปคาดการณ์ทุกหน้าจอหรือทุก API จึงเสี่ยงต่อการเลือกผิด

งานอ่านล้วน อ่านเขียนผสม และ INSERT ให้คำตอบต่างกัน

ชุดทดสอบแยกภาระงานที่มักถูกรวมเป็นคำว่า “ฐานข้อมูลเร็ว” ออกจากกัน ผลทั้งสามประเภทวัดด้วยเครื่องมือเดียวกันบน VM เครื่องเดียว แต่แต่ละประเภทใช้ทรัพยากรและเผชิญการทำงานพร้อมกันต่างกัน ตัวเลขที่มีประโยชน์จึงเป็นคู่ของ throughput กับ latency ภายในงานประเภทเดียวกัน ไม่ใช่ TPS สูงสุดเพียงค่าเดียว

• อ่านล้วน: PostgreSQL ทำได้ 5,628 TPS และ MySQL ทำได้ 5,400 TPS โดย latency เฉลี่ยอยู่ที่ 2.84 และ 2.96 มิลลิวินาทีตามลำดับ ผลคู่นี้บอกว่าช่องว่างเล็กเมื่อชุดคำสั่งไม่มีการแก้ไขข้อมูล แต่ยังไม่แทนคำขออ่านจริงที่อาจมีการเชื่อมหลายตารางหรือส่งผลลัพธ์จำนวนมาก
• อ่านเขียนผสม: PostgreSQL ทำได้ 2,886 TPS ที่ latency เฉลี่ย 5.54 มิลลิวินาที ส่วน MySQL ทำได้ 436 TPS ที่ 36.6 มิลลิวินาที ค่า latency ที่เปอร์เซ็นไทล์ 95 อยู่ที่ 8.74 และ 90.78 มิลลิวินาทีตามลำดับ ชุดนี้รวม SELECT, UPDATE, INSERT และ DELETE จึงใกล้กับธุรกรรมที่ต้องอ่านก่อนเปลี่ยนสถานะข้อมูลมากกว่างานอ่านล้วน
• INSERT: PostgreSQL ทำได้ 7,255 TPS ที่ latency เฉลี่ย 2.20 มิลลิวินาที เทียบกับ MySQL ที่ 2,206 TPS และ 7.25 มิลลิวินาที ผลของการเพิ่มแถวอย่างเดียวไม่ควรใช้แทนธุรกรรมที่ต้องค้นหา ตรวจเงื่อนไข แล้วจึงบันทึกข้อมูล เพราะธุรกรรมหลังมีต้นทุนของคำสั่งและโอกาสรอที่ต่างออกไป

TPS นับธุรกรรมที่เสร็จต่อวินาที ส่วน latency วัดเวลาของธุรกรรมหนึ่งรายการ ความสัมพันธ์ของสองค่านี้ขึ้นกับจำนวนงานที่กำลังทำพร้อมกันด้วย ระบบหนึ่งอาจรับงานรวมได้มาก แต่ยังมีคำขอบางส่วนรอนานจนกระทบผู้ใช้ จึงควรมองค่าเฉลี่ยควบกับค่าปลายช่วงอย่างเปอร์เซ็นไทล์ 95 โดยเฉพาะเส้นทางที่มีข้อกำหนดเวลา เช่น การยืนยันรายการหรือการเปลี่ยนสถานะคำสั่งซื้อ

หนึ่งธุรกรรมใน sysbench ไม่จำเป็นต้องเท่ากับหนึ่งคำขอของแอปพลิเคชัน คำขอจริงอาจเปิดธุรกรรมหลายครั้ง มีการเรียกบริการอื่นก่อนตอบกลับ หรือมีคำสั่งที่ทดสอบนี้ไม่ได้ใช้ หากต้องการตีความ TPS ให้เป็นกำลังรองรับผู้ใช้ ต้องรู้ก่อนว่าคำขอแต่ละชนิดสร้างธุรกรรมกี่ครั้งและใช้เวลานอกฐานข้อมูลเท่าใด ผล benchmark นี้จึงใช้ชี้จุดที่ควรทดสอบต่อได้ดีกว่าใช้เป็นตัวคูณกำลังรองรับของทั้งบริการ

ขอบเขตของเครื่อง เวอร์ชัน และเวลาทดสอบ

ผู้ทดสอบใช้ Rocky Linux 10.1 บน VM ที่มี 4 vCPU หน่วยความจำ 8 GB และพื้นที่เก็บข้อมูล SSD แบบ LVM thin provisioning เปิดฐานข้อมูลทีละระบบเพื่อไม่ให้แย่งทรัพยากรกัน sysbench 1.0.20 ทำงานในเครื่องเดียวกับฐานข้อมูล จึงไม่มีเวลาเดินทางผ่านเครือข่ายอยู่ในค่า latency ที่รายงาน การจัดสภาพแวดล้อมเช่นนี้ช่วยให้เห็นความต่างบนเครื่องนั้นชัดขึ้น แต่แอปพลิเคชันที่เชื่อมต่อจากอีกเครื่องจะมีต้นทุนเพิ่มอีกชั้น

ข้อมูลมี 10 ตาราง ตารางละ 100,000 แถว ใช้ 16 เธรด และรันแต่ละภาระงาน 60 วินาที ตัวเลขเหล่านี้สำคัญเพราะขนาดข้อมูลมีผลต่อการใช้แคช ส่วนจำนวนเธรดมีผลต่อการแย่งทรัพยากรและการรอ เงื่อนไขของฐานข้อมูลที่เก็บข้อมูลมากกว่านี้มาก หรือมีจำนวนการเชื่อมต่อขึ้นลงตามช่วงเวลา อาจทำให้ลำดับของคอขวดเปลี่ยนไป

ผู้ทดสอบกำหนด shared_buffers ของ PostgreSQL และ innodb_buffer_pool_size ของ MySQL ไว้ที่ 2 GB เท่ากัน แต่ตัวแปรสองตัวนี้อยู่ในสถาปัตยกรรมคนละแบบและไม่ได้ทำให้การใช้หน่วยความจำทั้งหมดเท่ากัน การตั้งค่าของ PostgreSQL ยังระบุ work_mem, effective_cache_size และค่าที่เกี่ยวกับ checkpoint ขณะที่ฝั่ง MySQL ระบุ innodb_flush_log_at_trx_commit ไว้ด้วย ดังนั้นคำว่า “ฮาร์ดแวร์เดียวกัน” เป็นเงื่อนไขที่จำเป็นต่อการเทียบ แต่ไม่รับประกันว่าต้นทุนการจัดการแคช บันทึกธุรกรรม และความทนทานของข้อมูลถูกตั้งให้เทียบกันได้ทุกมิติ

ระยะเวลาที่สั้นช่วยวัดอัตราการทำงานภายใต้โหลดที่กำหนด แต่ระบบผลิตต้องรับงานต่อเนื่อง มีช่วงที่ข้อมูลหรือดัชนีเปลี่ยน และอาจมีธุรกรรมที่เปิดค้างนานกว่างานทดสอบ การทดสอบที่ยาวขึ้นมีโอกาสเผยต้นทุนการเก็บกวาดข้อมูลเก่า การเขียนลงพื้นที่เก็บข้อมูล และผลของแคชที่เปลี่ยนระหว่างวัน ข้อจำกัดนี้ไม่ได้ลบผลต่างที่วัดได้ใน VM ดังกล่าว เพียงกำหนดว่าผลต่างนั้นนำไปอ้างกับสภาพแวดล้อมใดได้บ้าง

MVCC ดัชนี และการเก็บกวาดข้อมูลเกี่ยวข้องอย่างไร

เอกสาร MVCC ของ PostgreSQL อธิบายว่าคำสั่งอ่านเห็นภาพข้อมูลที่สอดคล้องกัน และการอ่านตามกลไกนี้ไม่ขัดกับการเขียน จึงลดการแย่งล็อกเมื่อมีผู้ใช้หลายราย ประโยชน์นี้ตรงกับระบบที่ต้องอ่านระหว่างมีการแก้ไขข้อมูล อย่างไรก็ตาม ธุรกรรมที่ต้องเปลี่ยนแถวเดียวกันยังอาจต้องรอกัน และคำสั่งที่ขอล็อกโดยชัดแจ้งก็มีพฤติกรรมต่างจากการอ่านตามปกติ

เอกสาร InnoDB ของ MySQL ระบุว่าเอนจินนี้เก็บข้อมูลของแถวเวอร์ชันเก่าใน undo เพื่อรองรับการอ่านอย่างสอดคล้อง การทำงานพร้อมกัน และ rollback เช่นกัน เมื่อคอลัมน์ใน secondary index ถูกแก้ไข InnoDB จะทำเครื่องหมายรายการดัชนีเก่า เพิ่มรายการใหม่ และเก็บกวาดรายการเก่าภายหลัง รายละเอียดนี้ทำให้รูปแบบ UPDATE และดัชนีที่มีอยู่มีผลต่อปริมาณงานที่ฐานข้อมูลต้องทำ

ทั้ง PostgreSQL และ InnoDB จึงใช้ข้อมูลหลายเวอร์ชัน การอธิบายผลต่างของ TPS ว่าเกิดจากระบบหนึ่งมี MVCC แต่อีกระบบไม่มี เป็นการระบุสาเหตุผิดประเด็น สิ่งที่ต้องแยกต่อคือคำสั่งใดรอล็อก คำสั่งใดอ่านแถวผ่านดัชนี คำสั่งใดต้องเขียนดัชนีหลายรายการ และเวลาที่เสียไปอยู่ที่ CPU หรือ I/O มากกว่า ตัวเลขรวมของงานอ่านเขียนผสมบอกผลที่เกิดขึ้น แต่ไม่ได้แยกต้นทุนเหล่านี้ออกจากกัน

ดัชนีช่วยให้ค้นหาแถวได้เร็วเมื่อเงื่อนไขและความกระจายของข้อมูลเหมาะสม ขณะเดียวกันดัชนีที่ต้องปรับตามการเขียนก็เพิ่มงานให้ INSERT, UPDATE หรือ DELETE ด้วย หากชุดทดสอบใช้ตารางและดัชนีที่ต่างจากระบบจริง แม้ SQL จะอยู่ในหมวดอ่านเขียนเหมือนกัน ผลก็อาจเปลี่ยนมาก ตารางที่มีการแก้ไขคอลัมน์ซึ่งถูกทำดัชนีบ่อยควรถูกแยกจากตารางที่เพิ่มแถวเป็นหลัก เพราะภาระงานของดัชนีไม่เหมือนกัน

เอกสาร VACUUM ของ PostgreSQL อธิบายว่าการ UPDATE และ DELETE ทิ้งแถวเวอร์ชันเก่าซึ่งต้องเก็บกวาดเพื่อใช้พื้นที่ซ้ำ และงานเก็บกวาดอาจสร้าง I/O จนกระทบงานอื่น ธุรกรรมที่เปิดค้างนานอาจทำให้บางเวอร์ชันเก่ายังถูกลบไม่ได้ ฝั่ง InnoDB ก็ต้องเก็บ undo ไว้ตราบที่ยังมีการอ่านซึ่งอาจต้องใช้ข้อมูลเวอร์ชันนั้น ภาระที่เกิดหลังจากเขียนต่อเนื่องจึงเป็นส่วนหนึ่งของการเทียบระบบธุรกรรม ไม่ใช่เพียงเวลาของคำสั่งเดี่ยวในช่วงสั้น

ออกแบบ benchmark ซ้ำให้ตรงกับธุรกรรมจริง

แนวทาง benchmark ของ MySQL แยกการวัดคำสั่งเดี่ยวออกจากการวัดภาระงานตลอดช่วงเวลา และระบุว่าผลอาจเปลี่ยนเมื่อสภาพแวดล้อมเปลี่ยน การทดสอบเพื่อเลือกฐานข้อมูลจึงควรเริ่มจากธุรกรรมที่บริการใช้อยู่จริง ไม่ใช่เริ่มจากการปรับค่าให้ได้ TPS สูงที่สุดในชุดคำสั่งสำเร็จรูป เป้าหมายคือให้สองระบบทำงานที่มีความหมายทางธุรกิจเดียวกันภายใต้ทรัพยากรระดับเดียวกัน

ก่อนสร้างโหลด ให้จัดกลุ่มคำขอจากระบบผลิต เช่น การเปิดรายการ การค้นหารายการตามเงื่อนไข การแก้ไขสถานะ และการบันทึกรายการใหม่ แล้วหาสัดส่วนและช่วงเวลาที่งานเหล่านี้เกิดพร้อมกัน ตัวอย่างเช่น หากช่วงเร่งด่วนมีการแก้ไขแถวสถานะเดิมซ้ำ การสุ่มเขียนกระจายทั่วตารางจะลดการแย่งแถวและให้ภาพที่ดูดีกว่าความจริง ตัวอย่างนี้เป็นเงื่อนไขสมมติสำหรับออกแบบการทดสอบ ไม่ใช่ข้ออ้างว่าทุกระบบมีแถวร้อนแบบเดียวกัน

1. กำหนดหน่วยที่วัด: ระบุว่าหนึ่งธุรกรรมเริ่มและจบตรงไหน รวมการตรวจเงื่อนไขและการบันทึกจริงหรือไม่ หากเส้นทางผู้ใช้มีหลายคำสั่ง ให้ทดสอบลำดับคำสั่งและขอบเขต commit เดียวกับบริการจริง จดสัดส่วน SELECT, UPDATE, INSERT และ DELETE แยกตามชนิดคำขอเพื่อไม่ให้ผลรวมกลบงานที่สำคัญ
2. ทำข้อมูลและดัชนีให้ใกล้จริง: ใช้ปริมาณข้อมูล ความกระจายของค่า ความยาวแถว และความถี่ของค่าที่ซ้ำใกล้ระบบผลิต ตรวจดัชนีสำหรับเงื่อนไขค้นหาและการเรียงลำดับที่ใช้จริง รวมถึงจำนวนดัชนีที่ต้องปรับเมื่อเขียน ดูแผนการรันคำสั่งทั้งสองฝั่ง เพราะ SQL ที่ให้คำตอบเหมือนกันอาจสแกนข้อมูลคนละทาง
3. ตรึงเงื่อนไขของระบบ: บันทึกเวอร์ชันฐานข้อมูล ไดรเวอร์ connection pool ระดับ isolation วิธี commit และค่าที่กำหนดความทนทานของข้อมูล ใช้คอร์ หน่วยความจำ และชนิดพื้นที่เก็บข้อมูลระดับเดียวกัน โดยเปิดเผยค่าที่ต้องตั้งต่างกันตามสถาปัตยกรรม อย่าแลกความปลอดภัยของข้อมูลกับความเร็วโดยไม่ระบุไว้ในผล
4. วัดทั้งสามภาระงาน: แยกงานอ่านล้วน งานอ่านเขียนผสม และงานเพิ่มแถว แล้วเพิ่มระดับการทำงานพร้อมกันทีละช่วง เก็บ TPS, latency เฉลี่ย, latency ที่เปอร์เซ็นไทล์ 95, ข้อผิดพลาด และการลองธุรกรรมซ้ำในแต่ละช่วง การดูหลายระดับช่วยเห็นจุดที่เวลาเริ่มสูงเร็วขึ้น แม้ throughput ยังเพิ่มได้
5. ทดสอบเส้นทางและช่วงเวลาที่ใช้จริง: หากแอปพลิเคชันเชื่อมผ่านเครือข่าย ให้รวมเครือข่ายไว้ในการวัดเวลาที่ผู้ใช้เผชิญ รันให้เห็นทั้งช่วงอุ่นแคชและช่วงทำงานต่อเนื่อง พร้อมเก็บ CPU, I/O, การใช้หน่วยความจำ และเวลารอล็อก ค่าประสิทธิภาพของฐานข้อมูลควรแยกจากเวลาที่แอปพลิเคชันใช้ประมวลผลส่วนอื่น
6. ทำซ้ำและตรวจความถูกต้อง: รันทุกรูปแบบมากกว่าหนึ่งรอบภายใต้เงื่อนไขเดิม และตรวจว่าผลลัพธ์กับข้อมูลหลังทดสอบถูกต้องเหมือนกันทั้งสองระบบ หากธุรกรรมล้มเหลวหรือถูกลองใหม่ การนับเฉพาะรายการที่สำเร็จพร้อมระบุอัตราความล้มเหลวจะให้ภาพที่มีความหมายกว่า TPS ซึ่งละเลยปัญหานั้น

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

เลือกฐานข้อมูลจากข้อกำหนดของบริการ

หากธุรกรรมอ่านเขียนผสมเป็นภาระหลัก และการทดสอบด้วยข้อมูลจริงยังให้ PostgreSQL รองรับงานได้มากกว่าพร้อมรักษา latency ตามเป้าหมาย ผลนั้นเป็นเหตุผลด้านประสิทธิภาพสำหรับการเลือก PostgreSQL หากงานส่วนใหญ่เป็นการอ่าน ผล benchmark ตัวอย่างชี้ว่าช่องว่างอาจเล็กลงมาก จึงควรให้น้ำหนักกับคำสั่งที่ใช้จริง แผนดัชนี และต้นทุนดำเนินงานของระบบที่มีอยู่มากขึ้น

สำหรับบริการที่ใช้ MySQL อยู่แล้ว การปรับคำสั่ง ดัชนี หรือรูปแบบธุรกรรมอาจแก้จุดช้าได้โดยไม่ต้องย้ายข้อมูล การย้ายฐานข้อมูลมีต้นทุนของชนิดข้อมูล ไวยากรณ์ SQL ที่แอปพลิเคชันพึ่งพา ไดรเวอร์ การสำรองและกู้คืน และวิธีดูแลระบบประจำวัน ต้นทุนเหล่านี้ควรเทียบกับผลที่วัดได้จากธุรกรรมสำคัญ ไม่ใช่กับอัตราส่วนจากภาระงานภายนอกเพียงชุดเดียว

เกณฑ์ตัดสินสุดท้ายคือระบบใดรับสัดส่วนงานจริงได้โดยรักษา latency ของคำขอสำคัญและความถูกต้องของธุรกรรมภายใต้ทรัพยากรที่องค์กรจะใช้ ผล benchmark ภายนอกให้จุดตั้งต้นที่ชัดเจนสำหรับงานอ่านเขียนพร้อมกัน ส่วนผลทดสอบบนข้อมูลและเส้นทางของบริการเองเป็นตัวกำหนดว่าความต่างนั้นมีผลต่อการเลือกฐานข้อมูลมากเพียงใด