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 =))

npm install express --save && npm install mysql --save && npm install body-parser --save

Có vẻ dài quá nhỉ. Giải pháp khác:

npm install express mysql body-parser --save

Hoặc:

yarn add express mysql body-parser

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

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

ngon, vote phong cách viết bài =))

Theo mình thì các tính toán rất căn bản như lấy phần nguyên của 1 số ngôn ngữ nào cũng làm rất tốt, còn thực tế thì hãy test với 10 tỷ lần xem sao, tốc độ gần như giống nhau và chênh nhau k đáng kể, đều hết tầm 55 giây trên browser mình:

console.log('Please wait until you see the result ...');
var start = moment(new Date).format('x');
for(let i = 0; i<1E10; i++) {
	const a = Math.floor(6.98453);
}
var end = moment(new Date).format('x');
console.log('Total: ' + +(end - start)/1000 + 's');

vs

console.log('Please wait until you see the result ...');
var start = moment(new Date).format('x');
for(let i = 0; i<1E10; i++) {
	const a = ~~6.98453;
}
var end = moment(new Date).format('x');
console.log('Total: ' + +(end - start)/1000 + 's');

Thế nên mình khuyên mọi người nên tập trung vào high level code, focus vào mục đích code tươi sáng dễ đọc hơn là tối ưu cải thiện 1 chút ít hiệu suất thế này.