MySQL ALTER TABLE trên bảng rất lớn - có an toàn để chạy không?

Question

Tôi có một cơ sở dữ liệu MySQL với một bảng MyISAM với 4 triệu hàng. Tôi cập nhật bảng này khoảng một lần một tuần với khoảng 2000 hàng mới. Sau khi cập nhật, tôi sau đó thay đổi bảng như sau:

ALTER TABLE x ORDER BY PK DESC 

Tôi sắp xếp bảng theo trường khóa chính theo thứ tự giảm dần. Điều này đã không cho tôi bất kỳ vấn đề gì về máy phát triển của tôi (Windows với bộ nhớ 3GB). Ba lần tôi đã thử nó thành công trên máy chủ Linux sản xuất (với RAM 512MB - và đạt được bảng xếp hạng kết quả trong khoảng 6 phút mỗi lần), lần cuối tôi thử nó, tôi phải dừng truy vấn sau khoảng 30 phút và xây dựng lại cơ sở dữ liệu từ một bản sao lưu.

Máy chủ 512MB có thể đối phó với tuyên bố thay đổi đó trên bảng lớn như vậy không? Tôi đã đọc rằng một bảng tạm thời được tạo ra để thực hiện lệnh ALTER TABLE.

Câu hỏi: Lệnh này có thể được chạy an toàn không? Điều gì sẽ là thời gian dự kiến ​​cho sự thay đổi của bảng?

Answer 1

Tôi có thể tạo Chế độ xem thay vì được sắp xếp theo giá trị PK, để cho một thứ bạn không cần phải khóa bảng lớn đó trong khi ALTER đang được thực hiện.

Answer 2

Như tôi vừa đọc, truy vấn ALTER TABLE ... ORDER BY ... hữu ích để cải thiện hiệu suất trong một số trường hợp nhất định. Tôi ngạc nhiên rằng chỉ số PK không giúp gì cho điều này. Tuy nhiên, từ the MySQL docs, có vẻ như InnoDB hiện sử dụng chỉ mục. Tuy nhiên InnoDB có xu hướng chậm hơn như MyISAM. Điều đó nói rằng, với InnoDB bạn sẽ không cần phải sắp xếp lại bảng nhưng bạn sẽ mất tốc độ rực rỡ của MyISAM. Nó vẫn có thể đáng để bắn.

Cách bạn giải thích các sự cố, có vẻ như có quá nhiều dữ liệu được tải vào bộ nhớ (có thể thậm chí có sự hoán đổi đang xảy ra?). Bạn có thể dễ dàng kiểm tra xem có sử dụng bộ nhớ của mình hay không. Thật khó để nói như tôi không biết MySQL tất cả những gì tốt.

Mặt khác, tôi nghĩ vấn đề của bạn nằm ở một nơi rất khác: Bạn đang sử dụng một máy chỉ có 512 Megabyte RAM làm máy chủ Cơ sở dữ liệu với một bảng chứa nhiều hơn 4Mio hàng ... Và bạn đang thực hiện hoạt động rất nhiều bộ nhớ trên toàn bộ bảng trên máy đó. Dường như 512Megs sẽ không gần như đủ cho điều đó.

Một vấn đề cơ bản hơn tôi thấy ở đây: Bạn đang phát triển (và có khả năng thử nghiệm tốt) trong môi trường rất khác với môi trường sản xuất. Các loại vấn đề bạn đang giải thích là để được mong đợi. Máy phát triển của bạn có bộ nhớ gấp 6 lần so với máy sản xuất của bạn. Tôi tin rằng tôi có thể nói một cách an toàn, bộ vi xử lý cũng nhanh hơn nhiều. Trong trường hợp đó, tôi đề nghị bạn tạo một máy ảo bắt chước trang web sản xuất của bạn. Bằng cách đó bạn có thể dễ dàng kiểm tra dự án của mình mà không làm gián đoạn trang web sản xuất.

Answer 3

Điều bạn đang yêu cầu làm là xây dựng lại toàn bộ bảng và tất cả các chỉ mục của bảng; đây là một hoạt động tốn kém đặc biệt nếu dữ liệu không phù hợp với ram. Nó sẽ hoàn thành, nhưng nó sẽ chậm hơn rất nhiều nếu dữ liệu không phù hợp với ram, đặc biệt nếu bạn có nhiều chỉ mục.

Tôi đặt câu hỏi về phán đoán của bạn khi chọn chạy máy có bộ nhớ nhỏ như vậy trong quá trình sản xuất. Dù sao:

• Đây có phải là ALTER TABLE thực sự cần thiết hay không; truy vấn cụ thể nào bạn đang cố gắng tăng tốc và bạn đã thử nó chưa?
• Bạn đã cân nhắc làm cho máy phát triển của mình giống sản xuất hơn?Tôi có nghĩa là, bằng cách sử dụng một hộp dev với bộ nhớ MORE là không bao giờ là một ý tưởng tốt, và sử dụng một hệ điều hành khác nhau chắc chắn không phải là một trong hai.

Có thể bạn cũng có thể thực hiện một số điều chỉnh để cố gắng trợ giúp; nó phần lớn phụ thuộc vào lược đồ của bạn (các chỉ mục cụ thể). 4M hàng không phải là rất nhiều (đối với một máy có số lượng ram bình thường).

Answer 4

Nếu bạn đang sử dụng InnoDB, bạn không cần phải thực hiện rõ ràng ORDER BY hoặc sau khi chèn hoặc tại thời điểm truy vấn. Theo hướng dẫn MySQL 5.0, InnoDB đã mặc định để đặt hàng khóa chính cho kết quả truy vấn:

http://dev.mysql.com/doc/refman/5.0/en/alter-table.html#id4052480

bảng MyISAM trả lại hồ sơ để chèn theo mặc định, thay vào đó, có thể làm việc tốt nếu bạn chỉ từng gắn liền với các bảng, thay vì sử dụng truy vấn UPDATE để sửa đổi bất kỳ hàng nào tại chỗ.

Answer 5

là khóa chính auto_increment? nếu vậy, sau đó làm ALTER TABLE ... ORDER BY sẽ không cải thiện bất cứ điều gì vì mọi thứ sẽ được chèn vào theo thứ tự anyway.

(trừ khi bạn có nhiều lần xóa)