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 đó
18 วันที่ผ่านมา +3
Giảng quá đỉnh quá dễ hiểu, em FE mà nghe hiểu không cần dừng 👍
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 ạ 😁
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.
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
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
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
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
@@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 ạ.
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 ạ?
@@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.
@@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
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.
@@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.
@@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 :))
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 👍
Kỹ thuật phân trang mà anh ý chia sẻ ở cuối còn gọi là "Deferred joins". Mn tham khảo nhé.
Cảm ơn bạn nhé.
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!!!
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!!
Ủng hộ anh, tận tâm quá a ơi, chúc a nhiều sức khỏe ạ! ❤❤
thật sự tuyệt vời , chúc a và gia đình sức khỏe .
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
hay quá sếp
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 ạ 😁
Quá đỉnh Admin ơi.
Tks em
cảm ơn anh vì kiến thức hữu ích
Cám ơn thầy, cực kì bổ ích ạ
Tuyệt vời anh ơi 🎉🎉🎉
Cảm ơn em
rất hay và bổ ích luôn
quá hay a ơi, rất thật tế
Tuyệt vời ạ
well done a ơi 🎉🎉🎉
Hay quá bác ơi
Tuyệt vời
Cảm ơn anh, kiến thức quá hay
quá đỉnh a oi
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 ạ?
cái này e tự mày dùng bừa ko ngờ cũng đúng công thức🤣
khá giống với "common table expression" anh nhỉ 😊😊
Cảm ơn anh!
Dạ bên thầy có khoá học nào chuyên về mảng MySQL này không ạ
hay vãi, giờ e mới biết cái bảng tạm
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!!
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.
Cảm ơn anh ạ ❤❤❤
Nào ra 1 bài về CTE trong SQL a nhé
tối ưu câu tính tổng sao anh? tks!
Hóng a share cách chạy câu query khác server như DBLink trong MSSQL trên MySQL :D
Video hay quá
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
Khóa chính thì nó đã tự động được đánh index rồi nha ae, nên select nó nhanh, sau đó join
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
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
Anh ơi, khoảng bao lâu nữa thì a xong khoá java spring
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.
Giọng nguyên bản mà, có chỉnh gì đâu
@@anonystick 🤣🤣🤣
❤❤ 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
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
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
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
@@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 ạ.
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 ạ?
À nếu như là pk_key có lẽ là đã đc đánh index tương đương với row_id rồi thầy nhỉ
nghe tiếng mưa và lập trình....
Đối với câu query này e giảm xuống 0.02s! Không cần chia table gì cả
Ghi ra đi bạn
@@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.
@@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
@@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
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 * ạ
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
@@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.
đú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.
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.
@@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.
vẫn đang đợi khoá java anh ơi
Khà khà... Em xem kỹ lại đi xem có bất ngờ gì ko??
Bạn vô phần member thay đổi level là xem được khoá java
@@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
à 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
@@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 :))
sao không select ra rồi where in đỡ phải join ạạ
theo mình biết thì where in sẽ làm mất tính thứ tự của câu sub query á
@@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ỉ
@@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 ạạ
10 triệu tốn 1s , vậy 100 triệu records tốn 10s hả anh ?
Hay quá anh ơi