MYSQL BACKEND: Tối ưu hoá phân trang từ 7s còn 1s với Table có 10.000.000 dữ liệu, SẾP tăng lương...

Tham gia làm hội viên của kênh này để được hưởng đặc quyền:
/ @anonystick
👉 Link khóa học backend Go: • Course - Go Backend Ar...
👉 Link khóa học backend Nodejs: • Course - Node.js Backe...
👉 Link khóa học backend Java: / @anonystick
Timeline:
01:20 Tối ưu phân trang theo Google
03:10 Cú pháp phân trang MYSQL
12:07 Mẹo tạo INDEX dựa trên tiêu chí
14:30 Sau khi tối ưu 7s còn 1 s
🚩 Subscribe ➜ / tipsjavascript
#anonystick #mysql #backend
✅ Follow Me:
Blog: anonystick.com
Github: github.com/ano...
Facebook: / tipjs
KZbin: / tipsjavascript

[@vietthuan98]

Kỹ thuật phân trang mà anh ý chia sẻ ở cuối còn gọi là "Deferred joins". Mn tham khảo nhé.

[@user-nc6ho6dj3i]

Cảm ơn bạn nhé.

[@middmoon]

hồi học môn cơ sở dữ liệu giáo viên của mình đã nói rất nhiều về độ quan trọng cũng như hiệu quả của truy xuất lồng (subquery) thật đáng tiếc khi không chăm chỉ học tập tại thời điểm đó

Giảng quá đỉnh quá dễ hiểu, em FE mà nghe hiểu không cần dừng 👍

[@ngokhanhnguyen2276]

Quá hay a ơi, cám ơn a đã chia sẻ. Hôm nào làm 1 video về Chuẩn hóa dữ liệu (1NF, 2NF, 3NF, BCNF) đi anh!!

[@trihua5296]

Ủng hộ anh, tận tâm quá a ơi, chúc a nhiều sức khỏe ạ! ❤❤

[@nghiatranai4587]

Trước giờ trong đầu cứ chỉ tránh subquery k hề biết đến điều này. Cảm ơn a nhiều!!!

[@hien2914]

thật sự tuyệt vời , chúc a và gia đình sức khỏe .

[@quanledinh2239]

Trước e làm inner join rất nhiều nhưng ko ngờ inner join 1 primary key column lại tăng hiệu suất đến vậy

[@nhatminhnguyenquang7965]

Hay anh ạ, btw cái cách này nếu mn để ý thì nó cũng được handle trong cái framework orm điển hình như là typeorm, bữa em log query ra thấy nó handle y chang luôn ạ 😁

[@sunetala2957]

Quá đỉnh Admin ơi.

[@anonystick]

Tks em

[@vanhoangleton]

Tuyệt vời anh ơi 🎉🎉🎉

[@anonystick]

Cảm ơn em

[@ngocphucdo3757]

well done a ơi 🎉🎉🎉

[@tartaglia5724]

hay quá sếp

[@JackieKim2207]

cảm ơn anh vì kiến thức hữu ích

[@tritripro]

Cám ơn thầy, cực kì bổ ích ạ

[@devlife811]

Tuyệt vời ạ

[@tonacody4100]

Hay quá bác ơi

[@kduy10b8]

quá hay a ơi, rất thật tế

[@gaucoder]

rất hay và bổ ích luôn

[@minhthuanle1599]

Anh có thể làm video hướng dẫn setup project nodejs theo mô hình mvc sử dụng database oracle (cụ thể là plsql) + gói node-oracledb không ạ?

[@TungJohn123]

quá đỉnh a oi

[@tandat4619]

Tuyệt vời

[@tuanluong6316]

Cảm ơn anh, kiến thức quá hay

[@ziat1988]

Cho e hỏi là như vậy phải đánh index cho các thành phần trong where ạ? Nếu như trang có chức năng filter phức tạp thì như vậy phải đánh index cho rất nhiều cột. Như vậy có ok ko ạ?

[@kysomaio7207]

khá giống với "common table expression" anh nhỉ 😊😊

[@VanChinhBui-dc1nm]

cái này e tự mày dùng bừa ko ngờ cũng đúng công thức🤣

[@luuxuanthe3602]

Cảm ơn anh!

[@inhantrinh2402]

Dạ bên thầy có khoá học nào chuyên về mảng MySQL này không ạ

[@aw7258]

Nào ra 1 bài về CTE trong SQL a nhé

[@msnv3652]

tối ưu câu tính tổng sao anh? tks!

[@khoatrananh7372]

lúc em học, thầy cô cứ nói nên tránh việc dùng subquery vì nó sẽ ảnh hưởng tới perfornamce. Nhưng nay em có 1 góc nhìn khác về nó. Cảm ơn anh!!

[@finn2536]

Cái này đúng nha, dùng subquery ở FROM nó sẽ tạo ra một cái table tạm thời, cũng cần phải tốn MEM cho cái table này. Nếu size table tạm này lớn thì sẽ ảnh hưởng đến server.

[@vuduchong]

hay vãi, giờ e mới biết cái bảng tạm

[@pt.9e]

Hóng a share cách chạy câu query khác server như DBLink trong MSSQL trên MySQL :D

[@TamNguyen-dx2ly]

Cho em hỏi câu này với. Em đang thấy là cách làm đang tạo 1 table giả. vậy nếu như bài toán là có 5 table mà mỗi table có 1 trường sẽ được search(name, possition , salary ...). thì ở table giả sẽ phải join vao và thực hiện search ở đó phải không anh

[@sang-r3u]

Cảm ơn anh ạ ❤❤❤

[@yughiole7088]

Khóa chính thì nó đã tự động được đánh index rồi nha ae, nên select nó nhanh, sau đó join

[@phanhuyhoang3720]

Mình inner join nhưng không có index user id thì nó không phải quét full bảng hả bạn

[@leeshey99]

Video hay quá

[@thachvungoc4254]

thật ra có hơi khác 1 tí nhe, đáng lẽ phải để order by ở trong câu subquery chứ a nhỉ, sau đó câu select ngoài chỉ đơn thuần lấy join thôi anh

[@DoTienThuatQP]

Anh ơi, khoảng bao lâu nữa thì a xong khoá java spring

[@tuannguyenanh85]

quá dữ Ad ơi, mà Ad cho hỏi thêm là Ad sử dụng phần mềm chỉnh giọng nào thế? Xin cám ơn.

[@anonystick]

Giọng nguyên bản mà, có chỉnh gì đâu

[@yughiole7088]

@@anonystick 🤣🤣🤣

[@nhamnguyendinh1899]

❤❤ a có thể demo kỹ thuật này trong mongoose được k ạ, vì mongoose k có viết query rõ ràng như thế này

[@reoteuray9823]

logic thế này có đúng ko anh: giả sử bảng A có 10 record, và bảng temp kia có 7 record , thì lúc join nó sẽ phải scan cả 2 bảng, tổng phép scan là 10*7 , tức là để tạo ra bảng join tốn nhiều công sức tuy nhiên mặt lợi của pp trên là, chỉ tốn công ở công đoạn join, còn điều kiện where đã nằm ở phần tạo bảng temp, mà phần tạo bảng temp đã được index để rút tối ưu nên tuy công đoạn join là tốn công nhưng so với việc để nguyên bảng kia ko đánh index và scan 10 record , thì lại rút ngắn đc thời gian hơn

[@TheNguyendinhduy]

Em cảm ơn chia sẻ của anh. Anh cho em hỏi, em có 1 vẫn đề này, mong anh giải đáp ạ. Em có 1 cái table gần 1.5b, table có 28 trường, nhưng không có partition, thì mình có cách nào tối ưu không ạ? Em sử dụng MySQL

[@anonystick]

Vấn đề này thì nhiều khía cạnh. Dữ liệu truy cập thường xuyên hay không? Tối ưu ở đây là tối ưu về insert hay join hay single query... em pm Anh để nói thêm hen

[@TheNguyendinhduy]

@@anonystick Bảng có lượng insert khoảng 5 triệu records/ngày, và có join ạ, hiện tại thì em vẫn đang sử dụng limit và offset ạ, có index các trường thường query. Em join thêm 3 bảng ạ Bảng a: có 50 records Bảng b: có 150 records Bảng c: Có khoảng 10m records. Bảng a và b thì ít có insert, bảng c thì thường xuyên insert ạ. Hiện tại thì em đang query thì nó mất khoảng hơn 1 phút. Mong anh cho lời khuyên ạ.

[@khauvannam]

Thầy cho em hỏi, theo em biết khi mà select * và select 1 field thì đều tốn performance như nhau bởi vì đều kéo hết row từ page của sql, tại sao select usr_id lại nhanh hơn select * vậy ạ?

[@khauvannam]

À nếu như là pk_key có lẽ là đã đc đánh index tương đương với row_id rồi thầy nhỉ

[@n8_nguyenngocphu160]

a cho em hỏi tại sao truy vấn mỗi usr_id lại có tốc độ nhanh hơn truy vấn * ạ

[@anonystick]

Càng ít dữ liệu network thì càng nhanh... ví dụ em chuyển 6 đồ vật sẽ nặng hơn một đồ vật... Yên tâm anh sẽ nói thêm nhiều hơn về mysql đúng trọng tâm

[@n8_nguyenngocphu160]

​@@anonystickem vừa xem kĩ lại thì vì usr_id là PK, nó có index thế nên câu lệnh select chỉ làm trên index thôi(only scan index) thế nên nó rất nhanh.

[@mahung8041]

đúng là dù lấy * hay 1 trường thì time nó cũng same nhau thôi. do user_id có index nên time mới nhanh. phần này a có thể check lại.

[@phanlinh6742]

Phần này root cause ko liên quan nhiều đến việc transfer network mà bản chất là đánh index field usr_created_at_data thì index đã bao gồm PK là usr_id rồi. Vì thế câu trên sẽ dùng Index Scan Only. Nếu mem đủ lớn sẽ scan luôn trên mem, còn ko nó cũng chỉ scan trên index mà không cần lookup lại cây B-tree để lấy dữ liệu và order by toàn bộ dữ liệu.

[@vuhuuquocbao8260]

@@phanlinh6742 chỉ scan trên index mà ko cần lookup B-tree là sao anh, data structure của index chính là B-tree mà nên lúc nào scan index thì cũng phải lookup đến B-tree anh.

[@binshin]

nghe tiếng mưa và lập trình....

[@longshin4299]

Đối với câu query này e giảm xuống 0.02s! Không cần chia table gì cả

[@Meonoppo]

Ghi ra đi bạn

[@longshin4299]

@@Meonoppo #1 index( created_datetime, user_id). #2 dùng sub query+ semi join thay vì join. #3 tùy vào requirements và tần suất sử dụng query có thể triển khai thêm một số kỹ thuật paging như 1 dùng 1 câu query chia table thành nhiều page sẵn lưu vào mem cache. Mỗi page ở cache có thể lưu range cho khoảng 10k hoặc 100k records. Khi đó query sẽ tính toán và lấy page lớn đc tính toán lưu ở cache để giảm bớt đc số lượng records cần order ( order by max 10k). Đó là vd. Còn nhiều technique khác Bình thường application nhỏ chỉ cần apply #1 và #2 là ổn và đơn giản rồi.

[@AnhTuanHuynhVan]

@@longshin4299 bác ơi cho e xin câu query được không, em đã đánh index( created_datetime, user_id), mà mất tận 1.5s, cảm ơn bác nhiều

[@AnhTuanHuynhVan]

@@longshin4299 Bạn ơi mình đã đánh index ( created_datetime, user_id), dùng cả sub query+ semi join mà truy vấn vẫn mất 1s, bạn cho mình xin câu query của bạn nhe

[@VuTran-wy7xb]

vẫn đang đợi khoá java anh ơi

[@anonystick]

Khà khà... Em xem kỹ lại đi xem có bất ngờ gì ko??

[@ki3n203]

Bạn vô phần member thay đổi level là xem được khoá java

[@VuTran-wy7xb]

@@ki3n203 mình join hội viên đc 12 ngày có được không bạn nhỉ, mình vào mà không thay đổi level đc

[@VuTran-wy7xb]

à rồi, bạn nào bị giống mình thì làm bằng app điện thoại nha, trình duyệt web nó không hiện

[@vannguyenpham6809]

@@ki3n203 uây vậy hả, nâng cấp 50k/tháng là có khóa java. Mình chỉ đăng kí hội viên xem video chứ chưa thực hành được nhiều NodeJS vì làm Java. Hay quá ha :))

[@hungtrantv9891]

10 triệu tốn 1s , vậy 100 triệu records tốn 10s hả anh ?

[@TruongNguyen-f3i]

sao không select ra rồi where in đỡ phải join ạạ

[@thachvungoc4254]

theo mình biết thì where in sẽ làm mất tính thứ tự của câu sub query á

[@TruongNguyen-f3i]

@@thachvungoc4254 sub query có sort và query bên ngoài đều có sort thì đâu có vấn đề gì về kết quả đâu bạn nhỉnhỉ

[@TruongNguyen-f3i]

@@thachvungoc4254 có sort cả query sub và query bên ngoài rồi thì đâu có mất tính thứ tự gì đâu ạạ

[@cuonghoang7609]

Hay quá anh ơi