Mọi thứ về hiệu năng FOREIGN KEY trong RDBMS (Oracle, SQL Server, PostgreSQL, MySQL, MariaDB …)

Рет қаралды 42,974

Learning Database with Tran Quoc Huy

Күн бұрын

Пікірлер: 129

@tranquochuywecommit Ай бұрын

Công thức tạo dựng sự nghiệp không giới hạn của tôi - TOP 1% SECRET: www.top1percentsecret.com/

@TrungNguyenTranNam 28 күн бұрын

Video rất hay. Mình thiếu điều bị ADHD nhưng nghe x1 tốc độ không thiếu 1 giây nào. Cực nể những người làm trong 1 lĩnh vực lâu năm, nói không trật vào đâu được

@duongxuana414 Ай бұрын

Cảm ơn a Huy chia sẻ cực chi tiết từ bản chất. ⚡Dùng công cụ nào cũng phải có chiến lược. ⚡Những bảng nào cần nhất quán dữ liệu thì hoàn toàn có thể dùng FK. ⚡Có thể đẩy FK lên app để giảm tải cho database khi tính đúng đắn của phần dữ liệu đó chưa quan trọng ngay.

@haihoang0210 Ай бұрын

Quá hay luôn. Mọi thứ dễ dàng hơn khi nghe thầy giảng ạ. Em cám ơn thầy rất nhiều 🌺🌻☘🍀🌿

@chutranthe2837 Ай бұрын

Video này có lẽ không chỉ em mà còn nhiều ACE khác xem video này hiểu rõ hơn về bản chất FOREIGN KEY trong Database. Từ đó giúp quyết định việc sử dụng FOREIGN KEY cho 1 hệ thống hiệu quả nhất, vừa đáp ứng tốc độ vừa đáp ứng việc DỮ LIỆU NHẤT QUÁN. Cảm ơn anh Huy, và xin phép anh share video này cho nhiều người có cùng mối quan tâm được biết và tham khảo.

@iductruong Ай бұрын

Cảm ơn anh Huy chia sẻ kiến thức rất chuyên sâu về FK, ví dụ như các case trong tình huống thực tế tại sao thiết kế DB mà ng ta ko dùng FK hay trường hợp nào thì cần move FK lên xử lý ở tầng application, nếu ko có kinh nghiệm thực chiến thì những cái này chắc còn lâu ae mới biết đc. Các phần trong video trình bày rất logic và khoa học, đi từ giới thiệu về FK, lý do mà hệ thống chậm, chiến lược/ kỹ thuật tối ưu và phần demo - vô cùng thuyết phục. Mong chờ các video chia sẻ chuyên sâu như này sắp tới từ a ạ.

@DungLe-kk1tk Ай бұрын

Đã xem hết video thật sự ấn tượng về những keywords, kiến thức được anh Huy chia sẻ. Cảm ơn anh đã đống góp cho cộng đồng những video chất lượng như vậy.

@quocmanh449 Ай бұрын

Video đỉnh của chóp. Mình cũng thắc mắc từ lâu mà nay mới có người giải thích

Ай бұрын

primary key phải thiết kế cho nó là duy nhất, không được phép change. Thường thì được generate từ UUID, hoặc là sử dụng auto increment. Còn ông thần nào đi change primary key thì sai ngay từ đầu rồi, ai gánh cho nổi!

@kenhquanhgia9879 Ай бұрын

Đúng rồi, làm gì có logic change primary key trong thực tế

@kivisatedomotoji5956 Ай бұрын

Ví dụ mà delete 1 dòng PK trong bảng customer thì nó cũng phải quét bảng order thôi. Thực tế có thể ko ai Update PK thế nhưng mà ý tưởng trong video thì vẫn đúng

@hoathang4950 Ай бұрын

@@kivisatedomotoji5956 Thường sẽ phải xoá hết dữ liệu con trước xong mới xoá dữ liệu cha mà nên sao xảy ra đc, nếu không thì sẽ xoá mềm trước rồi chạy job xoá sau

@Ching582 Ай бұрын

@@kivisatedomotoji5956đừng có làm cascade.

@pnhannnn9382 Ай бұрын

Thì cái đó chỉ là ví dụ để đưa ra bản chất thôi mà

@cronocks Ай бұрын

video tuyệt vời. hồi trước mình có làm việc với FK, cũng đc hướng dẫn là làm theo thứ tự này kia chứ ko hiểu bản chất. giờ xem xong mới hiểu đc vì sao lại cần làm như thế.

@datnt97 Ай бұрын

Anh đưa ra một số chiến lược giải quyết vấn đề về hiệu năng khi làm việc với FK, cũng như Partition đều là những kiến thức rất mới mẻ với em. Cám ơn anh đã giúp em hiểu bản chất của vấn đề liên quan đến FK ạ!

@quyhoang4883 Ай бұрын

Video rất tuyệt vời a ạ, hiểu từ bản chất như này lý giải được rất nhiều điều Cảm ơn anh đã chia sẻ những kiến thức quý giá như vậy

@hoantranvietvn Ай бұрын

Với em video rất tâm huyết và đi sâu vào bản chất. Trước em từng xem phần bảng có Foreign Key phải đánh index để tránh lock giữa transaction ở bảng cha và bảng con nhưng chưa biết lý do. Xem video xong thì hiểu cơ chế hoạt động của database, lock khi update bảng con và update bảng cha khác nhau ntn. Sau em xem lại phần lock giữa các transaction, isolation levels thì hiểu sâu và dễ nhớ hơn. Cảm ơn anh nhiều, giữ nhiệt huyết nha anh.

@iepVuNgoc28490 Ай бұрын

Video quá bổ ích, giúp em hiểu rõ bản chất vấn đề bao lâu nay thắc mắc mà không dám dùng FK. Cảm ơn anh rất nhiều 😊

@phaminhthien7772 Ай бұрын

Cảm ơn anh, 1 video rất chi tiết và chuyên sâu

@hoangbuiminh1400 Ай бұрын

Video tuyệt vời quá ạ, hiểu bản chất là cảm thấy mọi thứ nó dễ hiểu hơn hẳn

@thucnguyenquy536 Ай бұрын

Trước khi anh lên video em vẫn luôn tin là triển khai FK trên business logic luôn tốt hơn. Cảm ơn anh đã cung cấp góc nhìn đa chiều ạ

@phamdan4495 Ай бұрын

Video dài hơn 1 tiếng mà xem cuốn từng phút một. Cảm ơn anh Huy đã chia sẻ.

@sontrinhvan1024 28 күн бұрын

Thanks bạn!, Hiểu được sản phẩm nhà SX là cả một quá trình trải nghiệm tuyệt vời.

@baudeejay8592 Ай бұрын

Kiến thức quá chuyên sâu hay nhất phần lock cám ơn anh chia sẻ nhiều ❤

@hoangvanduong9020 Ай бұрын

quá hữu ích, nhờ học hỏi từ a mà e pass PV dễ dàng hơn trc rất nhiều

@hoangvinh6567 Ай бұрын

Cám ơn Huy đã chia sẻ view thực sự rất hữu ích, và có chiều sâu như vậy, mà hoàn toàn miễn phí. Chúc Huy sức khoẻ và thành công hơn nữa

@gaumeuvlog2603 7 күн бұрын

Cám ơn anh đã chia sẻ ạ 😊

@tuansusu 9 күн бұрын

Rất cảm ơn anh, bài giảng hay quá

@chuannguyen1686 Ай бұрын

Kiến thức tuyệt vời như v mà học k tốn phí, e sẽ cho a 3 likes =)) cảm ơn a 😄

@tranquochuywecommit Ай бұрын

haha, cảm ơn người anh em

@hoangbon2806 Ай бұрын

Kiến thức rất bổ ích, cảm ơn bác nhé 😍😍😍😍😍😍

@tiendang5149 Ай бұрын

Kiến thức rất đáng quý, cảm ơn anh đã chia sẻ.

@tranquochuywecommit Ай бұрын

cảm ơn người anh em, mình đã nhận được quà tặng nhé.

@MrLoyalNguyen 19 күн бұрын

Rất hay và bổ ích luôn anh.

@Tienthanh0907 Ай бұрын

cám ơn anh Huy . Video rất hữu ích .

@Oxygen-h1u Ай бұрын

Video quá tuyệt vời anh ơi

@quandum Ай бұрын

Cám ơn anh về những bài học hữu ích.

@tranquochuywecommit Ай бұрын

cảm ơn người anh em, mình đã nhận được quà của anh em

@damvv.ptit12 Ай бұрын

Vẫn cứ nhiệt và máu lửa khi truyền kiến thức cho ae, thật đáng tiếc cho ae Dev mà không xem được video này của anh. Cảm ơn anh rất nhiều, 500 ae chia sẻ video này cho mọi người được biết ạ.

@minhhieple6483 Ай бұрын

Quá khủng, thanks anh rất nhiều. Mong anh ra nhiều video thực chiến như thế này hơn ạ.

@imsfy5335 5 күн бұрын

em chào anh, cảm ơn anh vì những video rất bổ ích và tâm huyết anh chia sẻ với mọi người anh có thể làm video hướng dẫn xây dựng database cho 1 số ứng dụng nào đó được không ạ? hiện tại em là sinh viên và đang dự tính làm 1 web app dạng như Upwork nhưng gặp khó khăn trong việc xây dựng database :( hi vọng được anh đọc comment và xem xét hướng dẫn ạ em cảm ơn anh

@huynguyenquang6204 Ай бұрын

video sâu sắc quá anh, em cảm ơn anh Huy

@Laggerptc Ай бұрын

Cám ơn anh Huy và team ạ!

@barebeardota Ай бұрын

Kênh bổ ích thế này phải lên 100k sub sớm

@huyhandes Ай бұрын

Quá dễ hiểu anh ạ. WOW thực sự

@achillesle3995 28 күн бұрын

Video hay.Thank a :)). Mong anh ra video nên đánh nhiều cột index theo thứ tự như thế nào ?

@congnguyenthanh3601 Ай бұрын

thank you bạn đã chia sẽ. Rất hữu ích,

@babykidscucaisuhao Ай бұрын

Tuyệt vời sếp!

@tutosolve Ай бұрын

Trong video, anh dùng chỉnh sửa đấy mn, Chứ ngoài đời, anh Huy đẹp trai, thân thiện hơn nha mn.

@hoangduy3929 7 күн бұрын

Mình thích xem video anh này, nhiều kiến thức hay nhưng kb sao có cảm giác cấn cấn sao đó, kiểu nghe cứ giống giọng video dạy làm giàu, self help kiểu thế :v

@lamdangtran81 Ай бұрын

Bản chất là ông không đọc tài liệu, đọc nguyên lý thiết kế của datatabase thôi => Đọc tài liệu sẽ giải quyết toàn bộ vấn đề trong tương lai, bất kể có liên quan database hay không Tôi: Xem anh Huy hướng dẫn sau khi nản việc dùng google dịch đọc tài liệu tiếng anh

@zonvlog5532 Ай бұрын

Cám ơn Huy. Chia sẻ chất quá! Nhưng có điều nhạc nền hơi buồn ngủ 😅

@tunael4027 Ай бұрын

Quá đỉnh

@phamcongtoan1399 Ай бұрын

mong chú làm nhìu về thiết kế db

@tranquochuywecommit Ай бұрын

okie anh em, các kiến thức về db sẽ có nhé

@NhanNguyen-xb5cn Ай бұрын

hay quá đại ca ơi

@thinhbui4835 Ай бұрын

Anh có thể nói về vấn đề query trên nhiều cột được không, ví dụ như bảng order có customerid, userid, create at, ... khi đánh index thì chỉ theo 1 thứ tự, nhưng khi select thì có thể gặp trường hợp không dùng đc index, vậy best practice là gì, query trên app layer rồi select theo list id, hay chia bảng như nào. Cám ơn anh

@DatNickNganGonVaDeNho Ай бұрын

Đa số db có hỗ trợ sắp xếp lại WHERE clause để check xem có index hay chưa, tiêu biểu là postgres, oracle, nhưng cũng có hạn chế như mySQL, nên dùng bất cứ 1 query nào có composite index thì đều phải check lại plan xem có gọi đc index hay chưa ( index sai, hoặc thứ tự ko đúng index do DB cùi)

@thinhbui4835 Ай бұрын

@@DatNickNganGonVaDeNho vậy trường hợp index có 3 cols, nhưng mình muốn lọc theo tất cả trường hợp bao gồm cả query 1 hoặc 2 cols cuối trong index thì sao ạ

@DatNickNganGonVaDeNho Ай бұрын

@@thinhbui4835 buộc phải đánh thêm index nhé, 1 cái 3 cols, 1 cái 2 cols, 1 cái 1 cols

@DatNickNganGonVaDeNho Ай бұрын

@@thinhbui4835ko phải bất cứ cái gì trong WHERE đều cần index và nên kết hợp index và partition và lưu ý composite index chưa chắc hoạt động, nhưng index 1 field thì luôn luôn hoạt động. Đánh index cần kinh nghiệm và mức độ hiểu biết toàn bộ dự án, sự thật là index là thứ thay đổi xoành xoạch.

@quocbao2765 Ай бұрын

@@thinhbui4835 phần đánh index có nói rồi đó, đánh index theo câu query, đánh index nhiều cột, theo thứ tự query các col

Ай бұрын

tuyệt vời

@tanphucle9417 Ай бұрын

Hay quá anh ơi

@quangphongtran3558 Ай бұрын

QUÁ HAY

@dung.nt085 Ай бұрын

đoạn đánh index tổ hợp có thêm lý do vì sao (order_id, custom_id) mà nó không ăn vào được index của custom_id khi update trên bảng custom thì ngon luôn anh

@baudeejay8592 Ай бұрын

Hay quá anh

@tungthanh4297 Ай бұрын

Anh có thể làm video về các trường hợp locking của MongoDB đc không ạ

@Ching582 Ай бұрын

Làm nghề hơn 20 năm chưa gặp case change ID. Lạy luôn

@hoangvinh6567 Ай бұрын

Bạn delete id bảng chính nó cũng lock luôn, ở đây Huy đang nói về vấn đề liên quan đến FK

@Ching582 Ай бұрын

@@hoangvinh6567 thì sao ko nói thẳng vấn đề mà đưa ra tình huống không có trong thực tế rồi nói dông dài ra.

@amazingthings3617 Ай бұрын

Chốt lại nếu hệ thống nào liên quan tiền bạc nhiều thì cứ FK cho chắc nhé ae, tuy chậm nhưng yên tâm hơn khi giao phó hết cho mấy ông dev

@sytien492 Ай бұрын

hay quá

@HuyPham-ov1qd Ай бұрын

Video rất hữu ích anh, Cho em hỏi thêm khi bảng order lớn lên và mình cần "đếm số lượng order được đặt bởi user 'a' theo từng tháng trong năm" thì mình tách thành 2 lần query (6 tháng / lần) hay nên query 1 lần 12 tháng sẽ tối ưu hơn vây anh.

@tiephoangpham303 Ай бұрын

Cái này nên kết hợp cache thì tốt hơn, lần đầu thì query 1 phát 12 tháng, lần sau thì check cached -> nếu ko có thì mới query các tháng đang thiếu

@phamduc4048 Ай бұрын

anh Huy làm video về nên lựa chọn primary key = UUID hay integer được k anh? Khi nào nên dùng thằng nào, và tại sao ạ

@tiephoangpham303 Ай бұрын

tùy theo số lượng bản ghi, nhiều thì UUID, ít thì int. có 1 số logic thì UUID sẽ tốt hơn ví dụ như trong 1 transaction, create new record -> sau đó dùng id để thực hiện tiếp các inser/update các bản ghi thì UUID sẽ tốt hơn là int tự động tăng...

@phamduc4048 Ай бұрын

@@tiephoangpham303 Ồ mình cảm ơn nha, vậy theo mình hiểu là uuid hiệu quả hơn trong tính nhất quán của dữ liệu. Mình thấy về performance thì int sẽ nhanh hơn

@vananhtranlekj Ай бұрын

T xem nhiều video của anh này, nói chung cũng hay, tuy nhiên thì các ví dụ chậm như này chắc cỡ 99% là có dính dáng transaction. có thể lấy ví dụ mà ko dính dáng gì ông transaction này dc ko

@tranquochuywecommit Ай бұрын

trong video có đấy em, không có transaction thì vẫn chậm vì chiến lược thực thi phải quét FULL đấy. Còn transaction thì gần như là điều đối mặt liên tục trong dự án, đó là điều vì sao anh hay nói cho anh em về transaction.

@sonht1109 18 күн бұрын

thank sếp nhiều ạ, sếp cho e hỏi, case study phần đầu hình như ko chạy với Postgres đúng ko ạ? Em test thì có vẻ vậy, hay có thể do em test sai ạ, mong sếp giải đáp ạ Ví dụ nếu em update bảng orders mà có customer_id là 1 thì xảy ra lock như trên, nhưng nếu update bảng orders mà customer_id khác 1 thì em lại ko thấy bị lock với Postgres ạ

@TwoRpa Ай бұрын

Tôi thấy db mà cho change key thì nó sai từ khâu thiết kế rồi. Vì khi chúng ta add key(primary hay foreign) thì db nó phải chạy index, nó phải đảm bảo key được ref đúng chỗ. Nên nghiệp vụ change key là sai hoàn toàn, không thực tế.

@CuongPham-gq1ol Ай бұрын

Chuẩn

@tranquochuywecommit Ай бұрын

Ví dụ để anh em hiểu nguyên lý thôi. Không Update thì Delete cũng dính, trong video có phân tích và lúc demo cuối video có làm phần delete đấy anh em. Quan trọng là hiểu bản chất hoạt động của database người anh em ah

@nguyenhoanganh2k1 Ай бұрын

anh cho em hỏi ví dụ ban đầu là chỉnh sửa cột khóa chính mà là fk của bảng khác thì nếu ví dụ là update cột khác ở bảng khóa chính thì nó có khóa và ngầm định check ở bảng fk nữa ko anh?

@quandum Ай бұрын

Em muốn hỏi thế này: Theo em hiểu ý anh nói ở phần FK disable / enable no validate thì khi validate có thể dẫn tới việc Full Scan bảng cha * Full scan bảng con. Dẫn tới chậm tới mức không thể với data mỗi bảng trên hàng triệu. Vậy nếu case này em có index cả 2 key trên 2 bảng, hoặc có luôn partition nếu cần tất cả chỉ tập trung tăng tốc scan 2 cột key đó, thì quá trình validate có thể tăng tốc lên không?

@sonlh81 Ай бұрын

Cái này Huy đã làm 1 lần rồi nhưng video lần đó ngắn hơn và k giải thích kỹ như video này :)

@tranquochuywecommit Ай бұрын

cảm ơn người anh em đã ủng hộ mình trong thời gian dài, đúng là đã có 1 video về vấn đề này, nhưng video đợt đó chỉ là 1 khía cạnh, còn video này thì chi tiết và nhiều góc phân tích hơn

@sonlh81 Ай бұрын

@@tranquochuywecommit Đoạn cuối cùng Delete trên bảng Customers, nếu bạn show cả Excute Plan trong trường hợp bảng Order ko có và có Index trên trường customerID thì đẹp hơn. Vì như thế anh em hiểu rõ là khi không có Index thì nó scan bảng, read block nhiều, khi có Index nó seek thì read block ít :)

@dat1309 21 күн бұрын

Cho em hỏi, nếu transaction A chạy trước transaction B thì gây ra lock và ngược lại nếu transaction B chạy trước transaction A thì không bị lock. Nhưng đấy chỉ là 2 transaction. vậy nếu trong trường hợp transaction B chạy trước transaction A nhưng lại có một transaction thứ 3 chạy giống tác vụ của transaction A thì nó vẫn bị lock chứ nhỉ :(

@mBussiness Ай бұрын

e hỏi ví dụ thực tế sao cứ thứ 2 bên bệnh viện lại chậm

@tranquochuywecommit Ай бұрын

có những thứ đi vào chi tiết dự án anh không tiết lộ được. Nhưng em vào các viện sẽ thấy điều này

@Phuc050589 Ай бұрын

Ngay từ ngữ cảnh nó đã ko đúng, tại sao lại change primary key?

@khuongduy223 Ай бұрын

anh ơi, e muốn dùng partition key cho 1000 key trong table của mysql, dù table rỗng nhưng vẫn tạo rất lâu, cho e xin cách khắc phục với

@thangciu1345 Ай бұрын

Hi a. ở phần update hoặc delete FK. Nếu mình where FK nhưng update field # FK thì có bị lock không a nhỉ? với ở phần index nhiều cột thay vì phải để ý đến thứ tự thì sẽ tạo 2 index, 1 cho FK và 1 index nhiều cột( ko cần quan tâm thứ tự) thì có ảnh hưởng gì ko ạ?

@NguyenMinh-gl7qz Ай бұрын

Em đang tìm hiểu 4 cái isolation level và case phantom read mà có vẻ k thấy anh có video nào nói về cái này, mong là lúc nào có để được thông não ạ :D

@tranquochuywecommit Ай бұрын

nội dung thuộc phần ACID này lúc khảo sát thấy hơi ít người quan tâm nên anh chưa làm.

@dinhnguyen4729 Ай бұрын

Mình đang dùng Sql Server Replication để lấy dữ liệu từ Core SQL Server về. Hiện tại trên các bảng lấy về chưa có Partition vậy mình đã thử Partition trên các table mình lấy về được . Thì gặp 1 rắc rối là khi đó Replicaiton bị lỗi, không lấy được dữ liệu về nữa. Host có ý tưởng nào cho việc này không. Vì mình đang không được đụng gì đến thiết kế Database của Core . Xin cảm ơn

@Nhadautu-dz7nm Ай бұрын

pro Huy ơi, khoá học của pro có online không? tôi ở nước ngoài không offline được

@tranquochuywecommit Ай бұрын

học viên nước ngoài của mình rất nhiều, anh em tham gia thoải mái nhé.

@phuo9516 Ай бұрын

Tức là lúc update customer id 2 thành 3 nó sẽ lock vì dễ gây inconsistency hay là cứ update column này là dính lock v a ...

@tranquochuywecommit Ай бұрын

xem kỹ hơn trong video, anh có nói chi tiết đấy em

@MrKeyyuki Ай бұрын

anh dùng tool gì để phân tích chiến lược câu lệnh vậy ạ

@tranquochuywecommit Ай бұрын

phân tích chiến lược thực thi thì bản thân các loại database đều có sẵn em ah. Trong video thì anh dùng ngay tool SSMS trong SQL Server thôi. Nếu em dùng loại database khác thì em có thể tìm các video full course liên quan tới database đó trên youtube của anh, anh đều hướng dẫn lấy và xem chiến lược thực thi đấy. Em có thể tìm + Trần Quốc Huy + Full Course là ra. Ví dụ: MySQL + Trần Quốc Huy + Full Course PostgreSQL + Trần Quốc Huy + Full Course Xem phát hiểu ngay em nhé

@HungNguyen-ke5mi Ай бұрын

E chào anh , anh cho em hỏi nếu trong dự án thực tế em đang dùng mariadb có 1 table số lượng bản ghi lên đến 19 triệu bản ghi với data length trong table là 40G nhưng thiết kế ban đầu chưa setup partition thì mình nên xử lý thế nào để cải thiện tốc độ truy vấn vào bảng này ạ, mong anh giải đáp thắc mắc giúp em ạ

@tranquochuywecommit 14 күн бұрын

Với các loại cơ sở dữ liệu, em đều có thể chuyển từ một bảng chưa partition sang partition nhé.

@thebeastwithin01 Ай бұрын

sao mình test ví dụ ở đầu clip , với cả 2 database PostgreSQL và MySQL (engine InnoDB) thì đều không thấy câu lệnh update customer id từ 2 -> 3 bị lock nhỉ . Chỉ khi update id của customer với id là 1 sang một giá trị khác thì lúc ấy PostgreSQL / MySQL mới báo lỗi vi phạm constraint (nhưng vẫn không lock)

@tranquochuywecommit Ай бұрын

xem đủ video sẽ thấy nói Mysql tự động tạo index trên fk nhé anh em.

@NguyenNgoc-zq7mc Ай бұрын

1h16 : 3585+13+1 = 3600 sao ad ơi 😹😹😹

@chienpham6392 Ай бұрын

cmt đầu

@tranquochuywecommit Ай бұрын

tuyệt vời, cảm ơn người anh em

@dbt1231 Ай бұрын

Mysql không thể partitions kết hợp foreign key, mà lượng data lớn như hệ thống ngân hàng, e-commerce… thì bắt buộc phải có partitions kèm theo rang buộc chặt chẽ về mặt data nên suy ra mysql không phù hợp với hệ thống có đặc thù như trên phải không bạn Huy?