Cách an toàn nhất để xóa hàng loạt sửa đổi bài

Một trong những khách hàng của tôi đang ở trên một blog khá lớn về số lượng bài đăng và lưu lượng truy cập. Tôi đang cố gắng đưa cơ sở dữ liệu của mình xuống một kích thước có thể quản lý được, và một điều khiến nó tăng lên theo nghĩa đen là hàng chục ngàn bản sửa đổi.

Tôi đã đặt cấu hình Wordpress để giới hạn số lần sửa đổi trong tương lai thành hai:

define('WP_POST_REVISIONS', 2);

Nhưng tôi muốn xóa tất cả các sửa đổi hiện có.

Câu hỏi 1 : Có an toàn khi xóa trực tiếp tất cả các hàng trong bảng wp_posts có post_type sửa đổi không? (Tôi đã thấy những câu trả lời mâu thuẫn trên chiếc máy này nhưng tôi rất thích có thể làm theo cách này nếu nó an toàn).

Câu hỏi 2 : Câu hỏi và điều này chỉ liên quan nếu tôi KHÔNG nên thực hiện xóa đơn giản từ câu hỏi thứ nhất:

Tôi đã tìm thấy câu trả lời này trong đó songdogtech cung cấp truy vấn cơ sở dữ liệu để xóa một cách an toàn, nhưng (1) nó đặc biệt để trả lời cho một câu hỏi nhiều trang (đây là một trang web) và (2) Tôi vừa nâng cấp trang web lên 3.6, bao gồm các thay đổi cơ sở dữ liệu . (Vì vậy, tôi không đủ kỹ năng đọc các truy vấn cơ sở dữ liệu để biết chính xác những gì đang diễn ra ở đó và liệu nó có hoạt động cho một trang web trong WP 3.6 không

Có an toàn không khi xóa trực tiếp tất cả các hàng trong bảng wp_posts có post_type sửa đổi? (Tôi đã thấy những câu trả lời mâu thuẫn trên chiếc máy này nhưng tôi rất thích có thể làm theo cách này nếu nó an toàn)

An toàn, an toàn .

Nếu chỉ có một người dùng (bạn) có thể chỉnh sửa bài đăng trên trang thì nó an toàn và không gây ra bất kỳ vấn đề nào khác.

Nếu có nhiều người dùng hơn và một người đang chỉnh sửa một bài đăng và trong khi đó bạn xóa các bản sửa đổi thì nó vẫn không an toàn, nhưng có thể gây khó chịu cho người dùng khi thấy các bản sửa đổi biến mất.

Điều hoàn toàn không an toàn là chạy truy vấn SQL trên cơ sở dữ liệu WP mà không cần lấy một (hoặc tốt hơn, nhiều hơn) các bản sao lưu giá cả phải chăng và kiểm tra truy vấn trên môi trường local / dev trước đó.

Hãy tưởng tượng bạn vô tình gõ 'bài' thay vì 'sửa đổi' , nếu bạn không có bản sao lưu và bạn chạy truy vấn trên trang sản xuất, điều gì xảy ra?

Về câu hỏi thứ hai, chỉ cần xóa {id}_ở khắp mọi nơi nó xuất hiện trong truy vấn gửi để wp_{id}_poststrở thành wp_postsvà vân vân.

Một cảnh báo , wp_một phần là tiền tố bảng tiêu chuẩn, những kẻ lạnh lùng thay đổi thành thứ gì đó khác trong quá trình cài đặt WP.

Nếu bạn đã thay đổi nó và trong wp_config.phpbạn thấy$table_prefix = 'something_else_than_wp_';

Truy vấn của bạn trở thành:

DELETE a,b,c
FROM something_else_than_wp_posts a
LEFT JOIN something_else_than_wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN something_else_than_wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

Tôi đề nghị tiến hành như thế này:

1. Sao lưu cơ sở dữ liệu
2. Sao lưu lại cơ sở dữ liệu
3. Kiểm tra sao lưu bằng cách khôi phục cơ sở dữ liệu trong cơ sở dữ liệu khác
4. Thay đổi 'wp_config' của bạn để sử dụng cơ sở dữ liệu mới này
5. Chạy truy vấn trên cơ sở dữ liệu mới và kiểm tra xem có lỗi gì không
6. Nếu không, bạn đã hoàn thành. Nếu vậy, hãy thay đổi 'wp_config' một lần nữa để nó sử dụng cơ sở dữ liệu cũ và thử điều tra vấn đề.

Các chi tiết được cung cấp cho đến nay vẫn chưa đầy đủ và truy vấn a, b, c không tốt - thậm chí có thể nguy hiểm. Nó quên yếu tố trong rất nhiều phụ thuộc tiềm năng. Có một cuộc thảo luận đầy đủ và các truy vấn tốt hơn ở đây

Ngoài ra còn có phiên bản sửa đổi của truy vấn này sẽ tốt hơn nhiều, nhưng thử nghiệm trong môi trường phát triển và sao lưu rủi ro thấp:

Đặc biệt:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON ( a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON ( a.ID = c.post_id )
LEFT JOIN wp_term_taxonomy d ON ( b.term_taxonomy_id = d.term_taxonomy_id)
WHERE a.post_type = 'revision'
AND d.taxonomy != 'link_category';

Truy vấn này xử lý dữ liệu cũ hơn trong đó WordPress có thể đang sử dụng cùng một object_id trong bảng wp_term_relationships cho cả bài đăng và liên kết. Bằng cách chạy các phiên bản khác của truy vấn a, b, c này, bạn cũng có thể vô tình xóa dữ liệu liên kết. Đây không phải là vấn đề với các bản cài đặt mới hơn của WordPress.

Nếu bạn chạy phiên bản truy vấn đó và nhận được 0 lần xóa, điều đó chỉ có nghĩa là bạn không có mục 'link_carget' trong bảng wp_term_taxonomy của mình. Bạn có thể xác minh bằng cách kiểm tra bảng đó, sau đó chỉ cần xóa dòng cuối cùng đó và chạy lại truy vấn.

Nhưng hãy chắc chắn rằng bạn sao lưu, kiểm tra và xác minh kết quả trước khi sử dụng trên dữ liệu sản xuất. Truy vấn này đã lấy một trong bảng wp_posts sửa đổi của tôi từ 300 MB xuống còn 5 MB sau khi tối ưu hóa.

Chạy truy vấn SQL:

DELETE FROM wp_posts WHERE post_type = "revision" // for "wptest" DB, note the table name

LƯU Ý: Truy vấn trên chỉ xóa bài được đánh dấu là sửa đổi. Nếu vì lý do nào đó, bạn đã liên kết bản sửa đổi với thẻ hoặc danh mục đã bị xóa khi bài đăng cuối cùng được xuất bản, bạn sẽ có thêm các mục trong các bảng khác, chẳng hạn như. Truy vấn thích hợp để xóa an toàn tất cả các sửa đổi của bạn như sau (thay đổi tiền tố bảng nếu cần):

DELETE a,b,c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = 'revision'