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...
HTML-код
- Опубликовано: 7 янв 2025
- 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
RUclips: / tipsjavascript
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 đó
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é.
Giảng quá đỉnh quá dễ hiểu, em FE mà nghe hiểu không cần dừng 👍
Em là dev thiên về NoSQL, nhưng sau khi xem video này của anh, em thấy rất hay.
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.
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 ạ
Thẳng quỷ sứ... Lo đám đi cha...
@@anonystick Em cưới xong òi =))
Dạ video hay quá ạ cảm ơn anh đã chia sẻ kiến thức này ạ
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!!
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
thật sự tuyệt vời , chúc a và gia đình sức khỏe .
Hay quá anh ơi, mặc dù e vẫn gà nhưng mà xem cuốn quá :))
Hay quá 😮, a làm nhiều video về tối ưu tiếp đi ạ
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
Ủng hộ anh, tận tâm quá a ơi, chúc a nhiều sức khỏe ạ! ❤❤
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
well done a ơi 🎉🎉🎉
Cám ơn thầy, cực kì bổ ích ạ
quá hay a ơi, rất thật tế
Quá hay a ơi. ❤❤❤❤
cảm ơn anh vì kiến thức hữu ích
rất hay và bổ ích luôn
Tuyệt vời anh ơi 🎉🎉🎉
Cảm ơn em
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 ạ?
Khóa chính thì nó đã tự động được đánh index rồi nha ae, nên select nó nhanh, sau đó join
Tuyệt vời
Hay quá anh ơi
khá giống với "common table expression" anh nhỉ 😊😊
cái này e tự mày dùng bừa ko ngờ cũng đúng công thức🤣
hay. cám ơn sư huynh!
Cảm ơn anh!
Cảm ơn anh ạ ❤❤❤
hay quá sếp
Nào ra 1 bài về CTE trong SQL a nhé
hay quá anh
hay vãi, giờ e mới biết cái bảng tạm
Hóng a share cách chạy câu query khác server như DBLink trong MSSQL trên MySQL :D
Dạ bên thầy có khoá học nào chuyên về mảng MySQL này không ạ
tối ưu câu tính tổng sao anh? tks!
Video hay quá
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 🤣🤣🤣
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
các anh chị cho em hỏi, em muốn lấy data có số lượng bản ghi lớn để thực hành thì lấy ở đâu ạ
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
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.
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 ạ
nhưng kết hợp với partition hiệu suất lại kém đi
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 ạ?
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
Anh ơi, khoảng bao lâu nữa thì a xong khoá java spring
❤❤ 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
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 ạ.
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
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 ạ.
Video là 10 triệu..
@@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 😥
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ỉ
@@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 em học trên mạng thoi bác ơi, bác giải thích giúp em được không.
@@jackiedo7370 index họ lưu theo page và dòng thôi bác, như kiểu (1,3) là page 1 dòng 3 của page 1
@@jackiedo7370 Yes, in a row-based database, when you query a specific field (or column) of a row, the entire row is usually loaded into memory even though you're only interested in that specific field. This is because row-based databases are optimized for reading and writing entire rows. If you're querying a single field from a row, the database engine will still fetch the full row from disk, though it will only return the requested field to you.
In contrast, a columnar database would be more efficient if you're often querying individual fields across many rows, as it stores data by columns rather than rows.
Nguyên văn chat gpt đây bác, e học xong hỏi lại chat gpt cho chắc
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
a đã giải quyết đc vấn đề này chưa a
bắn tim chiu chiu
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.
nghe tiếng mưa và lập trình....
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 :))
Đố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
@@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 ạ
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á bác ơi