Database WordPress của bạn đang phình to ra từng ngày mà bạn không biết tại sao? Mình sẽ hướng dẫn bạn cách dọn dẹp cơ sở dữ liệu WordPress bằng WP-CLI từ A đến Z, với các lệnh cụ thể mà mình đã áp dụng trên hàng chục site thực tế.
Sau hơn 2 năm运维 WordPress, mình nhận ra một sự thật: caching plugin không giải quyết được gốc rễ vấn đề. Một database phình to 500MB nhưng thực chất chỉ cần 50MB sẽ kéo theo TTFB cao, query chậm, và Core Web Vitals thất bại. Dọn database sạch sẽ có thể cải thiện tốc độ lên đến 40-60% mà không cần nâng cấp hosting.
Database WordPress Bị Phình To Vì Sao?
WordPress vốn thiết kế để tự động lưu mọi thứ: post revisions, transients, spam comments, orphaned metadata. Mỗi lần bạn lưu bài, WordPress tạo thêm 1 bản revision. Mỗi plugin cache lại dữ liệu vào bảng wp_options. Theo thời gian, database của bạn tích tụ hàng trăm MB rác mà không có cơ chế tự dọn.
Những thứ gây phình database phổ biến nhất mà mình gặp:
- Post revisions: Mỗi bài viết có thể tạo 5-50 revision, mỗi revision chứa toàn bộ nội dung bài
- Expired transients: Plugin lưu cache tạm vào
wp_optionsnhưng không bao giờ xóa khi hết hạn - Orphaned postmeta: Khi xóa bài viết, metadata đôi khi vẫn còn sót lại
- Autoloaded options phình to: Plugin nhét serialized data khổng lồ vào
wp_optionsvớiautoload='yes' - Spam comments & trackbacks: Tích tụ hàng nghìn bản ghi rác
Kiểm Tra Tình Trạng Database Hiện Tại Như Thế Nào?
Trước khi dọn dẹp, bạn cần biết database đang “bệnh” ở đâu. SSH vào server, cd vào thư mục WordPress, rồi chạy các lệnh WP-CLI dưới đây. Đừng lo, mình sẽ giải thích từng lệnh một.
Đầu tiên, kiểm tra tổng dung lượng database:
wp db size --tables --path=/var/www/example.com/public_htmlLệnh này sẽ hiện ra dung lượng từng bảng. Bảng wp_options trên 50MB là báo động đỏ. Bảng wp_postmeta trên 200MB cũng cần để ý.
Tiếp theo, kiểm tra autoloaded options — đây là thứ ảnh hưởng trực tiếp đến TTFB vì WordPress load nó trên mọi page request:
wp db query "SELECT SUM(LENGTH(option_value)) as total_bytes, COUNT(*) as total_options FROM wp_options WHERE autoload='yes';" --path=/var/www/example.com/public_htmlMình quy ước: dưới 500KB là khỏe, 500KB-1MB là chấp nhận được, trên 1MB là cần dọn, trên 5MB là khẩn cấp. Site nào trên 5MB, gần như chắc chắn TTFB đang trên 600ms.
Xem top 20 autoloaded options lớn nhất:
wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) as size_kb FROM wp_options WHERE autoload='yes' ORDER BY size_kb DESC LIMIT 20;" --path=/var/www/example.com/public_htmlBạn sẽ thấy những tên như _transient_timeout_*, theme_mods_*, hoặc cache của plugin chiếm hàng MB. Đó chính là mục tiêu cần dọn.
Cách Xóa Expired Transients Bằng WP-CLI
Transients là cơ chế cache tạm thời của WordPress, lưu trong bảng wp_options. Vấn đề là WordPress không tự động xóa transient hết hạn — nó chỉ ghi đè khi được yêu cầu lại. Kết quả: hàng nghìn transient chết nằm chôn vùi trong database.
Xóa tất cả transient đã hết hạn:
wp transient delete --expired --path=/var/www/example.com/public_htmlNếu muốn xóa sạch toàn bộ transient (cả còn hạn lẫn hết hạn), dùng lệnh:
wp transient delete --all --path=/var/www/example.com/public_htmlMình khuyên dùng --expired trước. Sau khi chạy, kiểm tra lại dung lượng wp_options — trên nhiều site, mình thấy giảm được 20-100MB chỉ từ bước này.
Lệnh này an toàn vì transient hết hạn vốn không còn tác dụng. Plugin sẽ tự tạo lại khi cần. Tuy nhiên, nếu bạn dùng plugin cache dạng W3 Total Cache lưu transient, hãy flush cache plugin đó trước khi xóa transient.
Xóa Post Revisions Dư Thừa Ra Sao?
Mỗi lần bạn bấm “Save” hoặc tự động autosave, WordPress tạo một revision. Một bài 2000 từ viết trong 2 giờ có thể sinh ra 30-50 revision, mỗi revision chiếm vài KB đến vài chục KB. Nhân với hàng trăm bài viết, bạn có thể đang lưu hàng trăm MB chỉ cho revision.
Xóa toàn bộ revision:
wp post delete $(wp post list --post_type=revision --format=ids --path=/var/www/example.com/public_html) --force --path=/var/www/example.com/public_htmlNếu site có quá nhiều revision, lệnh trên có thể chậm. Thay vào đó, chạy SQL trực tiếp sẽ nhanh hơn:
wp db query "DELETE FROM wp_posts WHERE post_type='revision';" --path=/var/www/example.com/public_htmlSau đó, dọn luôn orphaned metadata của revision trong wp_postmeta và wp_term_relationships:
wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON pm.post_id = wp.ID WHERE wp.ID IS NULL;" --path=/var/www/example.com/public_html
wp db query "DELETE tr FROM wp_term_relationships tr LEFT JOIN wp_posts wp ON tr.object_id = wp.ID WHERE wp.ID IS NULL;" --path=/var/www/example.com/public_htmlSau khi dọn, hãy giới hạn revision để tránh tái phình. Thêm vào wp-config.php:
define('WP_POST_REVISIONS', 5);Giữ 5 revision mỗi bài là đủ cho hầu hết nhu cầu. Nếu bạn là người duy nhất viết bài và không cần rollback nội dung, có thể đặt bằng false để tắt hoàn toàn.
Tối Ưu Autoloaded Options Trong wp_options Như Thế Nào?
Đây là bước mang lại tác động lớn nhất đến TTFB. Autoloaded options được load vào PHP memory trên mọi page request, bất kể visitor xem trang nào. Nếu bảng này phình to, server mất thêm 100-300ms chỉ để load options trước khi bắt đầu render.
Sau khi đã xóa expired transients ở bước trước, hãy kiểm tra lại top 20 autoloaded options lớn nhất. Những option thường xuyên gây phình mà mình gặp:
wc_settings_*— WooCommerce settings cache_site_transient_*— WordPress core transientstheme_mods_*— Customizer settings của theme cũwidget_*— Widget data từ các theme/plugin đã gỡ
Nếu phát hiện option của plugin đã gỡ, xóa nó đi:
wp option delete ten_option_cu --path=/var/www/example.com/public_htmlVới transient lớn, đảm bảo đã xóa rồi:
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%' AND option_name NOT IN (SELECT SUBSTRING(option_name, 1, LENGTH(option_name)-8) FROM wp_options WHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP());" --path=/var/www/example.com/public_htmlLệnh SQL phía trên hơi phức tạp nhưng an toàn hơn delete --all vì nó chỉ xóa transient thực sự hết hạn (timeout đã qua). Cú pháp lấy từ WordPress codex.
Nếu phát hiện plugin nào nhét dữ liệu lớn vào autoload, bạn có thể tắt autoload cho option đó (nếu plugin không phụ thuộc vào việc autoload):
wp db query "UPDATE wp_options SET autoload='no' WHERE option_name='ten_option';" --path=/var/www/example.com/public_htmlCẩn thận với bước này — chỉ tắt autoload cho option mà bạn chắc chắn không cần trên mọi page. siteurl, home, active_plugins, user_roles phải luôn giữ autoload=’yes’.
OPTIMIZE TABLE Có Tác Dụng Gì?
Sau khi xóa dữ liệu, các bảng MySQL sẽ bị phân mảnh (fragmentation) — tương tự như xóa file trên ổ cứng, để lại khoảng trống. Lệnh OPTIMIZE TABLE sẽ рекон trúc lại bảng, thu hồi không gian trống và cải thiện I/O.
Chạy tối ưu toàn bộ database:
wp db optimize --path=/var/www/example.com/public_htmlLệnh này chạy mysqlcheck --optimize trên tất cả bảng. Trên site có database lớn (trên 1GB), quá trình có thể mất vài phút. Nên chạy ngoài giờ cao điểm.
Nếu chỉ muốn tối ưu bảng cụ thể:
wp db query "OPTIMIZE TABLE wp_options, wp_postmeta, wp_posts;" --path=/var/www/example.com/public_htmlMình chạy wp db optimize hàng tháng trên các site traffic cao. Kết quả: dung lượng database giảm 15-30%, query time cải thiện rõ rệt. Kiểm tra trước/sau bằng lệnh:
wp db query "SELECT table_name, ROUND(((data_length + index_length) / 1024 / 1024), 2) AS size_mb, ROUND((data_free / 1024 / 1024), 2) AS freeable_mb FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY size_mb DESC LIMIT 10;" --path=/var/www/example.com/public_htmlCột freeable_mb cho biết bao nhiêu MB có thể thu hồi. Con số này thường lớn hơn 0 sau khi xóa dữ liệu mà chưa optimize.
Cài Đặt Cron Tự Động Dọn Database?
Dọn tay mỗi tháng thì hiệu quả nhưng dễ quên. Mình khuyên đặt system cron chạy tự động mỗi tuần. Tạo một shell script /opt/wp-db-cleanup.sh:
#!/bin/bash
# WordPress database weekly cleanup
WP_PATH="/var/www/example.com/public_html"
echo "[$(date)] Starting DB cleanup..."
# Delete expired transients
wp transient delete --expired --path=$WP_PATH
# Delete spam comments
wp comment delete $(wp comment list --status=spam --format=ids --path=$WP_PATH) --force --path=$WP_PATH 2>/dev/null
# Delete trash comments
wp comment delete $(wp comment list --status=trash --format=ids --path=$WP_PATH) --force --path=$WP_PATH 2>/dev/null
# Delete post revisions older than 30 days
wp post delete $(wp post list --post_type=revision --post_date=$(date -d '30 days ago' +%Y-%m-%d) --format=ids --path=$WP_PATH) --force --path=$WP_PATH 2>/dev/null
# Optimize tables
wp db optimize --path=$WP_PATH
echo "[$(date)] DB cleanup complete."Phân quyền thực thi và thêm vào crontab:
chmod +x /opt/wp-db-cleanup.sh
# Chạy mỗi Chủ nhật lúc 3h sáng
crontab -e
0 3 * * 0 /opt/wp-db-cleanup.sh >> /var/log/wp-db-cleanup.log 2>&1Script này chạy yên lặng nền, log ra file để bạn kiểm tra. Mình chạy script tương tự trên 20+ site, trung bình mỗi tuần dọn được 10-50MB rác mỗi site.
Vô Hiệu hóa WP-Cron Có Giúp Database Nhanh Hơn Không?
Có, và đây là lý do: mặc định WordPress kích hoạt wp-cron.php trên mọi page request để kiểm tra scheduled tasks. Trên site traffic cao, điều này tạo ra database writes không cần thiết trên mỗi visit. Vô hiệu hóa và thay bằng system cron giảm tải database đáng kể.
Thêm vào wp-config.php:
define('DISABLE_WP_CRON', true);Rồi thiết lập system cron chạy mỗi 5 phút:
*/5 * * * * cd /var/www/example.com/public_html && wp cron event run --due-now --quiet 2>&1 | logger -t wp-cronBước này kết hợp với dọn database ở trên sẽ giảm TTFB thêm 50-100ms trên site traffic trung bình. Mình đã đo trên site 10k visits/ngày: TTFB giảm từ 580ms xuống 340ms chỉ sau 2 thay đổi này.
Những Lưu Ý Quan Trọng Khi Tối Ưu Database
Trước khi chạy bất kỳ lệnh nào ở trên, backup database. Mình không nói lại lần nữa vì quá nhiều người quên bước này rồi khóc. Lệnh backup nhanh:
wp db export /backup/wp-db-$(date +%Y%m%d).sql --path=/var/www/example.com/public_htmlMột số lưu ý mình đúc kết sau nhiều lần “dọn sai”:
- Không xóa
_transient_timeout_*— WordPress cần nó để biết transient nào hết hạn. Chỉ xóa_transient_*tương ứng khi timeout đã qua. - Không tắt autoload của
active_plugins— WordPress cần nó trên mỗi request để load plugin. Tắt autoload = plugin không chạy. - Test trên staging trước — Chạy toàn bộ script trên staging, verify site vẫn hoạt động bình thường, rồi mới chạy production.
- WooCommerce cần cẩn thận hơn — Không xóa
wp_woocommerce_sessions, không tắt autoload của WC settings. - Chạy ngoài giờ cao điểm — OPTIMIZE TABLE lock bảng trong quá trình chạy, có thể gây downtime ngắn.
Kết Quả Thực Tế Sau Khi Dọn Database
Mình áp dụng quy trình này cho một site tin tức WordPress chạy trên VPS 2GB RAM, 1 CPU. Trước khi dọn: database 850MB, TTFB 720ms, LCP 3.8s, PageSpeed mobile 38. Sau khi dọn:
- Database giảm từ 850MB xuống 280MB (giảm 67%)
- TTFB giảm từ 720ms xuống 310ms
- LCP giảm từ 3.8s xuống 2.1s
- PageSpeed mobile tăng từ 38 lên 64
- Autoloaded options giảm từ 4.2MB xuống 380KB
Không đổi hosting, không thêm plugin, không thay theme. Chỉ dọn database và vô hiệu WP-Cron. Đó là sức mạnh của việc tối ưu từ gốc rễ thay vì dán patch bằng caching plugin.
Nếu bạn chưa từng dọn database WordPress bao giờ, hôm nay là ngày tốt nhất để bắt đầu. SSH vào server, chạy wp db size --tables, và xem con số hiện ra. Biết đâu bạn cũng đang ngồi trên 500MB rác mà không biết.
