CÁCH TỐI ƯU CƠ SỞ DỮ LIỆU (DATABASE) TRONG WORDPRESS

Cơ sở dữ liệu (CSDL) trong website WordPress nắm giữ các thông tin kiểu như nội dung bài post, người dùng, đơn đặt hàng, và các cài đặt (setting) của giao diện cũng như plugin. Trong khi các mã PHP cho trang web biết cách thực hiện các hàm và CSS cho các đoạn mã hình dáng, thì CSDL nắm giữ tất cả thông tin cho nội dung của trang. Điều quan trọng là CSDL cần nhẹ nhàng (lightweight), khi ấy nó sẽ đủ nhanh để tương tác với mọi trang mà không ảnh hưởng tiêu cực đến hiệu suất (performance).

Ngôn ngữ SQL được dùng để viết lệnh yêu cầu, nó còn được gọi là “truy vấn/query” thông tin từ CSDL. Điều quan trọng là cũng phải đảm bảo truy vấn SQL nhẹ nhàng để trang có thể tải hiệu quả hơn.

Để tối ưu hóa CSDL của bạn, bạn sẽ cần phải chạy các truy vấn từ phpMyAdmin.

Bằng cách tối ưu hóa cả dữ liệu trong CSDL và truy vấn SQL giao tiếp với nó, bạn sẽ cải thiện thời gian tải trang web, TTFB, và trải nghiệm tổng thể của người dùng cuối (end-user experience).

Tối ưu hóa các bảng

Sử dụng các câu lệnh Tối ưu hóa bảng (optimize table) là thực hành tốt để duy trì chất lượng và hiệu suất của CSDL. Tối ưu hóa bảng sẽ tạo lại bảng đã chọn và loại bỏ bất kỳ không gian đĩa thừa nào được sử dụng bởi bảng đó. Giải phóng không gian đĩa thừa giúp cải thiện hiệu suất bằng cách giảm số lượng dữ liệu phải lưu giữ trong bộ nhớ khi truy cập bảng.

Để tối ưu hóa các bảng CSDL:

1. Đăng nhập vào phpMyAdmin
2. Chọn CSDL (wp_environmentname)
3. Tick vào hộp nhỏ bên cạnh các bảng bạn muốn tối ưu hóa
4. Ở cuối, trong phần xổ xuống, bạn chọn Tối ưu hóa bảng (Optimize table)

Các kiểu bảng Storage engine và bộ nhớ

Có hai cơ chế storage engines chính để tạo bảng: MyISAM và InnoDB. Kiểu storage engine trang của bạn sử dụng sẽ ảnh hưởng lớn đến hiệu suất do có sự khác biệt trong cách chúng ghi dữ liệu và sử dụng các nguồn tài nguyên máy chủ (server resources). Chúng tôi luôn khuyến khích sử dụng kiểu storage ingine InnoDB để tạo bảng.

Hiệu suất của MyISAM chỉ ổn ở khía cạnh đọc CSDL, nhưng khi nói đến việc viết và cập nhật CSDL, toàn bộ bảng sẽ bị khóa (locked) cho đến khi quá trình xử lý hoàn tất. Điều này sẽ ngăn bất kỳ hoạt động đọc/ghi nào được phép bắt đầu trong bảng cho đến khi một quá trình xử lý cụ thể được hoàn tất. InnoDB chỉ khóa một hàng cần để ghi, phần còn lại của bảng được tự do cho các hoạt động đồng thời khác.

Sự khác biệt quan trọng khác là cách các storage engines tương tác với bộ nhớ trong máy chủ (server). Có một pool bộ nhớ cụ thể được gọi là InnoDB Buffer Pool được sử dụng bởi các bảng InnoDB. Các bảng dùng MyISAM không thể sử dụng pool bộ nhớ này, điều đó có nghĩa là họ ghi vào đĩa (disk) thay vì sử dụng bộ nhớ CSDL.

Để kiểm tra storage engine bạn đang dùng:

1. Đăng nhập
2. Click vào phpMyAdmin
3. Chọn CSDL (wp_environmentname)
4. Nhìn vào cột “Type“

Bạn có thể sắp xếp cột này bằng cách click vào tên

Một khi bạn phát hiện một bảng nào đấy đang sử dụng MyISAM, hãy chuyển nó sang kiểu bảng InnoDB. Thay thế table_name bằng tên bảng tương ứng.

ALTER TABLE table_name ENGINE=InnoDB;

Nếu bạn không biết cách làm thế nào để chạy truy vấn, hãy tham khảo các hướng dẫn trên mạng.

Lưu ý: Bạn cần backup CSDL trước khi thực hiện thay đổi. (Plugin giúp bạn làm điều này dễ dàng là UpdraftPlus. Không chỉ database, nó còn có khả năng backup tất cả các thành phần khác của website – đây là một trong các plugin tốt nhất về mảng backup và restore, vui hơn nữa là các tính năng cơ bản của nó thì miễn phí)

Dọn dẹp CSDL

Điều quan trọng và có ích cho hiệu suất CSDL của bạn là loại bỏ các dữ liệu dư thừa cũng như giảm nguy cơ phình to CSDL qua thời gian (theo thời gian, bạn có nhiều nội dung hơn, thử nghiệm vô số plugin, giao diện, và vì vậy CSDL có khuynh hướng ngày càng lớn hơn).

MySQL là hệ thống CSDL kiểu quan hệ (relational), có nghĩa là dữ liệu trong một bảng thường sẽ có mối liên hệ dữ liệu ở trong bảng khác. Khi một giá trị dữ liệu, chẳng hạn như một bài đăng, bị loại bỏ khỏi một bảng, nó có thể bỏ lại dữ liệu không còn ý nghĩa trong một bảng khác (mà nó từng có liên hệ trước đây).

Câu lệnh dùng để kiểm tra xem bảng của bạn có bất kỳ dữ liệu postmeta nào vô ích hay không:

SELECT COUNT(pm.meta_id) as row_count FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;

Loại bỏ bất cứ postmeta nào vô ích:

DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;

Kiểm tra xem trang của bạn có bất cứ commentmata nào vô ích hay không:

SELECT COUNT(*) as row_count FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);

Loại bỏ bất cứ commentmeta nào vô ích:

DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);

Ngoài ra trang của bạn có thể có revision từ các bài đăng. Xóa bỏ bất cứ revisions nào bằng câu lệnh:

DELETE FROM wp_posts WHERE post_type = "revision";

Kiểm tra wp_session data:

SELECT * FROM `wp_options` WHERE `option_name` LIKE '_wp_session_%'

Loại bỏ wp_session data:

DELETE FROM `wp_options` WHERE `option_name` LIKE '_wp_session_%'

Loại bỏ transients quá hạn:

DELETE FROM `wp_options` WHERE `option_name` LIKE ('%_transient_%')

Loại bỏ các tag không có mối liên hệ với bất cứ bài post nào:

DELETE FROM wp_terms WHERE term_id IN (SELECT term_id FROM wp_term_taxonomy WHERE count = 0 );
DELETE FROM wp_term_taxonomy WHERE term_id not IN (SELECT term_id FROM wp_terms);
DELETE FROM wp_term_relationships WHERE term_taxonomy_id not IN (SELECT term_taxonomy_id FROM wp_term_taxonomy);

Loại bỏ các pingbacks và trackbacks:

DELETE FROM wp_comments WHERE comment_type = 'pingback';
DELETE FROM wp_comments WHERE comment_type = 'trackback';

Các plugin giúp dọn dẹp cơ sở dữ liệu

Hoàn toàn dễ hiểu thôi, việc thực hiện một số lượng lớn truy vấn có thể đáng sợ, nhất là khi trước đó bạn chưa từng thao tác với CSDL. Có một số plugin có thể hỗ trợ bạn, tuy nhiên các plugin có thể xóa dữ liệu kém cẩn trọng hơn so với khi chạy từng truy vấn SQL. Hãy thực hiện backup trước khi tiếp tục. Chúng tôi cũng khuyến cáo bạn kiểm tra bất cứ thay đổi nào trong môi trường staging (*) trước khi làm điều này ở phiên bản website chính thức.

(*): staging là môi trường demo cho website của bạn, nó giúp bạn kiểm tra kỹ lưỡng các thay đổi thử nghiệm, và khi mọi thứ ổn thỏa, bạn có thể đẩy nó lên website chính thức mà hiếm khi phải gặp rủi ro.

Một số plugin hỗ trợ bạn là:

• WP Rocket
• WP Optimize
• WP Sweep
• Advanced Database Cleaner

Các dữ liệu được tải tự động (autoloaded)

Một số thông tin trong CSDL phải được tải trong mỗi yêu cầu, chẳng hạn như URL của trang, giao diện và plugin nào đang được kích hoạt. Trong WordPress, điều này được gọi là dữ liệu tải tự động và nó được lưu trữ trong bảng wp_options (các tùy chọn của WP).

Trong khi dữ liệu tải tự động hữu ích trong một số trường hợp, nó cũng thường chứa nhiều thông tin không cần thiết. Một lời khuyên là bạn nên giữ tổng lượng dữ liệu tải tự động dưới 800 ngàn byte (khoảng 0,8Mb) để tối ưu hiệu suất.

Với từng hàng trong bảng tùy chọn, có một giá trị tương ứng trong cột “autoload” có thể là yes/có hoặc no/không. Vô hiệu hóa tự động tải cho một hàng đơn giản có nghĩa là thiết lập giá trị trong cột này là no.

Vô hiệu hóa tự động tải trong dữ hiệu hàng không làm loại bỏ nó khỏi CSDL của bạn, nó chỉ đơn giản có nghĩa là thông tin ở hàng đó không còn được gọi mỗi khi trang được tải tự động. Khi tự autoload được đặt là no, dữ liệu ở hàng đó chỉ được kéo vào trang khi có yêu cầu.

Cuối cùng, chuyện này là tùy thuộc vào bạn hoặc nhà lập trình quyết định là thông tin nào trong website cần được tự động tải và cái nào có thể được vô hiệu hóa mà không làm hỏng chức năng của trang. Bên dưới chúng tôi chia sẻ một số truy vấn hữu ích để điều khiển dữ liệu tải tự động.

Tính toán tổng lượng dữ liệu tải tự động theo bytes:

SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';

Tìm và sắp xếp 20 hàng có giá trị tải tự động lớn nhất:

SELECT LENGTH(option_value),option_name FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 20;

Vô hiệu hóa tải tự động cho một tùy chọn cụ thể. Thay option_name bằng tên tùy chọn thực sự mà bạn tìm ra khi sử dụng ở câu lệnh trước:

UPDATE wp_options SET autoload='no' WHERE option_name='option_name';

EX: UPDATE wp_options SET autoload='no' WHERE option_name='really_large_row';

Sau khi bạn giảm tổng lượng dữ liệu tải tự động xuống dưới 800K byte, cần đảm bảo bảng tùy chọn được lập chỉ mục (indexed). Điều này giúp trang web của bạn phục vụ dữ liệu tải tự động mới đã được dọn dẹp nhanh hơn.

CREATE INDEX autoloadindex ON wp_options(autoload, option_name);

Object cache

Object cache lưu trữ các kết quả để truy vấn được thực hiện nhanh hơn ở các lần truy cập sau. Nó có thể có bộ đệm lên tới 1MB và ảnh hưởng đến tất cả các trang trên website của bạn, thậm chí là cả những trang thông thường không phải lưu bộ nhớ đệm cache chẳng hạn như wp-admin.

Các truy vấn cache được gói vào trong các hàm wp_cache() được xác định bởi WordPress để lưu trữ, cũng như trong các transients.

Object cache được vô hiệu hóa theo mặc định, bật tính năng này lên thường được khuyến nghị để cải thiện hiệu suất.

Để bật Object Cache:

1. Đăng nhập
2. Click vào Utilities
3. Chọn tùy chọn để bật Object Cache
4. Save

Lưu ý: Nếu bạn có dữ liệu tải tự động vượt quá 800 ngàn byte, object cache cần phải vô hiệu hóa. Object cache có bộ đệm 1MB và dữ liệu tải tự động lớn sẽ nhanh chóng vượt quá giới hạn này làm xuất hiện lỗi 502 ngay lập tức hoặc ngẫu nhiên.

Các giải pháp cho tìm kiếm

Nếu trang của bạn có vài ngàn bài đăng, bạn có khả năng sẽ nhận ra chức năng tìm kiếm có tốc độ chậm. Điều này là vì số lượng các mục tìm kiếm và bản thân truy vấn tìm kiếm không mở rộng ra số lượng lớn nội dung.

Sau khi trang của bạn chạm đến giới hạn vài ngàn bài viết, tốt nhất hãy sử dụng giải pháp tìm kiếm dạng ứng dụng của bên thứ ba (off-site). Chúng tôi khuyến nghị:

• ElasticPress
• Algolia

Điều này giúp giảm tải cho việc phải sử dụng quá nhiều tài nguyên máy chủ của bạn để tìm kiếm, cũng như chuyển việc tìm kiếm đến hệ thống riêng đã được tối ưu hóa để xử lý nó và cho kết quả tốt hơn, nhanh hơn. Nhờ việc giảm tải, máy chủ của bạn có nhiều tài nguyên hơn để xử lý nhiều lưu lượng truy cập đồng thời hơn và làm cho website có thể mở rộng dễ dàng.

Cuối cùng nếu bạn đã thử các biện pháp tối ưu hóa ở trên (và các giải pháp khác) nhưng website vẫn gặp vấn đề về hiệu suất và tốc độ, thế thì có thể đã đến thời điểm bạn nên nâng cấp lên gói host lưu trữ có nhiều tài nguyên hơn. Tham khảo bài viết nên mua hosting ở đâu để biết thêm chi tiết.

(Được dịch từ bài viết How to optimize a database on WordPress, website: WP Engine)