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
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 ạ.
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.
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 🌺🌻☘🍀🌿
28 วันที่ผ่านมา +17
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!
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
@@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
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.
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 ạ.
Đã 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.
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.
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ế.
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 ạ!
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 ạ
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
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
Đ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)
@@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 ạ
@@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.
đ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
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ỉ :(
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?
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
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.
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ế.
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
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?
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 ạ?
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
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.
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...
@@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
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)
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 ạ
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
@@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 :)
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é
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?
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/
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
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 ạ.
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.
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 🌺🌻☘🍀🌿
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!
Đúng rồi, làm gì có logic change primary key trong thực tế
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
@@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
@@kivisatedomotoji5956đừng có làm cascade.
Thì cái đó chỉ là ví dụ để đưa ra bản chất thôi mà
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.
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 ạ.
Đã 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.
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
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.
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ế.
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 😊
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
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 ạ!
Cảm ơn anh, 1 video rất chi tiết và chuyên sâu
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 ạ
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.
Rất cảm ơn anh, bài giảng hay quá
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
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ẻ.
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
Kiến thức quá chuyên sâu hay nhất phần lock cám ơn anh chia sẻ nhiều ❤
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
Rất hay và bổ ích luôn anh.
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 😄
haha, cảm ơn người anh em
Kiến thức rất đáng quý, cảm ơn anh đã chia sẻ.
cảm ơn người anh em, mình đã nhận được quà tặng nhé.
Cám ơn anh về những bài học hữu ích.
cảm ơn người anh em, mình đã nhận được quà của anh em
cám ơn anh Huy . Video rất hữu ích .
Video hay.Thank a :)). Mong anh ra video nên đánh nhiều cột index theo thứ tự như thế nào ?
Kiến thức rất bổ ích, cảm ơn bác nhé 😍😍😍😍😍😍
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 ạ.
Kênh bổ ích thế này phải lên 100k sub sớm
Video quá tuyệt vời anh ơi
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 ạ
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.
video sâu sắc quá anh, em cảm ơn anh Huy
thank you bạn đã chia sẽ. Rất hữu ích,
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
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
Đ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)
@@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 ạ
@@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
@@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.
@@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
Cám ơn anh Huy và team ạ!
Quá dễ hiểu anh ạ. WOW thực sự
Ngay từ ngữ cảnh nó đã ko đúng, tại sao lại change primary key?
đ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
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ỉ :(
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?
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
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.
Làm nghề hơn 20 năm chưa gặp case change ID. Lạy luôn
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
@@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.
Tuyệt vời
sếp!
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ế.
Chuẩn
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
Cám ơn Huy. Chia sẻ chất quá! Nhưng có điều nhạc nền hơi buồn ngủ 😅
Anh có thể làm video về các trường hợp locking của MongoDB đc không ạ
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?
QUÁ HAY
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 ạ?
Hay quá anh ơi
Quá đỉnh
Hay quá anh
hay quá đại ca ơi
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
tuyệt vời
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.
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
mong chú làm nhìu về thiết kế db
okie anh em, các kiến thức về db sẽ có nhé
hay quá
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
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 ạ
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...
@@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
e hỏi ví dụ thực tế sao cứ thứ 2 bên bệnh viện lại chậm
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
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
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)
xem đủ video sẽ thấy nói Mysql tự động tạo index trên fk nhé anh em.
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 ạ
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é.
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 :)
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
@@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 :)
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 ...
xem kỹ hơn trong video, anh có nói chi tiết đấy em
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
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.
anh dùng tool gì để phân tích chiến lược câu lệnh vậy ạ
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é
pro Huy ơi, khoá học của pro có online không? tôi ở nước ngoài không offline được
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é.
1h16 : 3585+13+1 = 3600 sao ad ơi 😹😹😹
cmt đầu
tuyệt vời, cảm ơn người anh em
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?
tuyệt vời