Mình cũng có cảm giác giống bac Đình Danh. Thuật toán ban đầu vốn là bug lớn khi cứ F5 thì đếm, và qua bài này thì chúng ta vá lỗi đó bằng cách thêm Session & midd .
Code rất chân phương dễ hiểu. tks bạn.
TH1: Mình công nhận nếu tổng số bản ghi của bảng là 16000 và số trang >= ~ 8000 thì kết quả sẽ tốt hơn. page 500 vần phải quét nhiều hơn vì chưa quá nửa các bản ghi. Nói chung sau khi lấy qua nửa bảng, page càng lớn thì càng tốt (với điều kiện DESC record)
Các TH2 và TH3 có tốt hơn nhưng mình nghĩ nó khá giống TH1
Mình có thắc mắc, tại sao khi nó lấy đủ bản ghi rồi mà nó không dừng lại thôi, nếu nó dừng lại thì kết quả của việc bỏ offset luôn luôn nhanh hơn.
Cũng có thể phiên bản mysql nâng cấp sau này đã thay đổi và mình cũng đã đọc bài viết này trong cuốn "high performance mysql" nhưng vẫn chưa đả thông được kinh mạch ở vấn đề này =))
Hi bạn @mrrobot,
Trong trường hợp này do câu query của bạn không có WHERE "khác" và page khá thấp (page 2) nên bạn cảm thấy vậy.
Bạn thử giúp mình một số trường hợp sau xem kết quả có khác không nhé:
Giả sử table bạn có 16000 (ID từ 1-16000) bản ghi, mỗi page có 20 items => ~800 page.
TH1: tăng page lên page thứ 501
SELECT * FROM sakila.rental ORDER BY rental_id DESC OFFSET 1000 LIMIT 20
VS
SELECT * FROM sakila.rental WHERE rental_id < 600 ORDER BY rental_id DESC LIMIT 20
TH2: thêm WHERE conditions
SELECT * FROM sakila.rental WHERE staff_id = 1 ORDER BY rental_id DESC OFFSET 20 LIMIT 20
VS
SELECT * FROM sakila.rental WHERE staff_id = 1 AND rental_id < 16030 ORDER BY rental_id DESC LIMIT 20
TH3: remix
SELECT * FROM sakila.rental WHERE staff_id = 1 ORDER BY rental_id DESC OFFSET 1000 LIMIT 20
VS
SELECT * FROM sakila.rental WHERE staff_id = 1 AND rental_id < 600 ORDER BY rental_id DESC LIMIT 20
THẢO LUẬN
)))
Thanks
@NguyenThaiSon Great!
"@kiendinang Nốt anh êy! https://tamsudev.com (có vẻ khó hơn rồi (giggle))" trí tuệ nhân tạo đi lừa trí tuệ nhân tạo
bài viết tâm huyết (y)
Học trò ruột cô Thu đây rồi
còn thiếu nhiều lắm. CSS3 SASS jQuery Boostrap 3 snippet Icon Fonts SFTP ALL autocomplice Sublimelinter- js,php.... HTML5 HTML-CSS-Js Pretty....
Cảm ơn Kim đã góp ý nhá!
Good job! Mình nghĩ cho cái link dẫn tới phần 1 lên đầu bài viết thì sẽ hợp lý hơn =))
Có vẻ dài quá nhỉ. Giải pháp khác:
Hoặc:
tớ hay cài như này
npm i express mysql body-parser --save
Mình cũng có cảm giác giống bac Đình Danh. Thuật toán ban đầu vốn là bug lớn khi cứ F5 thì đếm, và qua bài này thì chúng ta vá lỗi đó bằng cách thêm Session & midd . Code rất chân phương dễ hiểu. tks bạn.
TH1: Mình công nhận nếu tổng số bản ghi của bảng là 16000 và số trang >= ~ 8000 thì kết quả sẽ tốt hơn. page 500 vần phải quét nhiều hơn vì chưa quá nửa các bản ghi. Nói chung sau khi lấy qua nửa bảng, page càng lớn thì càng tốt (với điều kiện DESC record) Các TH2 và TH3 có tốt hơn nhưng mình nghĩ nó khá giống TH1 Mình có thắc mắc, tại sao khi nó lấy đủ bản ghi rồi mà nó không dừng lại thôi, nếu nó dừng lại thì kết quả của việc bỏ offset luôn luôn nhanh hơn. Cũng có thể phiên bản mysql nâng cấp sau này đã thay đổi và mình cũng đã đọc bài viết này trong cuốn "high performance mysql" nhưng vẫn chưa đả thông được kinh mạch ở vấn đề này =))
Chuẩn rùi bạn )
Hi vọng sẽ được trao đổi chia sẻ kiến thức với bạn. Cảm ơn bạn
@bs90 em xin dừng cuộc chơi tại đây (okay)
hỗ trợ cả export csv,pdf,excel...mình dùng cái này làm backend max khỏe
@kiendinang Nốt anh êy! https://tamsudev.com (có vẻ khó hơn rồi (giggle))
Hi bạn @mrrobot, Trong trường hợp này do câu query của bạn không có WHERE "khác" và page khá thấp (page 2) nên bạn cảm thấy vậy. Bạn thử giúp mình một số trường hợp sau xem kết quả có khác không nhé:
Giả sử table bạn có
16000
(ID từ 1-16000) bản ghi, mỗi page có 20 items => ~800 page.TH1: tăng page lên page thứ 501
VS
TH2: thêm WHERE conditions
VS
TH3: remix
VS
ngon, vote phong cách viết bài =))