[Help] Cấu hình MySQL xử lý >= 50M records

chưa hiểu bạn muốn select như nào mà lại chậm

 

tốt nhất đừng count. Count với bất cứ cơ sở dữ liệu nào cũng sẽ lâu, đôi khi nhanh chỉ vì query được cache thôi. Select chỉ lấy tương đối rồi áng chừng còn records hay ko, ví dụ limit 40 nhưng nó trả về 39 là hết rồi.

 

Lập trình mà “áng chừng” là không ổn rồi. Còn đúng là phân trang thì không cần count nhưng count 40 nó trả về 40 thì làm sao biết đã hết hay chưa để show Next hay không? Nên giải pháp là nếu mỗi page show 40 rows thì hãy limit 41 rows, nếu trả đủ 41 thì vẫn chỉ show 40 nhưng mình biết là cần ít nhất 1 page nữa —> show Next còn ngược lại thì không show nữa.

 

dữ liệu của mình không nhất thiết phải chính xác nên đâu cần phải cứng nhắc vậy, mình cứ áng áng mà lấy ra thôi miễn là cảm thấy "phù hợp và chấp nhận được", còn nếu mình cần chia chính xác thì nên làm ngay từ đầu về để tối ưu tốc độ truy vấn và hiệu năng chứ ko phải chờ đến khi nó phình to mới tìm cách tối ưu

 

Bây giờ ví dụ nhé: làm 1 triệu tags, mỗi tag có 1 page riêng để show các data liên quan và các pages này đều phân trang. Câu hỏi đặt ra là:
- Nếu "áng chừng", bạn sẽ show ra bao nhiêu trang cho từng tags?
- Con số nào là "phù hợp và chấp nhận được" ? Vì sao lại chọn con số đó mà không phải con số khác?
- Trường hợp như mình đã nói - query limit 40 nó trả đủ 40 thì làm sao biết là còn hay hết records - để không show trang kế tiếp ra? Vì nếu lỡ mà show ra 1 trang trắng nhưng mình không biết trang đó không có data và vẫn hiện ads (AdSense) thì khả năng bị banned site là có (vì mình đã bị 1 lần trên 1 site kha khá traffic)

Trước giờ mình chỉ làm có 2 cách thôi:
- 1 là show đúng 1 page không paging (nếu thích thì làm ajax cho load more)
- 2 là đã paging thì phải đảm bảo paging cho đúng và hiện data chuẩn

Nên thật sự không hiểu cách "áng chừng" như bạn nói.

 

Tại sao ko làm chỉ có next và prev, khi next ta quẻy lấy start và limit, nếu như ko có sẽ redirect về trang trước đó,

 

Vậy thì có khác gì ajax load more hỡi người anh em thiện lành

 

Muốn ajax load more hay không load more thì có làm sao. Còn với cục data to như này mà di count rồi phân trang thì mình ko ý kiến gì nữa. Cám ơn.

 

Bác ấy chỉ count để thống kê chứ k phải phân trang bạn ơi. Bạn hiểu sai ý rồi. Chủ yếu là chậm quá nên muốn kiếm cách nhanh hơn ấy mà.

 

Ở trên mình đã nói là làm Next và prev rồi còn gì? Hoặc làm kiểu Ajax.
Nhưng bạn nói “áng chừng” mới thắc mắc chứ?

 

Còn thớt cũng nói là làm next prev chứ có nói count để paging đâu?

 

Cái chính là ko count.
Cách làm select 41 đưa vào bộ nhớ rồi từ bộ nhớ lấy ra 40 của money hay hơn của mình. Mặc dù xác suất trang trắng khá nhỏ 1/40 nhưng tránh hẳn trang trắng khỏi phải redirect vẫn hay hơn, công sức thì vẫn vậy, chỉ có 1 query.

 

Đó giờ chưa làm cách limit 41 mà show 40, nhưng rõ ràng cách này rất hay và tối ưu cho paging. Thanks anh Andy,

 

1. count(1) -> sẽ đọc qua tất cả các record nên sẽ rất lâu.
2. offset 9999 -> sẽ đọc đến record 9999 nên cũng sẽ rất lâu.

Vậy add thêm column "row_num" vào và index, giá trị tăng dần.
SELECT <fields> FROM <table> ORDER BY id DESC limit 10 offset 0;
-->
SELECT <fields> FROM <table> WHERE row_num > 500 and row_num < 550 ORDER BY id;

Lúc này câu query chỉ đọc 50 record thôi.

 

Nếu cột id bác có data kiểu vậy thì dùng luôn. Khỏi add

Ngoài ra thì select count(1) --> select max(id) luôn

 

schema ra sao bác?
Đang hiểu có table cat_pro có column (cat_it, pro_id) là KEY
Và query lấy ra 10 product trong cate nào đó.
Đoán là khi query [where cat_id = <cat_id>] ra quá nhiều record nên chậm
Nên vẫn theo cách trên là [where cat_id = <cat_id> and pro_id > 0 and pro_id < 10]
Lưu ý, pro_id lúc này data không tăng dần đc thì phải add column như trên