1. Em muốn hỏi các anh chị trong thực tế thì các câu lệnh trong SQL SERVER được thực thi hay xử lí bên trong như thế nào ạ. Em cũng chỉ biết viết các câu lệnh xong ấn execute để nó chạy thôi chứ em chưa hiểu SQL Server nó xử lí bên trong như thế nào ạ. Mong các anh chị giải đáp giúp em.
thảo luận Thảo luận về SQL Server
- Thread starter D4rkHaR1m
- Start date
EzLink
Senior Member
bạn cày hết video khóa CS186 này sẽ hiểu nhé https://www.youtube.com/@CS186Berkeley/playlists
Xin chân thành cảm ơn bạn rất nhiều ạ
codeforfood2015
Member
Tìm hiểu khái niệm execution plan nhé.
SQL Server Management Tool có cái hiển thị lược đồ thực thi hơi bị ngon.
SQL Server Management Tool có cái hiển thị lược đồ thực thi hơi bị ngon.
ez-aqua
Senior Member
Để bạn biết query đó được thực hiện thế nào thì bạn phải hiểu execution plan. Đọc hiểu execution plan là cả 1 nghệ thuật. Nhiều người cứ nói chứ muốn nhanh thì đánh... index là xong 
hoặc viết câu query thế này thế kia sẽ nhanh.... Vấn đề index hay viết query ra sao chỉ là phần nhỏ của tảng băng chìm thôi.
Câu query bạn viết là logical, nghĩa là kết quả sẽ trả về theo logic mong muốn mà bạn viết. Còn thực tế chạy thế nào thì bạn phải xem execution plan. Bạn nhìn vào đó bạn nhìn thấy scan, seek, nested loop, hash join, sort-merge join, stream aggregate, hash aggregate, parallelism, window function.... Vấn đề là bạn phải biết các thuật toán đó giải bằng tay thế nào thì bạn sẽ biết hiểu execution plan.
VD scan quét từ đầu đến cuối O(n), seek O(nlogn), nhưng chuyện gì xảy ra nếu n siêu nhỏ? trong khi seek phải traverse đọc từ root xuống leaf. Chuyện gì xảy ra nếu bạn phải seek n lần? Hay có sẵn index đấy, nhưng range seek siêu to, index đó lại là clustered index full data IO to tướng trong khi cái index khác không sort nhưng chỉ có vài column và đúng column bạn đang cần dùng để tính toán.
Hay như khi join, nested loop độ phức tạp to, chạy chậm, nhưng khi data sieu nhỏ, thì chạy luôn nestedloop vì overhead cost thấp, hash chạy nhanh nhưng lại dùng RAM to. Sort merge thì phải sort, vậy nếu có sẵn sort nhờ index, thì nên chọn cái nào.
Rồi làm sao nó nó biết được cái nào n to n nhỏ, đi qua 1 loạt operation, đến operation sau làm sao biết được data to nhỏ mà tính thuật toán + cung cấp resource đủ. Cấp k đủ resource thì spill.
Spill hoặc là plan không hợp lí thì hoặc là can thiệp vào statistics, hoặc là manual control nếu hết cách.
Kiểu vậy.
hoặc viết câu query thế này thế kia sẽ nhanh.... Vấn đề index hay viết query ra sao chỉ là phần nhỏ của tảng băng chìm thôi.Câu query bạn viết là logical, nghĩa là kết quả sẽ trả về theo logic mong muốn mà bạn viết. Còn thực tế chạy thế nào thì bạn phải xem execution plan. Bạn nhìn vào đó bạn nhìn thấy scan, seek, nested loop, hash join, sort-merge join, stream aggregate, hash aggregate, parallelism, window function.... Vấn đề là bạn phải biết các thuật toán đó giải bằng tay thế nào thì bạn sẽ biết hiểu execution plan.
VD scan quét từ đầu đến cuối O(n), seek O(nlogn), nhưng chuyện gì xảy ra nếu n siêu nhỏ? trong khi seek phải traverse đọc từ root xuống leaf. Chuyện gì xảy ra nếu bạn phải seek n lần? Hay có sẵn index đấy, nhưng range seek siêu to, index đó lại là clustered index full data IO to tướng trong khi cái index khác không sort nhưng chỉ có vài column và đúng column bạn đang cần dùng để tính toán.
Hay như khi join, nested loop độ phức tạp to, chạy chậm, nhưng khi data sieu nhỏ, thì chạy luôn nestedloop vì overhead cost thấp, hash chạy nhanh nhưng lại dùng RAM to. Sort merge thì phải sort, vậy nếu có sẵn sort nhờ index, thì nên chọn cái nào.
Rồi làm sao nó nó biết được cái nào n to n nhỏ, đi qua 1 loạt operation, đến operation sau làm sao biết được data to nhỏ mà tính thuật toán + cung cấp resource đủ. Cấp k đủ resource thì spill.
Spill hoặc là plan không hợp lí thì hoặc là can thiệp vào statistics, hoặc là manual control nếu hết cách.
Kiểu vậy.
Last edited:
Dạ em cảm ơn anh ạ
Em hiểu ý của anh ạ đúng là em cũng đang định đặt thêm câu hỏi về tối ưu ạ, em cảm ơn anh rất nhiều vì thông tin này rất hữu ích ạĐể bạn biết query đó được thực hiện thế nào thì bạn phải hiểu execution plan. Đọc hiểu execution plan là cả 1 nghệ thuật. Nhiều người cứ nói chứ muốn nhanh thì đánh... index là xong
Câu query bạn viết là logical, nghĩa là kết quả sẽ trả về theo logic mong muốn mà bạn viết. Còn thực tế chạy thế nào thì bạn phải xem execution plan. Bạn nhìn vào đó bạn nhìn thấy scan, seek, nested loop, hash join, sort-merge join, stream aggregate, hash aggregate, parallelism, window function.... Vấn đề là bạn phải biết các thuật toán đó giải bằng tay thế nào thì bạn sẽ biết hiểu execution plan.
VD scan quét từ đầu đến cuối O(n), seek O(nlogn), nhưng chuyện gì xảy ra nếu n siêu nhỏ? trong khi seek phải traverse đọc từ root xuống leaf. Chuyện gì xảy ra nếu bạn phải seek n lần? Hay có sẵn index đấy, nhưng range seek siêu to, index đó lại là clustered index full data IO to tướng trong khi cái index khác không sort nhưng chỉ có vài column và đúng column bạn đang cần dùng để tính toán.
Hay như khi join, nested loop độ phức tạp to, chạy chậm, nhưng khi data sieu nhỏ, thì chạy luôn nestedloop vì overhead cost thấp, hash chạy nhanh nhưng lại dùng RAM to. Sort merge thì phải sort, vậy nếu có sẵn sort nhờ index, thì nên chọn cái nào.
Rồi làm sao nó nó biết được cái nào n to n nhỏ, đi qua 1 loạt operation, đến operation sau làm sao biết được data to nhỏ mà tính thuật toán + cung cấp resource đủ. Cấp k đủ resource thì spill.
Spill hoặc là plan không hợp lí thì hoặc là can thiệp vào statistics, hoặc là manual control nếu hết cách.
Kiểu vậy.
anh có thể rcm cho em có nguồn docs nào anh thấy ok để đọc không ạ em có thể đọc được tiếng anh hoặc kênh youtube nào có series nói về cái này không thưa anhĐể bạn biết query đó được thực hiện thế nào thì bạn phải hiểu execution plan. Đọc hiểu execution plan là cả 1 nghệ thuật. Nhiều người cứ nói chứ muốn nhanh thì đánh... index là xong
Câu query bạn viết là logical, nghĩa là kết quả sẽ trả về theo logic mong muốn mà bạn viết. Còn thực tế chạy thế nào thì bạn phải xem execution plan. Bạn nhìn vào đó bạn nhìn thấy scan, seek, nested loop, hash join, sort-merge join, stream aggregate, hash aggregate, parallelism, window function.... Vấn đề là bạn phải biết các thuật toán đó giải bằng tay thế nào thì bạn sẽ biết hiểu execution plan.
VD scan quét từ đầu đến cuối O(n), seek O(nlogn), nhưng chuyện gì xảy ra nếu n siêu nhỏ? trong khi seek phải traverse đọc từ root xuống leaf. Chuyện gì xảy ra nếu bạn phải seek n lần? Hay có sẵn index đấy, nhưng range seek siêu to, index đó lại là clustered index full data IO to tướng trong khi cái index khác không sort nhưng chỉ có vài column và đúng column bạn đang cần dùng để tính toán.
Hay như khi join, nested loop độ phức tạp to, chạy chậm, nhưng khi data sieu nhỏ, thì chạy luôn nestedloop vì overhead cost thấp, hash chạy nhanh nhưng lại dùng RAM to. Sort merge thì phải sort, vậy nếu có sẵn sort nhờ index, thì nên chọn cái nào.
Rồi làm sao nó nó biết được cái nào n to n nhỏ, đi qua 1 loạt operation, đến operation sau làm sao biết được data to nhỏ mà tính thuật toán + cung cấp resource đủ. Cấp k đủ resource thì spill.
Spill hoặc là plan không hợp lí thì hoặc là can thiệp vào statistics, hoặc là manual control nếu hết cách.
Kiểu vậy.
ngoài cái ssms thì các tool khác không có hả anh ví dụ trước em có dùng workbench chạy mysql thì có cái execution plan này không ạ
meekoo
Senior Member
Giới trẻ bây giờ hỏi chat GPT nhiều nên ko biết dùng google thì phải.
View attachment 2492681Rất xin lỗi anh em sẽ chú ý hơn ạ)) tại em tưởng các anh đang trao đổi nên muốn hỏi luôn, lỗi của em ạ
chiyeuemthoi
Senior Member
fen xem hết chưa, h nhảy vô thì xem từ đâu nhỉ thấy nhiều quá kbt start ở đâu
Em xem từ cái list đầu tiên trong kênh ấy ạ hay lắmfen xem hết chưa, h nhảy vô thì xem từ đâu nhỉ thấy nhiều quá kbt start ở đâu
DauDau2021
Senior Member
hay quá. Bác làm 1 series về tối ưu SQL điĐể bạn biết query đó được thực hiện thế nào thì bạn phải hiểu execution plan. Đọc hiểu execution plan là cả 1 nghệ thuật. Nhiều người cứ nói chứ muốn nhanh thì đánh... index là xong
Câu query bạn viết là logical, nghĩa là kết quả sẽ trả về theo logic mong muốn mà bạn viết. Còn thực tế chạy thế nào thì bạn phải xem execution plan. Bạn nhìn vào đó bạn nhìn thấy scan, seek, nested loop, hash join, sort-merge join, stream aggregate, hash aggregate, parallelism, window function.... Vấn đề là bạn phải biết các thuật toán đó giải bằng tay thế nào thì bạn sẽ biết hiểu execution plan.
VD scan quét từ đầu đến cuối O(n), seek O(nlogn), nhưng chuyện gì xảy ra nếu n siêu nhỏ? trong khi seek phải traverse đọc từ root xuống leaf. Chuyện gì xảy ra nếu bạn phải seek n lần? Hay có sẵn index đấy, nhưng range seek siêu to, index đó lại là clustered index full data IO to tướng trong khi cái index khác không sort nhưng chỉ có vài column và đúng column bạn đang cần dùng để tính toán.
Hay như khi join, nested loop độ phức tạp to, chạy chậm, nhưng khi data sieu nhỏ, thì chạy luôn nestedloop vì overhead cost thấp, hash chạy nhanh nhưng lại dùng RAM to. Sort merge thì phải sort, vậy nếu có sẵn sort nhờ index, thì nên chọn cái nào.
Rồi làm sao nó nó biết được cái nào n to n nhỏ, đi qua 1 loạt operation, đến operation sau làm sao biết được data to nhỏ mà tính thuật toán + cung cấp resource đủ. Cấp k đủ resource thì spill.
Spill hoặc là plan không hợp lí thì hoặc là can thiệp vào statistics, hoặc là manual control nếu hết cách.
Kiểu vậy.
Coder quèn đang giãy dụa
Junior Member
nhớ là có explain gì ấy thì phải
Coder quèn đang giãy dụa
Junior Member
tôi để lại 1 tia thần thức ở đây để hóng cao nhân :v
rất cảm ơn bác ạ
Warrior Roger
Senior Member
tôi cũng để lại 1 tia thần thức ở đây để hóng cao nhân
Similar threads
