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

Рет қаралды 62,749

Learning Database with Tran Quoc Huy

Күн бұрын

Пікірлер: 140

@tranquochuywecommit Ай бұрын

Gửi mọi người Group Telegream Wecommit Public Community : www.wecommit.com.vn/wecommitcommunity ,anh em có thể trao đổi những câu hỏi , vấn đề khi xem Video và kết nối với tôi trong Group nhé (trường hợp click trực tiếp bị lỗi thì ae copy link ra browser nhé)

@duongxuana414 2 ай бұрын

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.

@chutranthe2837 2 ай бұрын

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.

@hoantranvietvn 2 ай бұрын

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.

@diepdo5883 Ай бұрын

tuyệt vời anh. DB cty em bị tình trạng lock đã 2 tháng nay , mỗi lần lock là chỉ biết kill. Nhờ có video này mà em xử lý được dứt điểm trường hợp bị lock trong cty em. Cảm ơn rất nhiều!

@DungLe-kk1tk 2 ай бұрын

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

@tranquochuywecommit 2 ай бұрын

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/

@iductruong 2 ай бұрын

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

@cronocks 2 ай бұрын

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

@thucnguyenquy536 2 ай бұрын

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 ạ

@datnt97 2 ай бұрын

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 ạ!

@quocmanh449 2 ай бұрын

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

@iepVuNgoc28490 2 ай бұрын

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 😊

@haihoang0210 2 ай бұрын

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 🌺🌻☘🍀🌿

@sontrinhvan1024 2 ай бұрын

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.

@HaiTran-tz7hm 29 күн бұрын

Chia sẻ cực chi tiết và dễ hiểu. Cảm ơn anh.

@quocduongth10bmta 28 күн бұрын

Khi update data của bảng cha, sẽ cần kiểm tra data của bảng con nên có thể phải full table scan bảng con. Có thể đánh index cho cột FK bên bảng con để tăng hiệu năng do không còn phải full table scan bảng con khi đã có index. Nên đánh index cho nhiều cột thay vì đánh nhiều index cho 1 cột, nhưng phải để cột FK đầu tiên.

@quyhoang4883 2 ай бұрын

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

@toannguyenvan91333 Ай бұрын

Cảm ơn anh đã chia sẻ kiến thức rất hay, chúc anh sức khoẻ để cống hiến cho ae ❤❤

@hoangvinh6567 2 ай бұрын

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

@phamdan4495 2 ай бұрын

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

@baudeejay8592 2 ай бұрын

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

@BinhNguyen-sd5sv 23 күн бұрын

Cảm ơn a rất nhiều, làm chục năm ồi giờ mới biết cái này :(

@hoangvanduong9020 2 ай бұрын

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

2 ай бұрын

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 2 ай бұрын

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

@kivisatedomotoji5956 2 ай бұрын

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 2 ай бұрын

@@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 2 ай бұрын

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

@pnhannnn9382 2 ай бұрын

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

@hoangbuiminh1400 2 ай бұрын

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

@tiendang5149 2 ай бұрын

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

@tranquochuywecommit 2 ай бұрын

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

@Ching582 2 ай бұрын

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

@hoangvinh6567 2 ай бұрын

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 2 ай бұрын

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

@tuansusu 2 ай бұрын

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

@chuannguyen1686 2 ай бұрын

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 2 ай бұрын

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

@pdthien 2 ай бұрын

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

@Tienthanh0907 2 ай бұрын

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

@MrLoyalNguyen 2 ай бұрын

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

@quandum 2 ай бұрын

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

@tranquochuywecommit 2 ай бұрын

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

@gaumeuvlog2603 Ай бұрын

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

@hoangbon2806 2 ай бұрын

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

@minhhieple6483 2 ай бұрын

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

@apt-92 2 ай бұрын

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

@achillesle3995 2 ай бұрын

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

@damvv.ptit12 2 ай бұрын

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

@imsfy5335 Ай бұрын

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

@quandum 2 ай бұрын

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?

@barebeardota 2 ай бұрын

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

@mongalexi584 Ай бұрын

hay quá anh ơi

@tranquochuywecommit Ай бұрын

cảm ơn anh em nhá

@thinhbui4835 2 ай бұрын

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 2 ай бұрын

Đ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 2 ай бұрын

@@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 2 ай бұрын

@@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 2 ай бұрын

@@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 2 ай бұрын

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

@tungthanh4297 2 ай бұрын

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

@dung.nt085 2 ай бұрын

đ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

@huynguyenquang6204 2 ай бұрын

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

@lamdangtran81 2 ай бұрын

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

@tutosolve 2 ай бұрын

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.

@huyhandes 2 ай бұрын

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

@Laggerptc 2 ай бұрын

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

@sonht1109 2 ай бұрын

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 ạ

@HuyPham-ov1qd 2 ай бұрын

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 2 ай бұрын

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

@congnguyenthanh3601 2 ай бұрын

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

@nguyenhoanganh2k1 2 ай бұрын

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?

@LongHoang-j7l 4 күн бұрын

Ủa sao có cái case delete/update PK ta, Ví dụ này không thực tế lắm, có ví dụ nào khác cho việc block này không vậy ạ chứ nếu mỗi case này thì nó cũng không giải quyết vấn đề gì vì đơn giản nó không xảy ra

@khuongduy223 2 ай бұрын

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

@zonvlog5532 2 ай бұрын

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

@hoangduy3929 Ай бұрын

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

@tunael4027 2 ай бұрын

Quá đỉnh

@dinhnguyen4729 2 ай бұрын

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

@learnanywhere139 2 ай бұрын

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ỉ :(

@vananhtranlekj 2 ай бұрын

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 2 ай бұрын

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.

@phamcongtoan1399 2 ай бұрын

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

@tranquochuywecommit 2 ай бұрын

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

@giadinhcucaisuhao 2 ай бұрын

Tuyệt vời sếp!

@thangciu1345 2 ай бұрын

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

@quangphongtran3558 2 ай бұрын

QUÁ HAY

@phamduc4048 2 ай бұрын

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 2 ай бұрын

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 2 ай бұрын

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

@quangphungvan6789 29 күн бұрын

Db distributed thì dùng uuid nhé

@amazingthings3617 2 ай бұрын

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 2 ай бұрын

hay quá

@baudeejay8592 2 ай бұрын

Hay quá anh

@phuo9516 2 ай бұрын

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 2 ай бұрын

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

@NhanNguyen-xb5cn 2 ай бұрын

hay quá đại ca ơi

@NguyenMinh-gl7qz 2 ай бұрын

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 2 ай бұрын

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.

@TwoRpa 2 ай бұрын

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 2 ай бұрын

Chuẩn

@tranquochuywecommit 2 ай бұрын

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

@tanphucle9417 2 ай бұрын

Hay quá anh ơi

@MrKeyyuki 2 ай бұрын

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

@tranquochuywecommit 2 ай бұрын

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 2 ай бұрын

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 2 ай бұрын

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

@Nhadautu-dz7nm 2 ай бұрын

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

@tranquochuywecommit 2 ай бұрын

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

@Phuc050589 2 ай бұрын

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

@ltakaka234 2 ай бұрын

tuyệt vời

@thebeastwithin01 2 ай бұрын

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 2 ай бұрын

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

@mBussiness 2 ай бұрын

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

@tranquochuywecommit 2 ай бұрын

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

@sonlh81 2 ай бұрын

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 2 ай бұрын

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 2 ай бұрын

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

@chienpham6392 2 ай бұрын

cmt đầu

@tranquochuywecommit 2 ай бұрын

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

@3cham817 Ай бұрын

cho em xin tool present vs ạ

@tranquochuywecommit Ай бұрын

goodnotes nhé người anh em

@NguyenNgoc-zq7mc 2 ай бұрын

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

@dbt1231 2 ай бұрын

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?