"Error Establishing a Database Connection" ใน WordPress: วิธีแก้ไข

คุณเปิดเว็บของคุณ แล้วทุกหน้า — ทั้ง front end และ wp-admin — ถูกแทนที่ด้วยประโยคสีเทาบรรทัดเดียว: Error establishing a database connection. ไม่มีอะไรแสดงผล เพราะมันแสดงไม่ได้ WordPress ยังไปไม่ถึงขั้นสร้างหน้าเว็บด้วยซ้ำ

นี่คือภาพในหัวที่ทำให้แก้ปัญหานี้ได้เร็ว WordPress เก็บเนื้อหาทั้งหมดของคุณ — posts, pages, settings, users — ไว้ในฐานข้อมูล MySQL ไม่ใช่ในไฟล์ ทุกครั้งที่มี request มันจะอ่านข้อมูลเข้าสู่ระบบสี่อย่างจาก wp-config.php เชื่อมต่อไปยังฐานข้อมูลนั้น แล้วดึงสิ่งที่ต้องการออกมา error นี้หมายความว่าการเชื่อมต่อนั้นถูกพยายามแล้วและ ถูกปฏิเสธ ทางแก้คือการหาให้ได้ว่า ทำไม จึงถูกปฏิเสธ ซึ่งมีความเป็นไปได้เพียงสามอย่างเท่านั้น

สามสาเหตุ เรียงตามโอกาสที่จะเกิด

1. ข้อมูลรับรองผิด ใน wp-config.php — มักเป็นผลจากการย้ายโฮสต์
2. เซิร์ฟเวอร์ฐานข้อมูลล่มหรือทำงานหนักเกินไป — มักเกิดขึ้นเมื่อ ฝั่งคุณไม่ได้เปลี่ยนอะไรเลย
3. ฐานข้อมูลเสียหาย — พบไม่บ่อยนัก และมันแสดงอาการออกมาต่างออกไป

ไล่ตรวจไปตามลำดับนี้

ขั้นที่ 1: ตรวจสอบข้อมูลรับรองทั้งสี่

เปิดไฟล์ wp-config.php ในโฟลเดอร์ root ของเว็บผ่าน SFTP หรือ file manager ของโฮสต์ มีสี่บรรทัดที่กำหนดการเชื่อมต่อนี้:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

แต่ละค่าต้องตรงเป๊ะกับที่โฮสต์กำหนดให้ เปิดส่วนฐานข้อมูลใน control panel ของโฮสต์ (ใน cPanel คือ “MySQL Databases”) แล้วเทียบทีละตัวอักษร:

• DB_NAME — โฮสต์มักเติม prefix ที่เป็นชื่อบัญชีของคุณไว้หน้าชื่อ เช่น cpaneluser_wpdb prefix นั้นเป็นส่วนหนึ่งของชื่อ
• DB_USER — มี prefix แบบเดียวกัน และ user ต้องถูก กำหนดให้ เข้าถึงฐานข้อมูลนั้น ไม่ใช่แค่มีอยู่เฉย ๆ
• DB_PASSWORD — ตัวการที่พบบ่อยที่สุด ถ้าไม่แน่ใจ ให้รีเซ็ตใน control panel แล้ววางค่าใหม่ลงไป ระวังช่องว่างที่ติดมาท้ายค่า หรือ smart quote
• DB_HOST — อย่าเดาว่าเป็น localhost โฮสต์จำนวนมากใช้เซิร์ฟเวอร์ฐานข้อมูลแยกต่างหาก ซึ่งมีที่อยู่แบบ mysql.yourhost.com บางครั้งก็มี :port ต่อท้าย ค่าที่ถูกต้องแสดงอยู่ใน control panel

เพราะค่าทั้งสี่นี้อยู่ในไฟล์นี้พอดี วิธีที่ปลอดภัยที่สุดในการสร้าง wp-config.php ที่สะอาดและใส่เครื่องหมายคำพูดถูกต้องขึ้นมาใหม่ คือ wp-config.php generator — กรอกฟิลด์ฐานข้อมูลทั้งสี่ แล้ววางผลลัพธ์ทับบล็อกเดิม

ขั้นตอนนี้เพียงอย่างเดียวก็แก้ error ได้แทบทุกครั้งหลังการย้ายโฮสต์ เพราะข้อมูลรับรองที่ถูกต้องบนโฮสต์เก่ากลับผิดบนโฮสต์ใหม่

ขั้นที่ 2: ยืนยันว่าเซิร์ฟเวอร์ฐานข้อมูลทำงานอยู่จริง

ถ้าข้อมูลรับรองถูกต้องแต่ error ยังอยู่ — โดยเฉพาะถ้ามัน เกิดขึ้นเอง โดยที่คุณไม่ได้เปลี่ยนอะไร — ผู้ต้องสงสัยก็คือตัวเซิร์ฟเวอร์ฐานข้อมูลเอง

บน shared hosting เรื่องนี้พบได้บ่อยและมักเป็นแค่ชั่วคราว: บริการ MySQL รับภาระไม่ไหวตอนที่ทราฟฟิกพุ่งสูง หรือชนเพดานจำนวนการเชื่อมต่อต่อบัญชี แล้วเริ่มปฏิเสธการเชื่อมต่อใหม่ โดยทั่วไปมันจะกลับมาปกติภายในไม่กี่นาที รอสักครู่แล้วโหลดหน้าใหม่ก่อนจะลงมือทำอะไรที่รุนแรง

หากต้องการทดสอบว่าข้อมูลรับรองใช้ได้จริงหรือไม่ โดยแยกจาก WordPress ให้วางสคริปต์เล็ก ๆ ไว้ข้าง ๆ wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

ใส่ค่า DB_HOST, DB_USER และ DB_PASSWORD จริงของคุณ ถ้ามันพิมพ์ว่า Connected แสดงว่าข้อมูลเข้าสู่ระบบของคุณใช้ได้ และปัญหาอยู่ที่อื่น (ฐานข้อมูลเสียหาย ในขั้นที่ 3) ถ้ามันพิมพ์ connection error ออกมา ข้อความจะบอกว่าเป็นแบบไหน: “Access denied” หมายถึง user หรือ password ผิด; “Can’t connect to MySQL server” หมายถึง host ผิด หรือบริการล่มจริง ๆ — ถึงเวลาติดต่อโฮสต์ ลบสคริปต์ทิ้งทันทีที่ทำเสร็จ

ขั้นที่ 3: ซ่อมฐานข้อมูลที่เสียหาย

มีสัญญาณหนึ่งที่แยกความเสียหายออกจากปัญหาการเชื่อมต่อ: front end โหลดได้แต่ wp-admin แสดง error หรือกลับกัน ถ้าการเชื่อมต่อถูกปฏิเสธจริง ทั้งสองฝั่งก็ต้องตายทั้งคู่ อาการที่แยกกันแบบนี้ชี้ไปที่ตารางที่เสียหาย

WordPress มีเครื่องมือซ่อมในตัว เพิ่มหนึ่งบรรทัดลงใน wp-config.php เหนือคอมเมนต์ “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

จากนั้นเปิด URL นี้ตรง ๆ ในเบราว์เซอร์:

https://yoursite.com/wp-admin/maint/repair.php

หน้านี้โหลดได้ โดยไม่ต้องล็อกอิน — ซึ่งเป็นเจตนา เพราะคุณอาจถูกล็อกไม่ให้เข้า — และมีปุ่ม “Repair Database” กับ “Repair and Optimize Database” ให้เลือก กดรันได้เลย

จากนั้นลบบรรทัดนั้นออกจาก wp-config.php ทันที ตราบใดที่มันยังอยู่ ใครก็ตามบนอินเทอร์เน็ตสามารถเข้า URL นั้นแล้วสั่งซ่อมฐานข้อมูลของคุณได้ นี่ไม่ใช่การเก็บกวาดที่จะทำหรือไม่ก็ได้ แต่เป็นการปิดช่องโหว่ที่คุณเพิ่งเปิดขึ้นมา

ขั้นที่ 4: เมื่อ repair ยังเชื่อมต่อไม่ได้ด้วยซ้ำ

ถ้าหน้า repair เองก็แสดง connection error ก็ไม่มีอะไรให้ซ่อม — เพราะเข้าถึงฐานข้อมูลไม่ได้เลย เท่ากับคุณย้อนกลับไปที่ขั้นที่ 1 หรือขั้นที่ 2 ถึงจุดนั้น ทางที่ไว้ใจได้คือ กู้คืนฐานข้อมูลจากข้อมูลสำรองล่าสุดของโฮสต์ control panel ส่วนใหญ่เก็บ snapshot ฐานข้อมูลรายวันอัตโนมัติ การกู้คืนจากเมื่อคืนแทบทุกครั้งเร็วและปลอดภัยกว่าการไล่ตามความเสียหายที่คุณเชื่อมต่อเข้าไปไม่ได้

คำแนะนำที่ปล่อยผ่านได้อย่างสบายใจ

“ลง WordPress ใหม่ไปเลยสิ” error นี้เป็นเรื่องของการเชื่อมต่อฐานข้อมูล ไม่ใช่ไฟล์ core การลงใหม่ไปแทนที่ไฟล์ที่ทำงานดีอยู่แล้ว และไม่ได้แตะอะไรที่พังเลย

“เพิ่ม PHP memory limit สิ” หน่วยความจำหมดเป็น error คนละตัว ที่มีข้อความต่างออกไป การเพิ่มลิมิตไม่ช่วยอะไรกับการเชื่อมต่อฐานข้อมูลที่ถูกปฏิเสธ มีแต่จะกลบว่าคุณไม่เคยตรวจข้อมูลรับรองเลย

“ล้างแคชสิ” ความล้มเหลวเกิดขึ้นใน PHP ก่อนที่แคชใด ๆ จะเสิร์ฟหน้าเว็บได้เสียอีก ตราบใดที่การเชื่อมต่อยังถูกปฏิเสธ การล้างแคชไม่เปลี่ยนอะไรทั้งนั้น มันคุ้มที่จะทำก็ต่อเมื่อเว็บกลับมาแล้ว เท่านั้น

“แก้ที่ฐานข้อมูลตรง ๆ เลยสิ” การรีบเปิด phpMyAdmin เพื่อแก้ตารางด้วยมือ ก่อนที่จะยืนยันด้วยซ้ำว่าการเชื่อมต่อยังทำงานอยู่ คือหนทางที่ทำให้เหตุขัดข้องชั่วคราวกลายเป็นการสูญเสียข้อมูลถาวร ยืนยันการเชื่อมต่อก่อน แล้วค่อยแตะข้อมูลเป็นอย่างสุดท้าย และทำจากข้อมูลสำรองเท่านั้น

ยังติดอยู่อีกไหม?

ถ้าข้อมูลรับรองผ่านการทดสอบด้วยสคริปต์ เซิร์ฟเวอร์ทำงานอยู่ และ repair เชื่อมต่อได้โดยไม่รายงาน error ใด ๆ แต่เว็บก็ยังแสดงข้อความนั้นอยู่ ผู้ต้องสงสัยที่เหลือคือ plugin ที่คุยกับฐานข้อมูลผ่านการเชื่อมต่อของมันเอง — plugin แคชหรือ plugin ฐานข้อมูลที่เก็บ host เก่าค้างไว้ เปลี่ยนชื่อ wp-content/plugins เป็น plugins-off ผ่าน SFTP เพื่อตัดข้อสงสัยนี้ออก ถ้า error หายไป ให้เปิด plugins กลับมาทีละตัวจนกว่ามันจะกลับมาอีกครั้ง