Hướng dẫn tối ưu hóa Database gọn nhẹ giúp tăng tốc cho WordPress

Hướng dẫn tối ưu hóa Database gọn nhẹ giúp tăng tốc cho WordPress

Đây là một chủ đề rất được nhiều Webmaster tìm kiếm và quan tâm nhiều nhất, bởi hệ thống website mà các WMT đang quản trị có thể đang bị lỗi truy vấn cơ sở dữ liệu (csdl) hay database dẫn đến website bị lỗi 5xx (lỗi 502, 504) khiến server/ hosting bị overload.

Database WordPress của bạn lưu giữ toàn bộ nội dung của website. Điều này bao gồm bài đăng blog dạng post, dạng page, bình luận, và các định dạng post tùy chỉnh như các liên kết, nội dung nhập vào form, và các thành phần portfolio, các đơn hàng và xử lý đơn hàng đi theo nó. Nó cũng lưu trữ các cài đặt của website, giao diện và plugin.

Nếu bạn cập nhật website thường xuyên, database của bạn sẽ lớn dần lên theo thời gian. Một database lớn có thể ảnh hưởng mạnh đến hiệu suất (performance) của website cũng như gây ra hiện tượng máy chủ của bạn mất nhiều thời gian hơn để xuất/nhập thông tin từ bảng cơ sở dữ liệu (database tables). Điều đó giải thích vì sao tối ưu hóa database lại quan trọng đến vậy.

Bằng cách loại bỏ các dữ liệu không cần thiết, bạn có thể cải thiện được tính hiệu quả của database và làm cho website của bạn tải nhanh hơn. Chúng ta sẽ cùng nhau đi từng bước để đạt được điều đó.

A. Tìm hiểu database của WordPress

Nếu bạn sử dụng WordPress để xuất bản nội dung lên internet, tôi tin rằng bạn sẽ nhận được nhiều lợi ích khi tìm hiểu lõi của bảng database trong WordPress; đặc biệt là nếu bạn đang có ý định tối ưu hóa database trang WordPress của bạn.

WordPress hiện có 11 bảng lõi (điều này, dĩ nhiên là sẽ có khả năng thay đổi vào bất kỳ lúc nào ở các phiên bản cập nhật trong tương lai của WordPress). Hầu hết các website WordPress có hàng tá bảng bởi vì các plugin lưu các cài đặt và dữ liệu khác trong database của WordPress. Các giao diện cũng có thể lưu các cài đặt và dữ liệu khác trong database của bạn.

Nếu bạn kiểm tra database của bạn, bạn sẽ thấy 11 bảng được liệt kê bên dưới đây. Tất cả các bảng khác 11 bảng này trong database của bạn được tạo thủ công hoặc được tạo bởi plugin WordPress hoặc giao diện WordPress.

>>> Xem thêm: Standard WordPress Tables

Hãy cùng xem từng bảng trong database lưu trữ điều gì:

  • wp_commentmeta – Lưu trữ các thông tin meta (siêu dữ liệu) về các bình luận
  • wp_comments – Lưu trữ các bình luận của bạn
  • wp_links – Lưu trữ các liên kết blogroll (tính năng blogroll hiện không còn dùng nữa, nhưng có thể được thêm vào bằng plugin Link Manager)
  • wp_options – Lưu trữ các tùy chọn được định rõ trong khu vực cài đặt của admin
  • wp_postmeta – Lưu trữ các thông tin post meta
  • wp_posts – Lưu trữ dữ liệu các bài post, pages, và các định dạng tùy chỉnh post khác
  • wp_terms – Lưu trữ các tag của post và các thư mục cho các post và liên kết
  • wp_term_relationships – Lưu trữ các mối liên kết giữa post và các thư mục và các tag cũng như mối quan hệ giữa các liên kết và thư mục liên kết
  • wp_term_taxonomy – Lưu trữ mô tả về taxonomy (thư mục, liên kết, hoặc tag) được sử dụng trong bảng wp_terms_table
  • wp_usermeta – Lưu trữ thông tin meta về các người dùng
  • wp_users – Lưu trữ người dùng của website (ví dụ admin, người đăng bài, duyệt bài, vân vân)

Nếu muốn tìm hiểu kỹ hơn về các bảng dữ liệu của WordPress, bạn hãy truy cập thông tin mô tả trên trang wordpress.org.

bảng dữ liệu lõi của WordPress

B. Cách tối ưu hóa và sửa chữa 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).

phpMyAdmin là cách phổ biến nhất để quản trị database trong WordPress. Nếu bạn không sử dụng cPanel làm công cụ quản trị hosting, gói hosting của bạn có thể sử dụng sử dụng công cụ quản trị MySQL khác phpMyAdmin. Đừng quá lăn tăn về điều này vì hầu hết các công cụ quản trị database có giao diện sử dụng tương tự nhau và làm việc theo cùng một cách.

Bạn có thể đang quản trị database WordPress thông qua plugin như Adminer (tên trước đây của nó là phpMinAdmin). Mặc dù plugin quản trị database của WordPress có thể giúp truy cập database theo cách đơn giản hơn, tôi khuyên không nên quản trị database của bạn theo cách này vì nó có nguy cơ bảo mật lớn (security risk). Nếu bạn đã cài plugin kiểu như Adminer và một ai đó không được phép lại truy cập được vào database của bạn, họ có thể làm bất cứ điều gì họ muốn trên website của bạ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).

1. 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)
tối ưu hóa bảng

2. 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

tên storage engine

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.

  a. MyISAM:
                 + Chỉ có thể đọc table đồng thời mà không thể ghi đồng thời
                 + Tự sữa chữa và phục hồi dữ liệu tốt sau khi hệ thống bị crash.
                 + Hỗ trợ tìm kiếm full-text index.
                 + Tăng tốc độ ghi nhờ không ghi dữ liệu vào ổ cứng ngay mà ghi vào buffer trên RAM trước, sau một khoảng thời gian mới ghi vào ổ cứng.
                 + Hỗ trợ nén dữ liệu giúp tăng tốc độ đọc dữ liệu nhưng dữ liệu sau khi nén không thể cập nhật được.
  b. InnoDB:
+ Có khả năng phục hồi, sửa chữa tốt.
+ Là engine phức tạp nhất trong các engine của MySQL.
+ Hỗ trợ MVCC (Multiversion Concurrency Control) do đó table có thể đọc và ghi đồng thời.
+ Sử dụng clustered index do đó hiệu năng tìm kiếm theo primakey rất cao.
+ Lưu dữ liệu trên 1 file (thuật ngữ gọi là tablespace).
+ Hỗ trợ transactions.
2. Cách chuyển MyISAM sang InnoDB và ngược lại
– Sử dụng cú pháp MySQL sau để chuyển từng table MyISAM sang InnoDB: ALTER TABLE table_name ENGINE = MyISAM;
– Sử dụng cú pháp MySQL sau để chuyển từng table InnoDB sang InnoDB: ALTER TABLE table_name ENGINE = InnoDB;
– Hướng dẫn chuyển tất cả table của một database từ MyISAM sang InnoDB:
+ Tạo file script: “vi script”
+ Thêm nội dung sau vào file script
         #!/bin/sh
DBNAME=”your-database”
DBUSER=”your-username”
DBPWD=”your-password”for t in $(mysql -u$DBUSER -p$DBPWD –batch –column-names=false-e “show tables” $DBNAME);do
echo “Converting table $t”
mysql -u$DBUSER -p$DBPWD -e “alter table $t engine=InnoDB” $DBNAME;done

         Trong đó “your-database” là database cần chuyển, “your-username” là user name của được gán quyền cho database, “your-password” là password của user.

+ Thêm quyền thực thi cho file script: “chmod +x script
+ Chạy file script: ./script

  – Khách hàng có thể sử dụng script trên để chuyển InnoDB sang MyISAM với script trên bằng cách sửa dòng “mysql -u$DBUSER -p$DBPWD -e “alter table $t engine=InnoDB” $DBNAME;done” thành “mysql -u$DBUSER -p$DBPWD -e “alter table $t engine=MyISAM” $DBNAME;done”
Tips: Nếu bạn không biết cách chuyển bằng câu lệnh( chọn database cần chuyển >>> chuyển sang thẻ sql và paste đoạn lệnh trên vào >>> ấn Go) thì bạn có thể làm thủ công như sau:

b1. Truy cập phpMyAdmin của hosting.

click-vao-muc-phpmyadmin-trong-cpanel

b2. Trong giao diện phpMyAdmin, click chọn database tương ứng với website của bạn. Danh sách các table của database sẽ hiện ra ở bên phải. Hãy chú ý đến cột Type, đây chính là công nghệ lưu trữ mà các table đang sử dụng.

kiem-tra-cong-nghe-luu-tru-database-trong-phpmyadmin

b3. Click vào 1 table mà bạn muốn chuyển đổi công nghệ lưu trữ => click tiếp vào tab Operations.

click-vao-tab-operations-trong-phpmyadmin

b4. Trong cột Table options, hãy click vào mục Storage Engine và chọn InnoDB.

click-vao-muc-storage-engine

Click vào nút Go để xác nhận thay đổi.

b5. Chờ trong giây lát cho quá trình chuyển đổi hoàn tất, bạn sẽ nhận được thông báo tương tự như thế này.

query-has-been-executed-successfully

b6. Quay trở lại danh sách table, các bạn sẽ thấy Type của table đã được chuyển thành InnoDB.

chuyen-doi-storage-engine-thanh-cong

Lặp lại các bước bên trên cho đến khi tất cả các table đều được chuyển hết thành InnoDB. Thật đơn giản phải không nào? Chúc các bạn thành cô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í).

3. Loại bỏ overhead

Nếu bạn kiểm tra database của bạn, bạn sẽ thấy hai cột ở cuối: size và overhead. Kích cỡ của bảng phụ thuộc vào số lượng dữ liệu được lưu trữ trong đó. Nếu nhiều hàng được lưu trữ trong bảng, kích cỡ của bảng sẽ tăng.

Overhead là không gian lưu trữ tạm thời được sử dụng bởi database của bạn để lưu trữ truy vấn. Qua thời gian, bảng overhead sẽ tăng kích cỡ.

Hoàn toàn bình thường thôi khi có overhead trong database WordPress của bạn và nó không làm ảnh hưởng đến hiệu suất trừ khi overhead quá cao.

Size và Overhead ở bên cuối
Size và overhead của database hiển thị ngoài cùng bên tay phải

 

Lưu ý: hình chụp màn hình ở trên được lấy từ bản cài đặt mới của WordPress. Đây là lý do tại sao tiền tố của database vẫn là wp_. Để website của bạn bảo mật hơn, bạn nên thay đổi tiền tố database của WordPress thông qua wp-config.php sang tên khác.

Tối ưu hóa database sẽ loại bỏ overhead và làm giảm kích cỡ tổng thể của database. Nhiều lập trình viên lưu ý rằng tối ưu hóa database giống như việc chống phân mảnh ổ cứng.

Tất cả database, qua thời gian yêu cầu một số bảo trì nhất định để duy trì được hiệu suất tối ưu. Xóa bỏ các hàng, sắp xếp lại, nén, quản lý đường dẫn chỉ mục, chống phân mảnh, vân vân là những thứ được coi là TỐI ƯU HÓA trong mysql.

Lấy ví dụ IBM DB2/400 gọi nó là REORGANIZE PHYSICAL FILE MEMBER. Điều này giống như việc thay dầu hoặc sửa chữa xe. Bạn có thể nghĩ rằng bạn không thực sự cần làm vậy, nhưng bằng cách sửa chữa bạn giúp xe chạy tốt hơn nhiều, và tiết kiệm xăng, vân vân. Chiếc xe càng chạy nhiều bạn càng cần bảo dưỡng thường xuyên hơn.

Tương tự, database cũng phải xử lý rất nhiều yêu cầu. Nếu bạn thực hiện việc CẬP NHẬT và/hoặc XÓA liên tục, và đặc biệt nếu các bảng có các cột có độ dài biến đổi (VARCHAR, TEXT, vân vân), bạn cần để ý bảo dưỡng chúng.

Bạn có thể tối ưu hóa bảng bị ảnh hưởng bởi overhead bằng cách sử dụng các câu lệnh SQL TỐI ƯU HÓA BẢNG (Optimize table). Lấy ví dụ, bạn có thể tối ưu bảng wp_posts bằng cách thực thi truy vấn sau:

OPTIMIZE TABLE 'wp_posts'

Bạn không cần phải sử dụng câu lệnh SQL vì phpMyAdmin cho phép bạn tối ưu hóa bảng thông qua menu xổ xuống. Tất cả điều bạn cần để tối ưu database là click vào box “Check All”, chọn “Optimize table” từ menu xổ xuống, rồi sau đó click vào nút “Go”.

Một khi bạn đã tối ưu hóa database WordPress, phpMyAdmin sẽ xác nhận rằng các bảng của bạn đã được tối ưu.

Một tùy chọn hữu ích khác bạn cần ghi nhớ để dùng trong tương lai là “Repair table / Sửa bảng”. Repair table sẽ giúp bạn sửa bảng bị hỏng.

WordPress có công cụ cho phép bạn sửa và tối ưu database của bạn. Bạn có thể tìm hiểu thêm công cụ này ở khu vực hướng dẫn trên wordpress.org thuộc phần Tự động Tối ưu hóa Database thông qua wp-config.php

Để sử dụng công cụ tối ưu hóa, trước hết bạn cần thêm dòng dưới đây vào website của bạn ở file wp-config.php

define( 'WP_ALLOW_REPAIR', true );

Một khi bạn đã thêm dòng trên vào wp-config.php và lưu file, bạn có thể truy cập công cụ tối ưu hóa tại đường dẫn http://www.ten-mien-cua-ban.com/wp-admin/maint/repair.php

sửa lại database

Công cụ tối ưu hóa sẽ cố gắng sửa từng bảng cơ sở dữ liệu. Theo thời gian, tệp lệnh có thể không có khả năng sửa các bảng nhất định.

sửa thành công

Nếu bạn không sửa thành công cơ sở dữ liệu của bạn trong lần thử đầu tiên, bạn có thể chạy công cụ tối ưu hóa lần nữa.

Nếu bạn chọn “Repair and Optimize Database”, WordPress sẽ tối ưu hóa từng bảng chưa được tối ưu hóa.

Bạn không cần đăng nhập để khởi chạy công cụ tối ưu hóa WordPress. Nhược điểm này khiến bất cứ ai cũng có thể truy cập vào tệp lệnh của bạn và thực thi nó. Vì vậy, bạn cần loại bỏ dòng WP_ALLOW_REPAIR khỏi file wp-config.php sau khi bạn sử dụng xong công cụ tối ưu hóa này.

4. Tắt Autosave

WordPress tự động lưu Post sau mỗi 2 phút và lưu chúng dưới dạng revision. Tất cả những revisions của một Post sẽ ghi thêm, nhân bản vào DB và làm tăng kích thước CSDL của bạn.

Nếu bạn viết một bài văn dài, bạn cần tắt tính năng Autosave trong WordPress là điều kiên quyết. Thêm vào dòng sau của tệp functions.php

function disableAutoSaveCompletely() {
	wp_deregister_script('autosave');
}
add_action( 'wp_print_scripts', 'disableAutoSaveCompletely' );


5. Làm thế nào để loại bỏ hiện tượng phình to database trong WordPress

Database của WordPress hầu như lưu trữ rất nhiều dữ liệu không cần thiết. Điều này làm phình dữ liệu và chậm website.

Có một số thứ là nguyên nhân gây phình to CSDL của WordPress. Dù vậy thì bằng cách làm theo một số thực hành phù hợp, bạn có thể giảm phần lớn dữ liệu dư thừa này, hoặc thậm chí loại bỏ hoàn toàn dữ liệu vô ích ra khỏi website của bạn.

Nào, chúng ta cùng xem các nguyên nhân chính gây phình to CSDL của WordPress.

a. Revisions

Hệ thống revisions của WordPress tạo ra nhiều database lớn không cần thiết. Được giới thiệu lần đầu trong WordPress 2.6, tính năng này giúp lưu trữ từng bản sao chép của bản nháp và mọi cập nhật cho bài post blog. Revision là tính năng hữu ích cho phép bạn khôi phục lại các bản sao chép cũ hơn của bài viết và kiểm tra các bản nháp trước đây.

Tuy nhiên cái dở ở đây là WordPress không giới hạn số lượng revision có thể lưu. Nếu bạn làm việc trên một bài viết dài (cần nhiều thời gian để viết nên bạn sẽ nhấn lưu nháp và/hoặc xuất bản rất nhiều lần), điều này gây ra hệ quả là có thể có hàng trăm revision được lưu giữ. Thậm chí ngay cả bài viết đã được xuất bản chỉ chiếm một dòng trong bảng CSDL, các bản revision tương ứng của nó có thể có hàng tá, hoặc thậm chí là hàng trăm dòng trong CSDL của bạn.

Tôi là người ủng hộ hệ thống revision, tuy nhiên tôi không tin bạn có lợi ích thực tế khi lưu trữ không giới hạn các bản revision của từng bài đăng. Rất may là WordPress cho phép bạn dễ dàng giảm số lượng revision lưu trữ xuống con số mà bạn muốn.

Để giảm số lượng revision xuống, đơn giản là bạn thêm đoạn mã sau vào file wp-configs.php (dòng dưới đây giảm số lượng revision xuống chỉ 2 bản):

define('WP_POST_REVISIONS', 2);

Các revision của bài post có thể hoàn toàn được vô hiệu hóa bằng cách thêm đoạn mã sau vào file wp-config.php.

define('WP_POST_REVISIONS', false);

Tôi không khuyến khích bạn vô hiệu hóa tính năng revision hoàn toàn. Cho dù việc vô hiệu hóa revision chắc chắn giúp giảm kích cỡ CSDL của bạn, nhưng nó sẽ loại bỏ khả năng khôi phục khi xảy ra lỗi. Ví dụ, trong tình huống bạn đóng cửa sổ trình duyệt vì lỗi nào đó hoặc mất kết nối internet, bạn có thể mất mọi thứ bạn đã gõ xuống kể từ lần lưu nháp cuối cùng!

Giảm số lượng revision được phép lưu, hoặc vô hiệu hóa revision không làm ảnh hưởng đến các revision đã lưu trước đó. Vì thế, các revision gắn với các bài đăng cũ sẽ vẫn được lưu trữ trong CSDL của bạn.

Một khi bài viết được xuất bản, bạn hầu như không còn nhu cầu giữ các post revision cũ làm gì nữa, do vậy, bạn có thể cân nhắc loại bỏ tất cả các revision từ bài viết đã xuất bản. Có một số plugin cho phép bạn làm điều này (bạn cũng có thể loại bỏ revision bằng cách sử dụng MySQL; tuy nhiên bạn phải ý thức được rắc rối có thể xảy ra nếu bạn không sử dụng câu lệnh một cách chính xác).

Ví dụ, tôi đã sử dụng plugin Optimize Database after Deleting Revisions đầu năm nay để giảm kích cỡ database của tôi đến 59%.

Plugin này cho phép bạn định rõ số lượng các bản revision được phép lưu. Nó cũng cho phép bạn xóa các item trong thùng rác, item spam, các tag không sử dụng, và các transients quá hạn. Các bảng database cụ thể có thể được loại bỏ từ quá trình tối ưu hóa.

Optimize Database after Deleting Revisions cho phép lên lịch xóa định kỳ (scheduler). Nó có thể tối ưu hóa website của bạn một cách tự động một lần mỗi giờ, hai lần một ngày, hoặc một lần một tuần.

Một tùy chọn khác để xóa các post revision là Better Delete Revision. Nó cung cấp một danh sách tất cả các revision đã lưu trên website của bạn. Đáng tiếc, không có tùy chọn xóa revision cụ thể từng cái; chỉ có duy nhất tùy chọn xóa tất cả revision cùng một lúc. Plugin cũng có một tùy chọn để tối ưu hóa tất cả bảng CSDL của bạn để giảm overhead.

Tôi cũng muốn nói ngắn gọn về tính năng autosaves. Tính năng autosave của WordPress tự động lưu một bản lưu bài viết của bạn cứ 60 giây một lần. Tần số này có thể được thay đổi bằng cách thêm đoạn mã sau vào file wp-config.php (*)

define('AUTOSAVE_INTERVAL', 600); // Seconds

Có nhiều blogger đưa ra lời khuyên vô hiệu hóa tính năng tự động lưu vì nó tạo ra nhiều bản sao tự động của bài post và page. Điều này đơn giản không đúng.  Tự động lưu bao giờ cũng chỉ tạo ra một bản sao bài viết của bạn (không giống với revision vẫn giữ nhiều bản sao) và do vậy nó sẽ không sử dụng nhiều không gian bộ nhớ trong database của bạn.

Tính năng tự động lưu là chức năng bảo vệ quan trọng khi chuyện không như ý xảy ra, chẳng hạn như việc bị mất kết nối internet, hoặc đóng cửa sổ trình duyệt do nhầm lẫn. Tính năng này không sử dụng nhiều không gian trong CSDL của bạn; vì thế tôi khuyến khích bạn để nó được kích hoạt.

(*): Cá nhân tôi không thấy tác dụng gì đáng kể khi bạn nâng thời gian tự động lưu từ 60s lên 160s, vì thực sự tác vụ này rất nhẹ nhàng, nó chỉ tạo ra một bản lưu, hơn nữa, đa số các website chỉ có ‘một hoặc vài người viết. Do vậy tác động (nếu có) là cực kỳ nhỏ đến hiệu suất.

b. Các bình luận spam

Nếu website của bạn nhận rất nhiều spam, bạn có thể nhận ra là các bình luận spam lấy rất nhiều không gian trong CSDL. Theo mặc định, các bình luận spam sẽ được tự động xóa sau 30 ngày; tuy nhiên trong suốt thời gian này chúng có thể tăng số lượng lên đến hàng ngàn thậm chí chục ngàn dòng trong bảng wp_comments của bạn.

Một plugin chống spam tốt có thể ngăn chặn nhiều spammer bằng cách lưu giữ hành vi mẫu của họ, do vậy số lượng các bình luận spam bạn bị nhận sẽ giảm xuống.

Akismet (xem thêm quản lý bình luận trong WordPress) là giải pháp tốt vì nó cho phép bạn loại bỏ các spam rõ ràng vì thế bình luận được loại bỏ khỏi CSDL của bạn ngay lập tức (mặc dù bạn cũng có rủi ro là các bình luận không phải spam cũng có thể bị xóa tự động do hệ thống nhận diện nhầm, tuy nhiên thiệt hại này thường rất nhỏ so với lợi ích chống spam mà plugin cung cấp).

Các tay spammer có xu hướng nhắm đến các bài viết cũ có thứ hạng tốt trên máy tìm kiếm. Do đó bạn có thể làm giảm số lượng spam trên website của bạn bằng việc cân nhắc vô hiệu hóa bình luận trên các bài viết cũ sau khi nó đạt tuổi ngày nhất định (ví dụ 100 ngày). Hiện tính năng này có sẵn trong phần discussion setting thuộc khu vực quản trị của WordPress.

Các bình luận spam cũng có thể được xóa bỏ bằng cách sử dụng truy vấn SQL sau:

DELETE FROM wp_comments WHERE comment_approved = 'spam'

Tất cả các bình luận chờ phê duyệt có thể được xóa bỏ bằng cách sử dụng truy vấn SQL sau:

DELETE FROM wp_comments WHERE comment_approved = '0'

Tuy nhiên hiện tại bạn có thể xóa bỏ tất cả bình luận spam bằng nút Empty Spam trong trang quản trị nên sẽ không thực tế nếu bạn lại sử dụng truy vấn SQL để xóa spam khỏi database.

c. Xóa bỏ các items

Bất cứ khi nào bạn xóa một item trong WordPress, chẳng hạn như một bài đăng blog, trang, ảnh, bình luận, hoặc liên kết, nó sẽ được gửi sang thư mục rác (trash). Đây là một hệ thống dự phòng khác của WordPress ngăn bạn xóa nhầm một thành phần nào đó do sơ ý.

Nếu bạn muốn, hệ thống cho phép bạn khôi phục lại item hiện đang nằm trong thùng rác (về mặt chức năng nó không khác gì thùng rác của hệ điều hành Windows quen thuộc).

Trừ khi bạn xóa nhiều item một cách thường xuyên, bạn không cần phải lo lắng về không gian của các item đã bị xóa nhưng vẫn chiếm chỗ trong database. Dù vậy, sẽ có ích khi hiểu được cách hệ thống thùng rác làm việc, đặc biệt nếu bạn đã thực hiện việc xóa hàng trăm hoặc hàng ngàn item từ trang WordPress (bất kể nó có là bài post, bình luận, ảnh hoặc gì đi chăng nữa).

Item đã được xóa sẽ tiếp tục nằm trong database của bạn cho đến khi thùng rác được làm trống hoàn toàn. Theo mặc định, các item trong thùng rác sẽ được xóa hoàn toàn sau 30 ngày.

Số ngày mặc định trước khi xóa hẳn này có thể được thay đổi bằng cách thêm đoạn mã sau vào file wp-config.php

define( 'EMPTY_TRASH_DAYS', 5 ); // 5 days

Hệ thống thùng rác có thể được vô hiệu hóa hoàn toàn bằng cách thêm đoạn mã sau vào file wp-config.php – bạn để số ngày về 0

define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days

Tôi không tin rằng vô hiệu hóa hoàn toàn hệ thống thùng rác là cách tốt vì làm như thế bạn sẽ không có khả năng khôi phục lại bất kỳ item nào bị xóa do sơ xuất.

d. Xóa các table của các plugin không còn sử dụng

Một số plugin khi cài vào sẽ “bonus” cho bạn thêm vào table trong database mà khi gỡ ra nó không chịu xóa đi, điều này có thể làm bạn hơi rối mắt.

Do đó, thi thoảng nên kiểm tra xem trong database của bạn có table nào không còn sử dụng hay không. Nếu không thì cứ chọn nó và chọn tác vụ Drop là xong.

phpmyadmin-drop-table

Hãy cẩn thận khi xóa table nhé và chắc chắn bạn nên hiểu mình đang làm gì, cũng đừng nên quên backup database trước khi làm việc này.

e. Tìm và xóa các giá trị database không sử dụng

Nếu bạn đã sử dụng website WordPress trong một thời gian dài, đã từng sử dụng quá nhiều plugin và theme khác nhau thì chắc chắn database của bạn sẽ chứa rất nhiều những giá trị không còn sử dụng đến, ví dụ như các cột giá trị của post meta và các thiết lập tùy chọn tự sản sinh ra trong plugin và theme.

Khi vào database, bạn nên để ý đến table wp_postmeta đầu tiên vì nó sẽ chứa các dữ liệu liên quan đến các dữ liệu vĩ mô của các post, ví như bạn sử dụng các plugin có thiết lập khi đăng bài thì nó sẽ lưu vào đây. Hãy ấn chọn table này và bạn sẽ thấy các giá trị của nó:

lamsachdatabase-postmeta

Bạn hãy để ý phần meta_key, nghĩa là tên của khóa trong custom field. Bạn xem có khóa nào của các plugin mà bạn nghĩ là không còn sử dụng nữa ngoài các khóa của WordPress (luôn bắt đầu là _wp). Chẳng hạn như mình thấy, mình có một số khóa tên essb_hidefb, essb_off và các khóa này mình nghĩ là không còn sử dụng nữa. Vậy thì việc tiếp theo mà mình cần làm đó là tìm toàn bộ các khóa theo tên này xem nó có nhiều không.

Mình chọn lên tab Search ở trên. Ở phần khóa meta_key, mình sẽ nhập một phần tên của khóa cần tìm kiếm và mình sẽ chọn kiểu Operator là LIKE %…% để có thể tìm theo tên tương đồng. Cuối cùng ấn nút Go để nó tìm.

lamsachdatabase-postmeta02

Và bây giờ nó sẽ liệt kê ra toàn bộ danh sách các khóa theo tên mà bạn tìm, bạn sẽ biết được nó có bao nhiêu dữ liệu như vậy.

lamsachdatabase-postmeta03

Nếu bạn cảm thấy cần xóa toàn bộ các dữ liệu này thì hãy copy cái dòng Query ở trên.

lamsachdatabase-postmeta04

Và chuyển qua tab SQL kế bên rồi paste vào, thay chữ SELECT * thành DELETE rồi ấn Go.

lamsachdatabase-postmeta05

Và nó sẽ thông báo có bao nhiêu dữ liệu liên quan tới khóa này đã được xóa.

Các bạn làm tương tự với các table khác nhé. Xin nhắc lại là làm table nào thì hãy chọn table đó rồi làm theo cách 4 này.

C. WordPress Transients

Chú thích từ người dịch: Đây là phần duy nhất mà các plugin tác giả đề cập là tương đối cập nhật, các plugin được nói trong các phần khác đều rất cũ.

WordPress Transients cung cấp cho lập trình viên cách để lưu trữ dữ liệu tạm thời trong database của WordPress. Các bản ghi transient được lưu trữ trong các bảng options của WordPress.

Các bản ghi transient quá hạn có thể làm đầy database của bạn và làm website của bạn chạy chậm lại. Có một số plugin có thể giúp bạn quản trị các transients và loại bỏ các bản ghi transient không còn dùng đến nữa.

Plugin WordPress có tên Trasient Cleaner cung cấp tùy chọn cho phép bạn loại bỏ các transients quá hạn và loại bỏ tất cả các transients. Plugin Delete Expired Transients cũng cung cấp chức năng này và cho phép bạn cài đặt tác vụ thực hiện lặp lại hàng ngày để loại bỏ các transients quá hạn.

Transients Manager là một trong các giải pháp tốt nhất để xem các transients của bạn. Nó cho phép bạn xem, chỉnh sửa và loại bỏ các transients. Tuy nhiên, plugin này không có bất kỳ tùy chọn nào để xóa số lượng lớn các transients quá hạn.

Transients không phải là cái gì đó mà bạn cần lo lắng thường xuyên, dù vậy nó xứng đáng được kiểm tra định kỳ để xác định được rằng chúng không làm ảnh hưởng đến hiệu suất.

D. Các bảng của plugin và giao diện không sử dụng

99% tất cả plugin WordPress lưu trữ các cài đặt (setting)* và dữ liệu của nó trong database của WordPress. Thật không may, khi bạn gỡ bản cài một plugin WordPress nào đó, thông tin này không bị loại bỏ đâu!

(*): setting được dịch là cài đặt nhưng bạn đừng nhầm với install, cũng hay được dịch là cài đặt. Để dễ hiểu thì install giống như bạn lắp máy điều hòa, bạn đục tường, đo dây, lắp cục nóng, cục lạnh; còn setting giống với cách bạn sử dụng, như bạn cài nhiệt độ bao nhiêu, có bật chế độ im lặng không, có bật hẹn giờ, lọc không khí không, vân vân.

Điều này là do thiết kế. Nếu dữ liệu bị loại bỏ mỗi lần bạn vô hiệu hóa/xóa một plugin, bạn sẽ phải cấu hình lại plugin khi bạn kích hoạt lại nó / reactivate ** (nhiều plugin có cấu hình rất phức tạp). Bạn sẽ mất bất kỳ báo cáo hoặc nội dung nào mà plugin đã tạo ra (ví dụ các bảng khảo sát, các thông tin mà người dùng điền vào form).

(**) và (***): khi bạn không dùng plugin nào đó bạn có hai lựa chọn: (1) bạn hủy kích hoạt nó còn gọi là deactivate hoặc (2) bạn gỡ hẳn nó ra còn gọi là uninstall. Để uninstall bạn buộc phải deactive nó trước.

Tuy vậy, nếu bạn quyết định ngừng sử dụng plugin, hoặc nếu bạn chỉ đơn giản đang test thử plugin, bạn sẽ muốn loại bỏ hoàn toàn tất cả dữ liệu khi bạn gỡ cài đặt (uninstall) *** plugin. Chỉ có một lượng nhỏ plugin WordPress bao gồm tùy chọn trong cài đặt của họ cho phép bạn loại bỏ toàn bộ dữ liệu, trong khi phần lớn plugin không có tùy chọn này.

(***): unistall mạnh hơn deactive. Với deactive, plugin chỉ như ngủ đông thôi, còn unistall là bạn gần như loại bỏ nó khỏi website.

Vì lý do đó, database của WordPress có thể tích lũy rất nhiều dữ liệu dư thừa theo thời gian. Không có gì lạ khi database của WordPress bao gồm hàng tá bảng của plugin mà đã bị loại bỏ nhiều tháng trước đây, hoặc thậm chí là nhiều năm trước.

Giao diện của WordPress cũng lưu trữ các cài đặt trong database WordPress và các cài đặt này sẽ vẫn còn trong database của bạn khi bạn chuyển sang dùng giao diện khác.

Các bảng không sử dụng có thể được loại bỏ khỏi database của bạn theo cách thủ công thông qua công cụ quản trị database như phpMyAdmin. Dù vậy, ngay cả khi bạn có hiểu biết tốt về 11 bảng lõi trong WordPress, bạn sẽ thấy là khó có thể phân biệt được bảng nào là của plugin đang được kích hoạt, còn bảng nào là của plugin đã gỡ cài đặt rồi.

Chú thích của người dịch: thực ra các bảng trong database là thứ dễ kiểm tra nhất để biết nó thuộc về plugin nào, các trang như Plugintests cung cấp các thông tin kiểu như vậy. Về sau bạn sẽ thấy Cron Jobs và Options mới là thứ khó biết. Các bảng dù sao cũng không nhiều, chỉ vài chục cái, mất vài tiếng cần cù search trên mạng là sẽ ra thôi. Tất nhiên một số plugin không phổ biến hoặc trong quá trình phát triển nó thay đổi tên bảng CSDL thì sẽ khó tìm hơn. Trong trường hợp như vậy vẫn có giải pháp, dù khá mất công. Đó là bạn tạo một trang WordPress trắng demo, sau đó cài lại tất cả các plugin hiện bạn đang kích hoạt trên trang, rồi sau đó bạn so sánh các bảng dữ liệu ở hai trang, trang web chính thức và trang demo, bạn sẽ nhanh chóng phát hiện ra các bảng nào thuộc trang chính thức là tàn dư của (các) plugin và/hoặc theme cũ kỹ đã không còn dùng đến từ lâu.

1. Các plugin gây cồng kềnh

Chú thích của người dịch: Tôi cho rằng đây là một trong các phần bạn cần để ý nhất! Có rất nhiều plugin thu thập dữ liệu, và sẽ trở thành vấn đề về kích cỡ trên website trung bình hoặc lớn. Theo thời gian nó có thể tích trữ một lượng dữ liệu khổng lồ mà phần nhiều trong số đó không còn hữu ích nữa vì sau khi đã được tổng hợp phân tích, hầu hết dữ liệu quá khứ có thể loại bỏ đi được.

Mỗi plugin bạn cài trên website đều làm gia tăng kích cỡ của database. Không gian lưu trữ mà một số plugin sử dụng trong database có thể không đáng kể; nhưng một số plugin khác lại có thể bổ sung thêm rất nhiều vào database.

Bất cứ khi nào bạn cài một plugin WordPress mới, bạn phải lưu tâm kiểm tra nó ảnh hưởng đến CPU của máy chủ thế nào, và không gian lưu trữ mà nó chiếm dữ trong cơ sở dữ liệu là bao nhiêu.

Các kiểu plugin WordPress sau được biết đến là lưu trữ rất nhiều dữ liệu trong database.

  • Các plugin chống spam – Để bảo vệ website của bạn, nhiều plugin chống spam lưu trữ thông tin như địa chỉ IP và địa chỉ email. Lấy ví dụ, Akismet lưu trữ rất nhiều dữ liệu trong bảng WP_CommentMeta.
  • Các plugin bảo mật – Cũng giống như các plugin chống spam, các plugin bảo mật lưu giữ và theo dõi nhiều thông tin về spammer và hacker (ví dụ plugin wordfence có thể tạo ra nhiều bảng dữ liệu có kích cỡ lớn).
  • Các plugin thống kê – Các plugin WordPress cung cấp các báo cáo về lưu lượng truy cập và phân tích cần lưu trữ một lượng lớn dữ liệu trong database website của bạn. Điều này bao gồm thông tin lượt xem, lượt ghé thăm, quốc gia, trình duyệt, hệ điều hành, trang giới thiệu, từ khóa, và nhiều thông tin khác nữa.
  • Plugin bài viết liên quan và bài viết phổ biến – Các plugin WordPress cho mục đích này rõ ràng sử dụng rất nhiều CPU và không gian lưu trữ của database. Các kiểu plugin này cần lưu trữ nhiều dữ liệu trong database; chẳng hạn như số lượt thích (like), chia sẻ (share), và lượt xem (views) mà từng trang trên website của bạn nhận được.
  • Các plugin phân tích liên kết (tracking link) – Hầu hết các giải pháp theo dõi liên kết cho bạn tùy chọn lưu giữ thông tin số lượng click vào liên kết. Điều này có ích khi bạn muốn hiểu thói quen của người đọc và nơi nào lưu lượng truy cập bị hướng ra ngoài nhiều nhất. Tuy nhiên, theo dõi các click như vậy có thể tốn rất nhiều không gian lưu trữ của database (thường không chỉ số lượt click, nó còn lưu thông tin trình duyệt, thời gian, hệ điều hành, IP, vân vân).

Một số nhà lập trình quan tâm đến thực tế là plugin của họ sử dụng rất nhiều không gian lưu trữ. Điều đó giải thích tại sao những nhà lập trình đó đưa ra tùy chọn xóa dữ liệu trong plugin của họ.

Lấy ví dụ, tôi theo dõi liên kết bằng plugin Pretty Link. Plugin cho phép bạn vô hiệu hóa hệ thống theo dõi được xây dựng bên trong. Có ba cài đặt theo dõi để bạn chọn lựa, bao gồm: (1) Theo dõi thông thường, (2) Cấu hình theo dõi mở rộng cung cấp nhiều thống kê hơn nhưng làm ảnh hưởng đến hiệu suất/tốc độ, và (3) Tùy chọn theo dõi click đơn giản cung cấp ít dữ liệu hơn nhưng lại giúp bạn có được hiệu suất tốt nhất.

Các con số thống kê cũng có thể được xóa trong khu vực tùy chỉnh. Plugin cho phép bạn xóa tất cả các thông tin lưu trữ trong 30 ngày hoặc 90 ngày đã qua.

Một số plugin WordPress khác cho phép bạn reset lại dữ liệu và loại bỏ các bảng mà plugin đã thêm vào. Dù vậy, nói chung, hầu hết plugin không có tính năng cho phép loại bỏ toàn bộ dữ liệu.

công cụ kiểm tra ảnh hưởng hiệu suất của plugin
P3 plugin có thể giúp bạn đánh dấu những plugin làm chậm website của bạn

Một công cụ tốt để kiểm tra các plugin cài trên trang WordPress của bạn có làm chậm website của bạn hay không là P3 (Plugin Performance Profiler). Plugin sẽ highlight ảnh hưởng của từng plugin lên thời gian tải trang.

Nếu một plugin sử dụng nhiều không gian lưu trữ trong database, hoặc làm chậm website của bạn đáng kể, hãy loại bỏ nó. Tôi chỉ khuyên giữ lại plugin làm chậm website nếu nó nắm vai trò rất quan trọng với mục tiêu của website. Dù vậy, tôi tin rằng luôn luôn có các giải pháp thay thế nhẹ nhàng hơn để bạn không còn phải sử dụng plugin nặng nề nữa.

2. Cách tối ưu database của bạn bằng plugin

Thông qua bài viết này tôi đã đưa ra lời khuyên về cách tối ưu hóa database sử dụng phpMyAdmin và wp-config.php. Nếu việc sử dụng phpMyAdmin làm bạn lo lắng, bạn có thể thích sử dụng các plugin WordPress để tối ưu hóa cơ sở dữ liệu. Chúng ta có một số plugin tốt đảm nhiệm được tốt vai trò này.

WP Clean UP là cách tốt để loại bỏ các dữ liệu vô dụng. Nó cho phép bạn loại bỏ các revision, bản nháp, bình luận, và nhiều thứ khác – tất cả chỉ thông qua một nút bấm.

WP-Optimize có thể được sử dụng để loại bỏ các revision cũ của bài viết, các bản nháp, các bình luận spam, các bình luận chưa được phê duyệt, các bình luận trong thùng rác, các tùy chọn transient, pingback, và trackback. Nó cũng bao gồm một trang hiển thị kích cỡ dữ liệu, kích cỡ index, và overhead, của từng bảng database.

Một plugin tối ưu hóa phổ biến khác là WP-DBManager. Nó là plugin đa tính năng cho phép bạn tối ưu hóa và sửa chữa database. Backup tự động website của bạn cũng có thể được tùy chỉnh.

WP-DBManager là một plugin chất lượng, nhưng từ quan điểm bảo mật tôi cho rằng cần sử dụng nó một cách cẩn thẩn, bởi vì plugin này cũng cho phép bạn xóa nội dung bảng (empty), loại bỏ bảng (drop) hoàn toàn và chạy các truy vấn MySQL. Vì lý do đó, bất kỳ ai có khả năng truy cập vào website của bạn sử dụng các phương thức độc hại có thể trở nên rất nguy hiểm.

Với những ai sử dụng ManageWP để quản trị website dạng multiple có thể tối ưu hóa database thông qua giao diện quản trị ManageWP.

Chú thích của người dịch: Ở thời điểm hiện tại tôi thấy phiên bản pro của plugin Advanced Database Cleaner có khả năng tốt nhất để thực hiện việc tối ưu hóa cơ sở dữ liệu một cách chuyên sâu. Một plugin khác rất nổi tiếng là WP-Optimize, nhưng dường như nó bị mất tập trung vào vấn đề tối ưu database, vì lan man sang cả những phần như tối ưu hóa ảnh và tạo cache, thành ra tôi không thích dùng.

E. 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í dụ về autoload

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
bật Object cache

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 (xem hướng dẫn sử dụng Algolia ở đây)

Đ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)

Tổng kết

Đây là điều mà tôi đã và đang làm trên các trang web WordPress của mình để giữ database của nó được tối ưu:

  • Tôi giảm số lượng các post revisions xuống hai bằng cách thêm define( ‘WP_POST_REVISIONS’, 2 ); vào wp-config.php
  • Tôi triển khai các biện pháp kiểm kê chống spam mạnh để giảm lượng lớn nội dung spam thêm vào database của tôi;
  • Tôi đánh giá kỹ càng bất kỳ item nào tôi muốn xóa và sau đó xóa chúng vĩnh viễn (thay vì để chúng trong thùng rác).

Tôi cũng thực hiện kiểm tra database của tôi định kỳ thông qua phpMyAdmin. Điều này cho phép tôi cơ hội phát hiện ra vấn đề để tối ưu hóa bảng database và loại bỏ bất cứ bảng database nào không sử dụng một cách kịp thời. Theo thời gian tôi cũng sử dụng các plugin tối ưu hóa, chẳng hạn như WP Clean Up. Điều này cho phép tôi loại bỏ các transients và bất kỳ dữ liệu nào khác đã không còn giá trị tích lũy theo thời gian.

Với một số trang WordPress, tôi thực hiện giảm số lượng ngày các dữ liệu được phép lưu trữ trong thùng rác từ mặc định là 30 xuống chỉ còn 5. Dù vậy, tôi thường không phải thực hiện bước này vì tôi có thói quen xóa một thành phần không sử dụng hoàn toàn.

Để giảm số lượng các lời gọi đến database, tôi cài plugin cache cho WordPress (LiteSpeed cache, WP-Rocket, Swift Performance). Điều này không làm giảm kích cỡ database của tôi, nhưng nó làm giảm sức ép lên máy chủ MySQL và đảm bảo các trang của tôi được tải nhanh chóng.

(Dịch từ bài viết Optimizing Your WordPress Database – A Complete Guide của WPMUdev, tác giả Kevin Muldoon)

Bonus của người dịch

Nếu bạn muốn loại bỏ toàn bộ rắc rối liên quan đến database, bạn có thể không sử dụng database nữa! Có cách để làm như vậy đó là sử dụng trang tĩnh hoãn toàn.

Plugin có thể làm điều đó có tên WP2Static, nó chuyển toàn bộ trang WordPress động của bạn thành HTML và các nội dung tĩnh đi kèm như CSS, JS và ảnh. Tất nhiên cái gì cũng có cái giá của nó, trang tĩnh hoàn toàn không phù hợp với tất cả kiểu trang, và bất cứ yếu tố động nào trên trang sẽ phải sử dụng dịch vụ của bên thứ ba. Hãy tham khảo link vừa dẫn để biết chi tiết.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *

four × 2 =