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é)
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.
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 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.
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 ạ.
Đã 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.
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 ạ!
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ế.
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!
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.
Kiến thức quá chuyên sâu hay nhất phần lock cám ơn anh chia sẻ nhiều ❤
3 місяці тому+20
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
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 ạ.
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
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?
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.
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
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.
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 ạ
đ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
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?
Ủ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
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ù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
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
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
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 ạ?
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ỉ :(
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é
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 ạ
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
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)
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 :)
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?
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é)
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.
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 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.
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 ạ.
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 🌺🌻☘🍀🌿
Đã 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.
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 ạ!
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
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ế.
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!
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 😊
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 ạ
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
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
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.
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
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.
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 ❤❤
Chia sẻ cực chi tiết và dễ hiểu. Cảm ơn anh.
Kiến thức quá chuyên sâu hay nhất phần lock cám ơn anh chia sẻ 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 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
Cảm ơn anh, 1 video rất chi tiết và chuyên sâu
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
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 ạ.
Cảm ơn a rất nhiều, làm chục năm ồi giờ mới biết cái này :(
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é.
Rất cảm ơn anh, bài giảng hay quá
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 ạ.
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.
Kiến thức rất bổ ích, cảm ơn bác nhé 😍😍😍😍😍😍
Rất hay và bổ ích luôn anh.
cám ơn anh Huy . Video rất hữu ích .
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 quá tuyệt vời anh ơi
Kênh bổ ích thế này phải lên 100k sub sớm
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
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
Cám ơn anh đã chia sẻ ạ 😊
Quá dễ hiểu anh ạ. WOW thực sự
video sâu sắc quá anh, em cảm ơn anh Huy
Video hay.Thank a :)). Mong anh ra video nên đánh nhiều cột index theo thứ tự như thế nào ?
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.
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?
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 ạ!
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
hay quá anh ơi
cảm ơn anh em nhá
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
Tuyệt vời
sếp!
Anh có thể làm video về các trường hợp locking của MongoDB đc không ạ
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 ạ
Cám ơn Huy. Chia sẻ chất quá! Nhưng có điều nhạc nền hơi buồn ngủ 😅
đ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
thank you bạn đã chia sẽ. Rất hữu ích,
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?
Ủ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
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.
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
Db distributed thì dùng uuid nhé
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
hay quá đại ca ơi
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
Hay quá anh ơi
Hay quá anh
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
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 ạ?
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
Quá đỉnh
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ỉ :(
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
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é
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é
QUÁ HAY
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é.
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é.
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.
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
Ngay từ ngữ cảnh nó đã ko đúng, tại sao lại change primary key?
tuyệt vời
hay quá
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.
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 :)
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
cho em xin tool present vs ạ
goodnotes nhé người anh em
cmt đầu
tuyệt vời, cảm ơn người anh em
1h16 : 3585+13+1 = 3600 sao ad ơi 😹😹😹
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