:cry: :cry:
xin chào mọi người
hiện tại mình đang có vướng mắc mong mọi người giúp đỡ.

trước đây mình có chạy một Mysql sever với 1 database duy nhất dung lượng khoảng 1,5G <1 forum> sử dụng bản mysql-3.0 thì mọi việc đều bình thường.Thời gian load cho 1 page trung bình 3-4 s <khá nhanh>
 

nhưng từ khi mình chuyển qua build bản mysql 5.0 thì trục trặc xảy ra.Trước hết là kô thể kết nối do code cũ ,may mà sửa nhanh chóng.Bây giờ thì xảy ra hiện tượng như mọi người gọi là cái cổ chai ấy.Mysql tốn rất nhiều tài nguyên CPU của hệ thống mà làm việc có vẻ ỳ ạch chứ kô nhanh chóng như trước.Việc duyệt web vì thế nên chậm đi hẳn ,mình đã thử khắc phục nhiều cách nhưng kô thay đổi nhiều.
 

tối ưu Mysql là một việc vô cùng khó khăn mà ít người nói đến,đâu chỉ là việc cp file my.cnf vào thư mục /etc và chạy mysql lên là ổn.Vì vậy mong mọi người những ai đã có nhiều kinh nghiệm về vấn đề này có thể chia sẻ với mọi người,đôi khi một câu nói cũng có thể tìm ra chân lý.
 

theo ý kiến chủ quan của mình thì mình muốn lắng nghe những kinh nghiệm của mọi người ,và nếu cần thì mình sẽ post cấu hình sever của mình lên <thực sự chưa muốn đưa lên để mọi người chỉnh giúp - nghe giống ăn sẵn quá ,kiểu click and see ...>

nếu vấn đề quá rộng thì chúng ta có thể thu hẹp lại <trong cấu hình sever mình chăng >

 

Một trang load có nhiều factor chớ không riêng gì CSDL. Bởi thế, nếu tính round-trip (thời gian load 1 trang) là tính tổng thể và không xác định cụ thể performance của CSDL được.

Nếu server hardware không thay đổi thì hiển nhiên vấn đề nằm ở code và cấu trúc của database.
Lý do đơn giản là vì tối ưu không chỉ nằm ở một khía cạnh nào đó mà nó trải dài ít nhất bốn khía cạnh quan trọng:

1. SQL query
2. SQL service
3. Operating System
4. Hardware

Trong 4 khía cạnh trên, nếu HW và OS không thay đổi thì chỉ còn có 2 điểm cần tập trung. Tuy nhiên cũng nên xét lại 3) và 4) nếu có thể.

Điểm bồ đề cập /etc/my.cnf chỉ là một khía cạnh của điểm 2). Theo tớ bồ, nên tập trung đến 1) ngay lúc này.

Có vài điểm tối quan trọng bồ cần xem:

- tránh query kiểu ambiguous như SELECT *. Tất cả các query phải cụ thể column và số column cần thiết. SELECT * hao tổn CPU một cách không cần thiết.

- tránh dùng sub-query khi có thể được.

- tránh dùng các logic và vòng lặp ngay trên CSDL. CSDL chỉ dùng để query những gì mình muốn query.

- nên tạo index cá biệt cho các column có liên quan đến những query thường xảy ra

- nên thường xuyên OPTIMIZE tables

- nên chú trọng 2 giá trị: table_cache và key_buffer_size trên cấu hình my.cnf. Giá trị cụ thể thế nào tùy thuộc vào tầng số sử dụng và kích thước của database.

- nên dùng connection pool để bảo tồn và điều hợp connection từ application đến CSDL. Tránh dùng "per connection" cho mỗi query.

- trên bình diện OS, nên build MySql theo dạng static link thay vì dynamic link vì chúng performance khác biệt thấy rõ.

Chi tiết thế nào thì phải đào sâu và phải cụ thể hơn.

Thân mến. 

ngoại trừ việc chỉnh lại code của web còn thì những điều khác em đều thực hiện đủ,Mysql build theo kiểu static .chỉ build những cái cần dùng đến,các thông số như max_connections hay cache và buffer được tính toán dựa trên thông số thưc tế <vừa chạy vừa sửa > .Tỷ lệ "hits" của cache và buffer là chấp nhận được .Tuy nhiên vấn đề gặp ra ở đây là 1 truy vấn mysql mất quá nhiều thời gian để thực hiện ,và chiếm quá nhiều CPU thông thường là 80 %.Trong các tập tin error log kô có thông tin gì cả,như vậy là sever chạy KÔ CÓ LỐI gì cả ??mọi thứ diễn ra bình thừong ngọa trừ việc chậm như rùa bò ....  

Ặc ặc, bồ dùng bản Alpha 5.2 của MySql cho một server có đòi hỏi: về thực tế nhiệm vụ của em là đảm bảo sever up time 24/24? Nên cẩn thận với quyết định trên.

Có thể chính MySql 5.0 có vấn đề nhưng quyết định thẳng lên 5.2 (qua mặt luôn bản Beta) thì....

Good luck ).

PS: server của bồ chạy single CPU hay multiple CPU? Bồ có dùng sub-query không? nếu có, dùng nhiều hay ít? Bồ đưa lên một vài dòng SQL bồ dùng sub query được không?