Phần đầu tiên của câu trả lời là tin tốt ... rằng mysqlcheck -o không có nhiều khả năng gây hại cho cơ sở dữ liệu của bạn hơn là chạy OPTIMIZE TABLE trên mọi bàn, bởi vì đó là tất cả những gì nó làm. Đó là một tiện ích thuận tiện đăng nhập vào máy chủ, tìm nạp danh sách các bảng và lặp lại chúng, gửi một OPTIMIZE TABLE truy vấn tới máy chủ cho từng bảng một cho đến khi hoàn tất.
Bây giờ, một số tin xấu. Nếu bạn có lỗi tiềm ẩn trong không gian bảng của mình, hãy OPTIMIZE TABLE có thể gặp phải nó, vì vậy bạn nên chắc chắn rằng bạn đã chuẩn bị cho khả năng đó, với các bản sao lưu và kế hoạch khôi phục. Cơ hội của điều này là khá xa vời, nhưng nó là một kết quả có thể xảy ra.
Tin xấu hơn:gần như chắc chắn là trồng nhầm cây.
Chạy Apache và MySQL cùng nhau trên cùng một máy có lưu lượng truy cập đáng kể - hoặc sự thay đổi lưu lượng truy cập đáng kể - là chống lại các phương pháp hay nhất và là công thức cho các vấn đề, bởi vì cả hai dịch vụ đều có xu hướng tăng mức tiêu thụ bộ nhớ khi tải và nếu cơ sở dữ liệu là nền tảng lưu trữ dữ liệu trang web, khi đó tải tăng lên có xu hướng xảy ra trên cả hai dịch vụ cùng một lúc.
Xem câu trả lời của tôi cho InnoDB Crash Post Mortem trên Stack Exchange quản trị viên cơ sở dữ liệu và Tại sao Apache hoạt động hoang dã và giết MySQL trên Lỗi máy chủ để bao quát kỹ lưỡng vấn đề khá phổ biến này, trong đó MySQL là nạn nhân, hơn bất cứ điều gì.
Lưu ý rằng bạn có đang sử dụng InnoDB hay không không quan trọng. Các mục khôi phục cơ sở dữ liệu trong nhật ký lỗi MySQL sẽ hơi khác một chút, nhưng phần quà đã chết là thế này:trước đó không có gì đáng ngờ cả, nhật ký lỗi MySQL cho biết:
mysqld_safe Number of processes running now: 0
Các thông báo sau đó thường bị hiểu sai là MySQL "gặp sự cố", nhưng đó không phải là những gì đang xảy ra ... Nó đã bị giết. MySQL thậm chí có thể từ chối khởi động lại, cho đến khi Apache bình tĩnh trở lại hoặc được khởi động lại hoặc máy chủ được khởi động lại. Một lần nữa, từ nhật ký lỗi, bạn có thể có hoặc không thể thấy thêm thông tin như sau:
InnoDB: Initializing buffer pool, size = 4.0G
InnoDB: mmap(4395630592 bytes) failed; errno 12
InnoDB: Completed initialization of buffer pool
InnoDB: Fatal error: cannot allocate memory for the buffer pool
[ERROR] Aborting
[Note] /usr/libexec/mysqld: Shutdown complete
mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Kiểm tra /var/log/syslog hoặc /var/log/messages (tùy thuộc vào bản phân phối bạn chạy) sẽ cho bạn thấy vấn đề thực sự.
$ sudo egrep 'kernel|oom' /var/log/syslog
... hoặc tin nhắn ... sẽ tiết lộ một số mục nhập bắt đầu như sau:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache bị đói bộ nhớ đến nỗi hệ thống có nguy cơ mất ổn định tổng thể, vì vậy "thứ gì đó" sẽ bị hy sinh. "Cái gì đó" có thể là daemon Máy chủ MySQL, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL thường sẽ cố gắng tự khởi động lại, và đối với tất cả những gì bạn biết, điều này đôi khi cũng có thể xảy ra ... nhưng trừ khi nhu cầu bộ nhớ của Apache giảm nhanh chóng, MySQL sẽ không được phép yêu cầu đủ bộ nhớ từ hệ thống, và sẽ bỏ cuộc.
Việc tối ưu hóa bảng có các ứng dụng hợp lệ ... nhưng, trong trường hợp này, nếu tôi đã xác định chính xác vấn đề của bạn, thì việc sắp xếp lại ghế trên boong tàu Titanic. Nó có thể giúp bạn tiết kiệm một số dung lượng đĩa, nhưng nó cũng sẽ khiến bạn tốn một số dung lượng đĩa dự phòng khi chạy vì một số công cụ lưu trữ tạo một bản sao hoàn toàn mới của bảng, sau đó đổi tên bản sao và xóa bảng cũ. Trong bất kỳ trường hợp nào, nó không có bất kỳ tác động đáng kể nào đến việc tiêu thụ bộ nhớ.
