1 số thắc mắc về sql

1/ Select chính xác cột cần lấy sẽ nhanh hơn, nếu được khai báo index sẽ càng nhanh hơn nữa.
2/ Việc xài nhiều where hay ít where tuỳ vào mức filter của bạn, chứ ko phải vì nhanh hay chậm mà xài nhiều hay ít
3/ Cần xác định rõ cái đơn nghỉ phép của bạn có nhiều records ko rồi mới tính tiếp đc.

Khi query nhiều coloumn sẽ tốn nhiều bộ nhớ và chậy chậm hơn.
Đặc biệt đối với 1 số CSDL hiện đại, khi sử dụng khi sử dụng “in-memory” trên columns, thì khi query trên những columns đó sẽ nhanh hơn đáng kể.

Ko liên qua với nhau lắm thì phải.
Về lý thuyết có nhiều điều kiện lọc hơn => nhiều phép so sánh hơn => chạy chộm hơn.
Tuy nhiên, thực tế nếu đặt nhiều “where” thích hợp trong các câu subqueries để làm giảm số records khi thực hiện các phép join/filter trong outer-queries, có thể giúp làm câu query chạy nhanh hơn.

Trừ khi bạn viết hay hơn các “cụ” sảm xuất ra csdl đó, ko thì nên học cách xài indexes + tối ưu câu queries sẽ tốt hơn.

• Những câu hỏi đều về performance nên rất khó trả lời chính xác vì còn tùy vào Hệ Quản Trị CSDL (HQT-CSDL) và tình huống cụ thể. nhưng mình sẽ trả lời theo kinh nghiệm chung của mình

1 . khi chạy 1 câu query thì nếu ta dùng select * và select chính xác các cột cần lấy thì cái nào sẽ chạy nhanh hơn ?

• Theo như hiểu biết của mình thì Select từng cột sẽ cho kết quả nhanh hơn
• Vì:
  • Trong hệ quản trị trước khi thực hiện bất kỳ câu Query nào đều trải qua một bước là tối ưu hóa câu truy vấn.
  • Khi select * mặc nhiên tất cả các column sẽ được HQT-CSDL lấy hết và đo đó số lượng data output sẽ lớn
  • Khi Select từng cột HQT-CSDL chỉ lọc những cột có tham gia trong câu Query nên sẽ nhẹ hàng hơn. Tuy nhiên nếu bạn select từng cột nhưng số lượng bằng với select * thì cơ bản là như nhau
• Việc performance của câu Query ngoài vấn đề execute Query còn nhiều yếu tố khác.
  • Khi bạn chỉ output 10 record hay 1 tỷ record chắc chắn là khác biệt rồi
  • Nếu output ra trên máy local thì tốc độ sẽ khác so với output về máy client
  • Query trên Hệ CSDL phân tán cũng khác với Hệ CSDL tập trung

2. càng nhiều đk where sẽ chạy nhanh hơn hay càng ít đk where sẽ chạy nhanh hơn

• Điều này không chắc, còn tuy thuộc vào điều kiện where là gì:
  VD: NHAN_VIEN (ID, ma_phongban, name): ID là khóa chính:
  • Giả sử trong trường hợp này bạn cần lấy thông tin của nhân viên và đã có ID nhân viên và [Mã phòng ban] của nhân viên đó:
    • SQL1: SELECT * FROM NHAN_VIEN WHERE ID = [ID nhân viên]
    • SQL2: SELECT * FROM NHAN_VIEN WHERE ID = [ID nhân viên] AND ma_phongban = [Mã phòng ban]
  • Xét 2 câu SQL1 trên thì trong trường hợp này câu SQL1 sẽ cho kết quả nhanh hơn vì bạn đã compare trực tiếp khóa chính
  • Câu SQL2 ngoài thực hiên lại như câu 1 còn phải compare thêm 1 điều kiện phòng ban (giả định đây là điều kiện thừa)
• Ngoài ra kiểu dữ liệu khi của cột trong điều kiện WHERE cũng sẽ có tốc độ khác nhau. kiểu chuổi sẽ compare chậm hơn số
• Tóm lại: để chạy nhanh không phải cần điều kiện ít hơn hay nhiều hơn mà phải là vừa đủ. không thừa không thiếu

3. tự viết code để tìm bằng các thuật toán tìm kiếm ngay trong chương trình sẽ nhanh hơn hay chạy câu query để hệ quản trị tìm sẽ nhanh hơn

• Việc viết giải thuật ở trong SQL hay ở code cũng là bài toàn đau đầu bao thế hệ coder . Theo kinh nghệm của mình. viết ở đâu không quan trọng, quan trọng là phải cân đối giữa client và server
• vấn đề 1:
  • Việc viết qua nhiều xử lý logic trong SQL làm gánh nặng cho Server chạy DB trong khi client có rất nhiều nhưng Server DB đa phần là 1.
  • Việc viết quá nhiều SQL logic dẫn đến khó khăn khi bảo trì nhất là khi có nhu cầu đổi DB (vd: MYSQL -> ORACEL) sẽ là 1 cực hình
• vấn đề 2:
  • Nếu như đem tất cả các xử lý query cụ thể hơn là điều kiện tìm kiếm vào xử lý trong code thì lúc này Server DB chỉ select nhưng SQL rất đơn giản có khi là select * thì lúc này sẽ phát sinh data thừa khi select
  • Khi phát sinh data thừa thì: tốn bộ nhớ cho nó, tốn đường truyền là đata không cần thiết, và tốn xử lý cho những data thừa
• Tóm lại: phải cân đối giữa số lượng người dùng với hệ thống.
  P/S: không có câu trả lời chính xác cho câu này

ok thanks mấy anh…