WooCommerce chậm khi nhiều đơn: nghẽn database và cách gỡ

Trả lời nhanh: WooCommerce chậm dần theo số đơn vì kiến trúc dữ liệu: đơn hàng kiểu cũ nằm rải trong wp_posts/wp_postmeta, vạn đơn là triệu dòng meta, mỗi trang admin là chuỗi truy vấn nặng dần. Bộ gỡ theo thứ tự hiệu quả: (1) bật HPOS, bảng đơn hàng riêng, cải thiện lớn nhất một cú click; (2) index + dọn dẹp, sessions, transient, action scheduler tồn đọng; (3) Redis object cache đỡ truy vấn lặp; (4) nền máy, checkout fsync và admin query cần NVMe + xung cao. Shop càng đông đơn, thứ tự này càng đúng nguyên văn.

Nghịch lý quen của chủ shop thành công: càng bán tốt web càng ì, đặc biệt là wp-admin, nơi mỗi lần mở danh sách đơn như một cực hình nhỏ. Đây không phải lời nguyền mà là kiến trúc, và kiến trúc thì gỡ được. Bài này đi từ gốc bệnh đến bộ thuốc theo thứ tự, kèm phép đo để biết mỗi liều ăn bao nhiêu.

Vì sao đơn càng nhiều web càng ì - gốc kiến trúc

WooCommerce truyền thống lưu mỗi đơn như một 'post' kèm hàng chục dòng wp_postmeta (khách, địa chỉ, tổng tiền, trạng thái... mỗi thứ một dòng key-value). Mười nghìn đơn = vài trăm nghìn đến hàng triệu dòng meta trộn chung bảng với meta của mọi thứ khác. Hệ quả: truy vấn kiểu 'đơn đang xử lý tháng này' phải join và lọc trên núi dữ liệu không được thiết kế cho việc đó, admin ì, báo cáo rùa, và cả frontend lây khi các widget đếm đơn/tồn kho chen vào. Đây là bài toán EAV kinh điển, và là lý do WooCommerce hiện đại xây lại từ gốc bằng HPOS.

Liều 1: HPOS - một cú chuyển kiến trúc

HPOS đưa đơn hàng về các bảng riêng thiết kế đúng mục đích (wc_orders...), cột rõ ràng, index sẵn, truy vấn thẳng. Shop vạn đơn bật xong thường thấy danh sách đơn và báo cáo nhanh lên nhiều lần. Đường bật: WooCommerce → Settings → Advanced → Features, với nghi thức: backup database trước (một lệnh dump, bài backup), bật chế độ tương thích (sync cả hai nơi) chạy vài ngày, kiểm plugin thanh toán/vận đơn quen dùng có tương thích HPOS (đa số plugin lớn đã hỗ trợ từ lâu), rồi mới chuyển hẳn. Đây là nâng cấp đáng làm nhất của mọi shop WooCommerce đông đơn còn chạy kiến trúc cũ.

Liều 2-3: Dọn rác định kỳ và Redis

Rác tích tụ, ba ổ quen: bảng wc_sessions phình theo khách vãng lai; transient hết hạn không ai dọn (đặc biệt khi dùng object cache ngoài thì transient DB thành rác kép); Action Scheduler (hàng đợi việc nền của Woo) tồn hàng chục nghìn bản ghi completed/failed. Dọn: WooCommerce → Status → Tools có sẵn nút cho sessions/transients; Action Scheduler đặt lịch dọn theo tài liệu chính chủ. Cho vào nghi thức tháng, như quét kho trước mùa sale. Redis object cache (liều 3): các truy vấn cấu hình/sản phẩm lặp lại được nhớ trong RAM, giảm hẳn áp lên MariaDB để nó dành sức cho phần đơn hàng thật; LiteSpeed Cache tích hợp sẵn mục này.

Liều 4: Nền máy - và bộ đo trước-sau

Phần không gỡ bằng phần mềm được: mỗi checkout là chuỗi ghi + fsync (đơn, giảm kho, log thanh toán), latency ổ đi thẳng vào cảm giác 'bấm đặt hàng'; mỗi trang admin là query lớn đơn luồng, sức một luồng CPU quyết định. NVMe có PLP + Xeon xung cao là tầng đỡ đúng bệnh (cả hai đã có bài riêng giải thích). Bộ đo trước-sau cho cả 4 liều:

# 1) thoi gian mo danh sach don (dang nhap admin, do bang devtools hoac):
curl -o /dev/null -s -w "admin-orders: %{time_starttransfer}sn" -H "Cookie: [cookie-admin]" https://shop.vn/wp-admin/admin.php?page=wc-orders
# 2) TTFB checkout (trang khong cache):
curl -o /dev/null -s -w "checkout: %{time_starttransfer}sn" https://shop.vn/checkout/
# 3) slow query log MariaDB bat truoc-sau moi lieu (bai MySQL cham)

Ghi số sau từng liều, biết liều nào ăn bao nhiêu là biết shop mình nghẽn thật ở đâu, và có bằng chứng khi cần nói chuyện với dev/nhà cung cấp.

Bộ đo trước và sau, để biết liều nào có tác dụng

# 1. Kich thuoc cac bang, hai bang don hang thuong lon nhat
mysql -e "SELECT table_name, ROUND(data_length/1024/1024,1) mb, table_rows
  FROM information_schema.tables WHERE table_schema='TEN_CSDL'
  ORDER BY data_length DESC LIMIT 10;"

# 2. Dem ban ghi rac trong bang bai viet
mysql -e "SELECT post_type, post_status, COUNT(*) c FROM wp_posts
  GROUP BY post_type, post_status ORDER BY c DESC LIMIT 15;"

# 3. Du lieu tu tai moi lan tai trang
mysql -e "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) mb_autoload
  FROM wp_options WHERE autoload='yes';"

# 4. Truy van cham
mysql -e "SET GLOBAL slow_query_log='ON'; SET GLOBAL long_query_time=1;"
# sau vai gio:
mysqldumpslow -s t -t 15 /var/log/mysql/slow.log

# 5. Do thoi gian trang quan tri don hang, con so nguoi ban cam nhan ro nhat
curl -o /dev/null -s -w "%{time_starttransfer}s\n" https://shop.vn/wp-admin/

Bốn liều theo thứ tự tác dụng

Thứ tự này quan trọng: nâng máy trước khi dọn cơ sở dữ liệu là mua tốc độ để bù cho lãng phí. Làm ba liều đầu rồi đo lại; nếu vẫn chậm thì mới nâng máy.

Việc phải làm trước khi chuyển cấu trúc lưu đơn hàng

1. Sao lưu toàn bộ cơ sở dữ liệu, và kiểm tệp sao lưu mở được.
2. Kiểm mọi plugin liên quan tới đơn hàng đã tương thích chưa: vận chuyển, thanh toán, kế toán, báo cáo. Đây là bước hay gây sự cố nhất.
3. Chạy thử trên bản sao trước, không chuyển thẳng trên bản đang bán.
4. Chọn khung giờ ít đơn, và tạm ngừng nhận đơn trong lúc chuyển.
5. Sau khi chuyển, kiểm trọn luồng: đặt một đơn thử, kiểm nó hiện trong trang quản trị, kiểm thư xác nhận, kiểm phần mềm kế toán nhận được đơn.

Về phần nền máy, xem cấu hình VPS cho WordPress và VPS NVMe.

Câu hỏi thường gặp

HPOS có rủi ro gì không, shop đang chạy có nên bật?

Rủi ro chính là plugin cũ chưa tương thích, vì vậy nghi thức: backup, bật chế độ tương thích chạy song song, kiểm nghiệp vụ (đặt đơn test, in vận đơn, đối soát), rồi mới chuyển hẳn. Làm đúng trình tự, đây là nâng cấp một chiều đáng giá.

Bao nhiêu đơn thì gọi là 'nhiều' đủ để ì?

Kiến trúc cũ thường bắt đầu 'có cảm giác' từ vài nghìn đơn cộng dồn, rõ rệt từ vài chục nghìn, tùy máy và plugin. Đừng chờ ì mới làm: HPOS + nghi thức dọn kho bật sớm là miễn nhiễm từ đầu.

Xóa đơn cũ để nhẹ database có nên không?

Thận trọng: đơn là sổ sách (thuế, đối soát, khách cũ). Hướng đúng là kiến trúc chịu được lịch sử (HPOS) + archive có chủ đích nếu thật cần, xuất trọn vẹn trước khi xóa, và tham khảo kế toán.

Frontend nhanh mà admin vẫn ì thì đáng đầu tư gì?

Đúng chân dung nghẽn query lớn đơn luồng: liều 1-2 trước (HPOS + dọn), rồi nhìn sức một luồng CPU của máy (sysbench, bài single-thread). Admin là nơi đội bạn sống hằng ngày, thời gian của họ cũng là tiền.

Bài viết liên quan

• Web bán hàng cần VPS không? Ngưỡng chuyển
• MySQL chậm: đọc EXPLAIN và tìm nghẽn
• VPS ổ Enterprise U.2 NVMe RAID 10 tại TND