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...

[@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é.

[@ThangPhan-q3u]

Cảm ơn bạn nhé.

[@baonguyen3543]

nếu ai làm Laravel nhiều sẽ dùng cách khá nhiều, nhưng cảm ơn anh vì video bổ ích.

[@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 đó

[@jackiedo7370]

Truy xuất lồng hổ trợ cho logic query phức tạp. Nếu có thể dùng join thì hãy dùng join, gần như là nhanh hơn so với subquery ở mọi case

[@nakhoayoutube]

Em là dev thiên về NoSQL, nhưng sau khi xem video này của anh, em thấy rất hay.

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

[@haituan8258]

em vừa vào 1 project được mấy tháng, dữ liệu cũng khá lớp, mấy síp cũng dùng cách này nhưng lúc e đọc code lại thắc mắc k biết tại sao. giờ xem được video này e mới biết được lý do. cảm ơn anh đã lên video này

[@levaighetscode6173]

Dạ video hay quá ạ cảm ơn anh đã chia sẻ kiến thức này ạ

[@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!!!

[@trihua5296]

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

[@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!!

[@hien2914]

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

[@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 ạ 😁

[@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

Vãi mưa lãn mạn. Anh em đúng đỉnh. Lúc nào nghe giọng anh chai cũng cười khúc khích. Video hay quá anh ạ

[@anonystick]

Thẳng quỷ sứ... Lo đám đi cha...

@@anonystick Em cưới xong òi =))

[@JackieKim2207]

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

[@tritripro]

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

[@Thinhkk0]

Quá hay a ơi. ❤❤❤❤

[@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 ạ?

[@kduy10b8]

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

[@tuanluong6316]

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

[@gaucoder]

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

[@kysomaio7207]

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

[@sunetala2957]

Quá đỉnh Admin ơi.

[@anonystick]

Tks em

[@tandat4619]

Tuyệt vời

[@ngocphucdo3757]

well done a ơi 🎉🎉🎉

[@devlife811]

Tuyệt vời ạ

[@vanhoangleton]

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

[@anonystick]

Cảm ơn em

[@TungJohn123]

quá đỉnh a oi

hay. cám ơn sư huynh!

[@VanChinhBui-dc1nm]

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

[@pt.9e]

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

[@vuduchong]

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

[@buituandung4554]

hay quá anh

[@luuxuanthe3602]

Cảm ơn anh!

[@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.

[@cuonghoang7609]

Hay quá anh ơi

[@aw7258]

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

[@tartaglia5724]

hay quá sếp

[@inhantrinh2402]

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

[@yughiole7088]

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

[@sang-r3u]

Cảm ơn anh ạ ❤❤❤

[@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

[@leeshey99]

Video hay quá

[@NghiaNguyen-fi7bw]

nhưng kết hợp với partition hiệu suất lại kém đi

[@msnv3652]

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

[@onembes]

Với bài toán phân trang nhưng cần phải thao tác với 4-5 bảng lớn thì sao ạ

[@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

[@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

[@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 🤣🤣🤣

[@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 ạ?

[@quocanhvu4301]

1 Index được nhiều cột mà bạn, mà phải sắp xếp thứ tự các cột cho đúng nữa nha bạn

[@DoTienThuatQP]

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

[@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 ạ.

[@quocanhvu4301]

Cách này chỉ tốt khi mà lấy phân trang từ tầm 1 triệu bản ghi trở đi thôi phải không ạ vì thời gian join không đáng kể so với thời gian quét tới 1 triệu ghi trở đi, mà lại sử dụng được cái unique key sẽ nhanh hơn là dùng index, nếu như bản ghi của em chỉ tầm 10k bản ghi thì đánh index là hiệu quả rồi phải không chứ join vào khá tốn hiệu năng ạ.

[@anonystick]

Video là 10 triệu..

[@quocanhvu4301]

@@anonystick em đang phân tích xem em có hiểu đúng ko ấy ạ :(( em sợ em ko hiểu đúng trường hợp nào cũng áp dụng như này thì toang á anh 😥

[@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

[@Nam_704]

bắn tim chiu chiu

[@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

[@onembes]

a đã giải quyết đc vấn đề này chưa a

[@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ỉ

[@jackiedo7370]

Select * và select 1 field sao performance như nhau đc😂

[@khauvannam]

@@jackiedo7370 bác giải thích giúp em tại sao lại khác nhau với ạ? Theo em biết là những row base database khi select 1 field thì nó đã select all trước đó r

[@jackiedo7370]

@@khauvannam hình như bạn hổng kiến thức căn bản về database rồi, bạn học lại cái truy vấn, cách index lưu và truy vấn data đi

[@khauvannam]

@@jackiedo7370 em học trên mạng thoi bác ơi, bác giải thích giúp em được không.

[@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

[@onembes]

@@longshin4299 cho e hỏi là với bài toán pagination, filter cần thao tác với 4-5 bảng lớn (tầm 50m records) để ra đc kết quả cuối cùng. E xin phương án tối ưu cho bài toán này ạ

[@binshin]

nghe tiếng mưa và lập trì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.

[@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 :))

[@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 ạạ

[@hungtrantv9891]

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

[@jackiedo7370]

Tùy vào tính unique của index bạn ơi. Dùng Bi-Index nên tốc độ là Logarit 2. Không phải là cấp số cộng

[@tonacody4100]

Hay quá bác ơi