it-swarm-vi.tech

Cái nào nhanh hơn / tốt nhất? CHỌN * hoặc CHỌN cột1, colum2, cột3, v.v.

Tôi đã nghe nói rằng SELECT * nói chung là sử dụng không tốt khi viết các lệnh SQL vì nó hiệu quả hơn đối với các cột SELECT mà bạn đặc biệt cần.

Nếu tôi cần SELECT mỗi cột trong bảng, tôi có nên sử dụng

SELECT * FROM TABLE

hoặc là

SELECT column1, colum2, column3, etc. FROM TABLE

Liệu hiệu quả thực sự quan trọng trong trường hợp này? Tôi nghĩ rằng SELECT * sẽ tối ưu hơn trong nội bộ nếu bạn thực sự cần tất cả dữ liệu, nhưng tôi đang nói điều này mà không có sự hiểu biết thực sự về cơ sở dữ liệu.

Tôi tò mò muốn biết thực hành tốt nhất là gì trong trường hợp này.

CẬP NHẬT : Tôi có lẽ nên xác định rằng tình huống duy nhất mà tôi thực sự muốn thực hiện SELECT * là khi tôi chọn dữ liệu từ một bảng trong đó tôi biết tất cả các cột sẽ luôn cần được truy xuất, ngay cả khi các cột mới được thêm vào.

Tuy nhiên, với những phản hồi tôi đã thấy, đây vẫn có vẻ là một ý tưởng tồi và SELECT * không bao giờ nên được sử dụng cho nhiều lý do kỹ thuật mà tôi từng nghĩ đến.

155
Dan Herbert

Một lý do khiến việc chọn các cột cụ thể tốt hơn là vì nó tăng xác suất SQL Server có thể truy cập dữ liệu từ các chỉ mục thay vì truy vấn dữ liệu bảng.

Đây là một bài đăng tôi đã viết về nó: Lý do thực sự chọn truy vấn là phạm vi chỉ số xấu

Nó cũng ít dễ thay đổi hơn, vì bất kỳ mã nào sử dụng dữ liệu sẽ có cùng cấu trúc dữ liệu bất kể thay đổi bạn thực hiện đối với lược đồ bảng trong tương lai.

158
Jon Galloway

Cho của bạn thông số kỹ thuật mà bạn đang chọn tất cả các cột, có rất ít sự khác biệt tại thời điểm này. Tuy nhiên, nhận ra rằng các lược đồ cơ sở dữ liệu thay đổi. Nếu bạn dùng SELECT * bạn sẽ nhận được bất kỳ cột mới nào được thêm vào bảng, mặc dù trong tất cả khả năng, mã của bạn không được chuẩn bị để sử dụng hoặc trình bày dữ liệu mới đó. Điều này có nghĩa là bạn đang phơi bày hệ thống của mình trước những thay đổi về hiệu năng và chức năng không mong muốn.

Bạn có thể sẵn sàng loại bỏ điều này như một chi phí nhỏ, nhưng nhận ra rằng các cột mà bạn không cần vẫn phải là:

  1. Đọc từ cơ sở dữ liệu
  2. Gửi qua mạng
  3. Tham gia vào quá trình của bạn
  4. (đối với công nghệ loại ADO) Được lưu trong bảng dữ liệu trong bộ nhớ
  5. Bỏ qua và loại bỏ/thu gom rác

Mục số 1 có nhiều chi phí ẩn bao gồm loại bỏ một số chỉ số che phủ tiềm năng, gây ra tải trang dữ liệu (và đập bộ đệm máy chủ), phát sinh khóa hàng/trang/bảng có thể tránh được.

Cân bằng điều này với mức tiết kiệm tiềm năng của việc chỉ định các cột so với * và khoản tiết kiệm tiềm năng duy nhất là:

  1. Lập trình viên không cần phải xem lại SQL để thêm các cột
  2. Truyền tải mạng của SQL nhỏ hơn/nhanh hơn
  3. Thời gian xác thực/phân tích truy vấn SQL Server
  4. Bộ đệm truy vấn SQL Server

Đối với mục 1, thực tế là bạn sẽ thêm/thay đổi mã để sử dụng bất kỳ cột mới nào mà bạn có thể thêm vào, vì vậy đây là một rửa.

Đối với mục 2, sự khác biệt hiếm khi đủ để đẩy bạn vào một gói hoặc số gói mạng khác nhau. Nếu bạn đi đến điểm mà thời gian truyền câu lệnh SQL là vấn đề chính, có lẽ bạn cần phải giảm tốc độ của câu lệnh trước.

Đối với mục 3, KHÔNG có khoản tiết kiệm nào khi mở rộng * dù sao cũng phải xảy ra, điều đó có nghĩa là tham khảo lược đồ (các) bảng. Trên thực tế, việc liệt kê các cột sẽ phải chịu cùng một chi phí vì chúng phải được xác nhận theo lược đồ. Nói cách khác, đây là một rửa hoàn toàn.

Đối với mục 4, khi bạn chỉ định các cột cụ thể, bộ đệm của kế hoạch truy vấn của bạn có thể lớn hơn nhưng chỉ nếu bạn đang xử lý các nhóm cột khác nhau (không phải là những gì bạn đã chỉ định). Trong trường hợp này, bạn muốn các mục bộ đệm khác nhau vì bạn muốn các gói khác nhau khi cần.

Vì vậy, tất cả điều này xảy ra, bởi vì cách bạn đã chỉ định câu hỏi, cho khả năng phục hồi vấn đề khi đối mặt với các sửa đổi lược đồ cuối cùng. Nếu bạn đang ghi lược đồ này vào ROM (nó xảy ra), thì * là hoàn toàn chấp nhận được.

Tuy nhiên, hướng dẫn chung của tôi là bạn chỉ nên chọn các cột bạn cần, điều đó có nghĩa là đôi khi sẽ giống như bạn đang yêu cầu tất cả chúng, nhưng các DBA và tiến hóa lược đồ có nghĩa là một số cột mới có thể xuất hiện có thể ảnh hưởng lớn đến truy vấn.

Lời khuyên của tôi là bạn nên LUÔN CHỌN các cột cụ thể. Hãy nhớ rằng bạn giỏi về những gì bạn làm đi làm lại, vì vậy hãy tập thói quen làm đúng.

Nếu bạn đang tự hỏi tại sao một lược đồ có thể thay đổi mà không thay đổi mã, hãy nghĩ về việc ghi nhật ký kiểm toán, ngày hiệu lực/ngày hết hạn và những thứ tương tự khác được DBAs thêm vào cho các vấn đề tuân thủ một cách có hệ thống. Một nguồn thay đổi ngầm khác là sự không chuẩn hóa cho hiệu suất ở những nơi khác trong hệ thống hoặc các trường do người dùng xác định.

57
IDisposable

Bạn chỉ nên chọn các cột mà bạn cần. Ngay cả khi bạn cần tất cả các cột, vẫn nên liệt kê tên cột để máy chủ sql không phải truy vấn bảng hệ thống cho các cột.

Ngoài ra, ứng dụng của bạn có thể bị hỏng nếu ai đó thêm các cột vào bảng. Chương trình của bạn sẽ nhận được các cột mà nó không mong đợi quá và nó có thể không biết cách xử lý chúng.

Ngoài ra, nếu bảng có cột nhị phân thì truy vấn sẽ chậm hơn nhiều và sử dụng nhiều tài nguyên mạng hơn.

33
Giorgi

Có bốn lý do lớn mà select * là một điều xấu:

  1. Lý do thực tế quan trọng nhất là nó buộc người dùng phải biết một cách kỳ diệu thứ tự các cột sẽ được trả về. Tốt hơn hết là nên nói rõ, điều này cũng bảo vệ bạn trước sự thay đổi của bảng, điều này giúp phân biệt thành ...

  2. Nếu tên cột bạn đang sử dụng thay đổi, tốt hơn là nên bắt sớm (tại thời điểm gọi SQL) thay vì khi bạn đang cố sử dụng cột không còn tồn tại (hoặc đã thay đổi tên, v.v. )

  3. Liệt kê các tên cột làm cho mã của bạn tự ghi lại nhiều hơn và do đó có thể dễ đọc hơn.

  4. Nếu bạn chuyển qua mạng (hoặc thậm chí nếu bạn không), các cột bạn không cần chỉ là lãng phí.

30
pkh

Chỉ định danh sách cột là thường tùy chọn tốt nhất vì ứng dụng của bạn sẽ không bị ảnh hưởng nếu ai đó thêm/chèn một cột vào bảng.

9
ilitirit

Chỉ định tên cột chắc chắn là nhanh hơn - cho máy chủ. Nhưng nếu

  1. hiệu suất không phải là vấn đề lớn (ví dụ: đây là cơ sở dữ liệu nội dung trang web với hàng trăm, có thể hàng nghìn - nhưng không phải hàng triệu - hàng trong mỗi bảng); VÀ
  2. công việc của bạn là tạo nhiều ứng dụng nhỏ, tương tự (ví dụ: các trang web được quản lý nội dung hướng tới công chúng) bằng cách sử dụng một khung chung, thay vì tạo một ứng dụng một lần phức tạp; VÀ
  3. tính linh hoạt là quan trọng (rất nhiều tùy chỉnh của lược đồ db cho từng trang web);

sau đó, tốt hơn hết bạn nên gắn bó với CHỌN *. Trong khuôn khổ của chúng tôi, việc sử dụng CHỌN * cho phép chúng tôi giới thiệu trường nội dung được quản lý trang web mới vào một bảng, mang lại cho nó tất cả các lợi ích của CMS (phiên bản, quy trình làm việc/phê duyệt, v.v.), trong khi chỉ chạm vào mã tại vài điểm, thay vì vài chục điểm.

Tôi biết các bậc thầy về DB sẽ ghét tôi vì điều này - hãy tiếp tục, bỏ phiếu cho tôi - nhưng trong thế giới của tôi, thời gian của nhà phát triển rất khan hiếm và chu kỳ CPU rất phong phú, vì vậy tôi điều chỉnh theo những gì tôi bảo tồn và những gì tôi lãng phí.

7
Herb Caudill

CHỌN * là một thực tiễn xấu ngay cả khi truy vấn không được gửi qua mạng.

  1. Chọn nhiều dữ liệu hơn bạn cần làm cho truy vấn kém hiệu quả hơn - máy chủ phải đọc và truyền thêm dữ liệu, do đó sẽ mất thời gian và tạo tải không cần thiết trên hệ thống (không chỉ mạng, như những người khác đã đề cập, mà cả đĩa, CPU, v.v. ). Ngoài ra, máy chủ không thể tối ưu hóa truy vấn cũng như có thể (ví dụ: sử dụng chỉ mục che cho truy vấn).
  2. Sau một thời gian, cấu trúc bảng của bạn có thể thay đổi, vì vậy CHỌN * sẽ trả về một nhóm cột khác. Vì vậy, ứng dụng của bạn có thể nhận được một tập dữ liệu về cấu trúc không mong muốn và phá vỡ ở đâu đó. Việc nêu rõ các cột đảm bảo rằng bạn có được một tập dữ liệu về cấu trúc đã biết hoặc nhận được một lỗi rõ ràng ở cấp cơ sở dữ liệu (như 'không tìm thấy cột').

Tất nhiên, tất cả điều này không quan trọng lắm đối với một hệ thống nhỏ và đơn giản.

6
VladV

Hiệu suất khôn ngoan, CHỌN với các cột cụ thể có thể nhanh hơn (không cần đọc trong tất cả dữ liệu). Nếu truy vấn của bạn thực sự sử dụng TẤT CẢ các cột, thì CHỌN với các tham số rõ ràng vẫn được ưu tiên. Bất kỳ sự khác biệt về tốc độ sẽ về cơ bản là không đáng chú ý và gần thời gian liên tục. Một ngày nào đó lược đồ của bạn sẽ thay đổi, và đây là bảo hiểm tốt để ngăn chặn các vấn đề do điều này.

4
Yann Ramin

Rất nhiều lý do chính đáng được trả lời ở đây cho đến nay, đây là một lý do khác chưa được đề cập.

Đặt tên rõ ràng cho các cột sẽ giúp bạn bảo trì xuống đường. Tại một số điểm, bạn sẽ thực hiện thay đổi hoặc khắc phục sự cố và thấy mình hỏi "cột đó được sử dụng ở đâu".

Nếu bạn đã có tên được liệt kê rõ ràng, thì việc tìm mọi tham chiếu đến cột đó - thông qua tất cả các quy trình, chế độ xem được lưu trữ, v.v. - rất đơn giản. Chỉ cần kết xuất tập lệnh CREATE cho lược đồ DB của bạn và tìm kiếm văn bản thông qua nó.

4
Chris Wuestefeld

Bạn thực sự chỉ nên chọn các lĩnh vực bạn cần và chỉ số lượng được yêu cầu, tức là.

SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)

Bên ngoài cơ sở dữ liệu, các truy vấn động có nguy cơ bị tấn công tiêm và dữ liệu không đúng định dạng. Thông thường, bạn có được vòng này bằng cách sử dụng các thủ tục được lưu trữ hoặc truy vấn tham số. Ngoài ra (mặc dù không thực sự có quá nhiều vấn đề), máy chủ phải tạo một kế hoạch thực hiện mỗi khi một truy vấn động được thực thi.

4
Matthew Abbott

Vấn đề với "select *" là khả năng mang lại dữ liệu bạn không thực sự cần. Trong truy vấn cơ sở dữ liệu thực tế, các cột được chọn không thực sự thêm vào tính toán. Điều thực sự "nặng nề" là việc truyền dữ liệu trở lại máy khách của bạn và bất kỳ cột nào bạn không thực sự cần chỉ là lãng phí băng thông mạng và thêm vào thời gian bạn chờ bạn truy vấn để trả về.

Ngay cả khi bạn sử dụng tất cả các cột được mang từ "select * ...", thì đó chỉ là bây giờ. Nếu trong tương lai bạn thay đổi bố cục bảng/dạng xem và thêm nhiều cột khác, bạn sẽ bắt đầu mang theo những thứ bạn chọn ngay cả khi bạn không cần chúng.

Một điểm khác trong đó một câu lệnh "select *" là xấu khi tạo chế độ xem. Nếu bạn tạo chế độ xem bằng cách sử dụng "select *" và sau đó thêm các cột vào bảng của mình, định nghĩa chế độ xem và dữ liệu được trả về sẽ không khớp và bạn sẽ cần biên dịch lại các chế độ xem của mình để chúng hoạt động trở lại.

Tôi biết rằng việc viết "chọn *" rất hấp dẫn, vì tôi thực sự không muốn chỉ định thủ công tất cả các trường trên các truy vấn của mình, nhưng khi hệ thống của bạn bắt đầu phát triển, bạn sẽ thấy rằng đáng để dành thêm thời gian này/nỗ lực trong việc chỉ định các lĩnh vực thay vì dành nhiều thời gian và nỗ lực hơn để loại bỏ các lỗi trên quan điểm của bạn hoặc tối ưu hóa ứng dụng của bạn.

3
Alexandre Brasil

Mặc dù các cột liệt kê rõ ràng là tốt cho hiệu suất, nhưng đừng có điên.

Vì vậy, nếu bạn sử dụng tất cả dữ liệu, hãy thử CHỌN * để đơn giản (hãy tưởng tượng có nhiều cột và thực hiện một truy vấn THAM GIA ... có thể trở nên khủng khiếp). Sau đó - đo lường. So sánh với truy vấn với tên cột được liệt kê rõ ràng.

Đừng suy đoán về hiệu suất, đo lường nó!

Danh sách rõ ràng giúp ích nhiều nhất khi bạn có một số cột chứa dữ liệu lớn (như nội dung của bài đăng hoặc bài viết) và không cần nó trong truy vấn nhất định. Sau đó, bằng cách không trả lại nó trong câu trả lời, máy chủ DB của bạn có thể tiết kiệm thời gian, băng thông và thông lượng đĩa. Kết quả truy vấn của bạn cũng sẽ nhỏ hơn, tốt cho mọi bộ đệm truy vấn.

3
Paweł Hajdan

chắc chắn xác định các cột, bởi vì SQL Server sẽ không phải tìm kiếm trên các cột để kéo chúng. Nếu bạn xác định các cột, thì SQL có thể bỏ qua bước đó.

3
Nick Berardi

Luôn luôn tốt hơn để chỉ định các cột bạn cần, nếu bạn nghĩ về nó một lần, SQL không phải nghĩ "wtf là *" mỗi khi bạn truy vấn. Trên hết, ai đó sau này có thể thêm các cột vào bảng mà bạn thực sự không cần trong truy vấn của mình và bạn sẽ tốt hơn trong trường hợp đó bằng cách chỉ định tất cả các cột của mình.

3
BrewinBombers

Chọn là hiệu quả tương đương (về vận tốc) nếu bạn sử dụng * hoặc cột.

Sự khác biệt là về bộ nhớ, không phải vận tốc. Khi bạn chọn một số cột, SQL Server phải phân bổ không gian bộ nhớ để phục vụ bạn truy vấn, bao gồm tất cả dữ liệu cho tất cả các cột mà bạn đã yêu cầu, ngay cả khi bạn chỉ sử dụng một trong số chúng.

Điều quan trọng về mặt hiệu suất là kế hoạch thực hiện, điều này phụ thuộc rất nhiều vào mệnh đề WHERE của bạn và số lượng THAM GIA, NGOÀI THAM GIA, v.v ...

Đối với câu hỏi của bạn chỉ cần sử dụng CHỌN *. Nếu bạn cần tất cả các cột thì không có sự khác biệt về hiệu suất.

2
Jorge Córdoba

Kết quả là quá lớn. Việc tạo và gửi kết quả từ công cụ SQL đến máy khách là chậm.

Phía máy khách, là một môi trường lập trình chung, không và không nên được thiết kế để lọc và xử lý kết quả (ví dụ: mệnh đề WHERE, mệnh đề ORDER), vì số lượng hàng có thể rất lớn (ví dụ: hàng chục triệu hàng).

2
kennytm

Đặt tên cho mỗi cột mà bạn mong muốn nhận được trong ứng dụng của mình cũng đảm bảo ứng dụng của bạn sẽ không bị hỏng nếu có ai đó thay đổi bảng, miễn là các cột của bạn vẫn còn (theo bất kỳ thứ tự nào).

2
Don

KHÔNG nhanh hơn khi sử dụng tên trường rõ ràng so với *, nếu và chỉ khi, bạn cần lấy dữ liệu cho tất cả các trường.

Phần mềm máy khách của bạn không nên phụ thuộc vào thứ tự của các trường được trả về, do đó, điều đó cũng vô nghĩa.

Và có thể (mặc dù không chắc) rằng bạn cần có được tất cả các trường bằng cách sử dụng * vì bạn chưa biết trường nào tồn tại (nghĩ cấu trúc cơ sở dữ liệu rất năng động).

Một nhược điểm khác của việc sử dụng tên trường rõ ràng là nếu có nhiều tên trong số chúng và chúng dài thì việc đọc mã và/hoặc nhật ký truy vấn trở nên khó khăn hơn.

Vì vậy, quy tắc nên là: nếu bạn cần tất cả các trường, hãy sử dụng *, nếu bạn chỉ cần một tập hợp con, hãy đặt tên cho chúng một cách rõ ràng.

2
user9385

Nó phụ thuộc vào phiên bản máy chủ DB của bạn, nhưng các phiên bản SQL hiện đại có thể lưu trữ kế hoạch theo bất kỳ cách nào. Tôi muốn nói đi với bất cứ điều gì có thể duy trì nhất với mã truy cập dữ liệu của bạn.

1
Keith

Một lý do tốt hơn là bạn nên đánh vần chính xác cột nào bạn muốn là vì những thay đổi có thể xảy ra trong cấu trúc bảng.

Nếu bạn đang đọc dữ liệu theo cách thủ công bằng cách sử dụng cách tiếp cận dựa trên chỉ mục để điền vào cấu trúc dữ liệu với kết quả truy vấn của bạn, thì trong tương lai khi bạn thêm/xóa một cột, bạn sẽ phải đau đầu khi cố gắng tìm ra lỗi sai.

Đối với những gì nhanh hơn, tôi sẽ trì hoãn cho người khác về chuyên môn của họ.

1
dpollock

Và hãy nhớ nếu bạn có một phép nối bên trong theo định nghĩa, bạn không cần tất cả các cột vì dữ liệu trong các cột nối được lặp lại.

Nó không giống như các cột liệt kê trong máy chủ SQl là khó khăn hoặc thậm chí tốn thời gian. Bạn chỉ cần kéo chúng từ trình duyệt đối tượng (bạn có thể lấy tất cả trong một lần bằng cách kéo từ các cột Word). Để đạt được hiệu suất vĩnh viễn trên hệ thống của bạn (vì điều này có thể làm giảm việc sử dụng các chỉ mục và vì việc gửi dữ liệu không cần thiết qua mạng là tốn kém) và có nhiều khả năng bạn sẽ gặp sự cố không mong muốn khi cơ sở dữ liệu thay đổi (đôi khi các cột được thêm vào bạn không muốn người dùng nhìn thấy chẳng hạn) chỉ để tiết kiệm ít hơn một phút thời gian phát triển là thiển cận và không chuyên nghiệp.

1
HLGEM

Những gì mọi người ở trên đã nói, cộng thêm:

Nếu bạn đang phấn đấu để có thể đọc được mã có thể bảo trì, hãy làm một cái gì đó như:

CHỌN foo, thanh TỪ các vật dụng;

là ngay lập tức có thể đọc và hiển thị ý định. Nếu bạn thực hiện cuộc gọi đó, bạn biết những gì bạn sẽ nhận lại. Nếu các widget chỉ có các cột foo và bar, thì việc chọn * có nghĩa là bạn vẫn phải suy nghĩ về những gì bạn sẽ nhận lại, xác nhận thứ tự được ánh xạ chính xác, v.v. Tuy nhiên, nếu các widget có nhiều cột hơn nhưng bạn chỉ quan tâm đến foo và thanh, sau đó mã của bạn trở nên lộn xộn khi bạn truy vấn ký tự đại diện và sau đó chỉ sử dụng một số thứ được trả về.

1
Faisal

CHỌN * là cần thiết nếu một người muốn có được siêu dữ liệu, chẳng hạn như số lượng cột.

1
Mark Etable

Để thêm vào những gì mọi người khác đã nói, nếu tất cả các cột mà bạn đang chọn được đưa vào một chỉ mục, tập kết quả của bạn sẽ được lấy từ chỉ mục thay vì tìm kiếm dữ liệu bổ sung từ SQL.

1
Mike

Như với hầu hết các vấn đề, nó phụ thuộc vào những gì bạn muốn đạt được. Nếu bạn muốn tạo một lưới db sẽ cho phép tất cả các cột trong bất kỳ bảng nào, thì "Chọn *" là câu trả lời. Tuy nhiên, nếu bạn sẽ chỉ cần một số cột nhất định và việc thêm hoặc xóa các cột khỏi truy vấn được thực hiện không thường xuyên, sau đó chỉ định chúng riêng lẻ.

Nó cũng phụ thuộc vào lượng dữ liệu bạn muốn chuyển từ máy chủ. Nếu một trong các cột được xác định là ghi nhớ, đồ họa, blob, v.v. và bạn không cần cột đó, tốt nhất bạn không nên sử dụng "Chọn *" hoặc bạn sẽ nhận được cả đống dữ liệu mà bạn không muốn và hiệu suất của bạn có thể bị ảnh hưởng.

1
Mark

Việc vấn đề hiệu quả có phụ thuộc rất nhiều vào quy mô của bộ dữ liệu sản xuất của bạn (và tốc độ tăng trưởng của chúng). Nếu bộ dữ liệu của bạn sẽ không lớn như vậy và chúng sẽ không phát triển nhanh như vậy, có thể không có nhiều lợi thế về hiệu suất để chọn các cột riêng lẻ.

Với bộ dữ liệu lớn hơn và tốc độ tăng trưởng dữ liệu nhanh hơn, lợi thế về hiệu suất ngày càng trở nên quan trọng.

Để xem đồ họa có khác biệt hay không, tôi khuyên bạn nên sử dụng bộ phân tích truy vấn để xem kế hoạch thực hiện truy vấn cho SELECT * và tương đương SELECT col1, col2, v.v. Điều đó sẽ cho bạn biết hai truy vấn nào hiệu quả hơn. Bạn cũng có thể tạo một số dữ liệu thử nghiệm với các khối lượng khác nhau để xem thời gian là gì.

0
Scott Lawrence

Gonna bị đánh sập vì điều này, nhưng tôi chọn * vì hầu như tất cả dữ liệu của tôi được truy xuất từ ​​Chế độ xem SQL Server, kết hợp các giá trị cần thiết từ nhiều bảng thành một chế độ dễ truy cập.

Sau đó, tôi muốn tất cả các cột từ chế độ xem sẽ không thay đổi khi các trường mới được thêm vào các bảng bên dưới. Điều này có thêm lợi ích là cho phép tôi thay đổi dữ liệu đến từ đâu. FieldA trong Chế độ xem có thể được tính toán tại một thời điểm và sau đó tôi có thể thay đổi nó thành tĩnh. Dù bằng cách nào, View cung cấp FieldA cho tôi.

Cái hay của việc này là nó cho phép lớp dữ liệu của tôi lấy các tập dữ liệu. Sau đó nó chuyển chúng đến BL của tôi để có thể tạo các đối tượng từ chúng. Ứng dụng chính của tôi chỉ biết và tương tác với các đối tượng. Tôi thậm chí còn cho phép các đối tượng của mình tự tạo khi thông qua một datarow.

Tất nhiên, tôi là nhà phát triển duy nhất, vì vậy điều đó cũng giúp :)

0
klkitchens

Hoàn toàn xác định các cột bạn muốn CHỌN mỗi lần. Không có lý do gì để không và cải thiện hiệu suất là hoàn toàn xứng đáng.

Họ không bao giờ nên đưa ra tùy chọn "CHỌN *"

0
cazlab

Nếu bạn cần mỗi cột thì chỉ cần sử dụng CHỌN * nhưng hãy nhớ rằng thứ tự có thể có khả năng thay đổi để khi bạn tiêu thụ kết quả, hãy truy cập chúng theo tên chứ không phải theo chỉ mục.

Tôi sẽ bỏ qua các nhận xét về cách * cần phải lấy danh sách - cơ hội phân tích cú pháp và xác thực các cột có tên bằng với thời gian xử lý nếu không nhiều hơn. Đừng tối ưu hóa sớm ;-)

0
DamienG

Sự khác biệt chính giữa hai là lượng dữ liệu được truyền qua lại. Bất kỳ đối số nào về chênh lệch thời gian đều bị thiếu sót một cách cơ bản trong đó "select *" và "select col1, ..., colN" dẫn đến cùng một lượng công việc tương đối được thực hiện bởi công cụ DB. Tuy nhiên, truyền 15 cột mỗi hàng so với 5 cột mỗi hàng là chênh lệch 10 cột.

0
Jeff Hubbard

Về hiệu quả thực thi tôi không nhận thấy sự khác biệt đáng kể nào. Nhưng để hiệu quả cho lập trình viên, tôi sẽ viết tên của các trường vì

  • Bạn biết thứ tự nếu bạn cần lập chỉ mục theo số hoặc nếu trình điều khiển của bạn cư xử hài hước trên các giá trị blob và bạn cần một thứ tự xác định
  • Bạn chỉ đọc các trường bạn cần, nếu bạn cần thêm nhiều trường
  • Bạn gặp lỗi sql nếu bạn viết sai chính tả hoặc đổi tên trường, không phải là giá trị trống từ recordset/row
  • Bạn có thể đọc tốt hơn những gì đang xảy ra.
0
Erik

Tôi thấy rằng một số người dường như nghĩ rằng phải mất nhiều thời gian hơn để chỉ định các cột. Vì bạn có thể kéo danh sách cột từ trình duyệt đối tượng, có thể mất thêm một phút để chỉ định các cột (đó là nếu bạn có nhiều cột và cần dành thời gian để đặt chúng trên các dòng riêng biệt) trong truy vấn. Tại sao mọi người nghĩ rằng rất tốn thời gian?

0
HLGEM

Tôi luôn khuyên bạn nên chỉ định các cột bạn cần, chỉ trong trường hợp lược đồ của bạn thay đổi và bạn không cần cột thêm.

Ngoài ra, đủ điều kiện tên cột với tên bảng. Điều này rất quan trọng khi truy vấn có chứa tham gia. Nếu không có trình độ bảng, có thể khó nhớ được cột nào đến từ bảng nào và việc thêm một cột có tên tương tự vào một trong các bảng khác có thể phá vỡ truy vấn của bạn.

0
mxsscott

Hiệu suất khôn ngoan Tôi đã thấy ý kiến ​​rằng cả hai đều bằng nhau. nhưng khía cạnh khả năng sử dụng có một số + và

Khi bạn sử dụng (select *) trong truy vấn và nếu một số thay đổi bảng và thêm các trường mới không cần cho truy vấn trước đó thì đó là một chi phí không cần thiết. Và nếu trường mới được thêm vào là một đốm màu hoặc trường hình ảnh thì sao ??? thời gian phản hồi truy vấn của bạn sẽ rất chậm.

Mặt khác, nếu bạn sử dụng (chọn col1, col2, ..) và nếu bảng bị thay đổi và thêm các trường mới và nếu các trường đó là cần thiết trong tập kết quả, bạn luôn cần chỉnh sửa truy vấn đã chọn sau khi thay đổi bảng.

Nhưng tôi khuyên bạn nên luôn luôn sử dụng chọn col1, col2, ... trong các truy vấn của mình và thay đổi truy vấn nếu bảng bị thay đổi sau ...

0
Lahiru Cooray

Điều đặc biệt quan trọng đối với hiệu suất là không sử dụng select * khi bạn có tham gia becaseu theo định nghĩa ít nhất hai trường chứa cùng một dữ liệu. Bạn không muốn lãng phí tài nguyên mạng gửi dữ liệu mà bạn không cần từ máy chủ cơ sở dữ liệu đến ứng dụng hoặc máy chủ web. Nó có vẻ dễ dàng hơn để sử dụng select * nhưng đó là một thực tế xấu. Vì thật dễ dàng để kéo các tên cột vào truy vấn, thay vào đó chỉ cần làm điều đó.

Một vấn đề khác xảy ra khi sử dụng select * là có những kẻ ngốc chọn thêm các trường mới vào giữa bảng (luôn luôn là một thực tiễn xấu), nếu bạn sử dụng select * làm cơ sở cho việc chèn thì đột nhiên thứ tự cột của bạn có thể sai và bạn có thể cố gắng chèn số an sinh xã hội vào danh dự (số tiền mà người nói có thể được trả để chọn một ví dụ không ngẫu nhiên) có thể là một điều rất tệ cho tính toàn vẹn dữ liệu. Ngay cả khi lựa chọn không phải là chèn, nó vẫn có vẻ xấu đối với khách hàng khi dữ liệu đột nhiên theo thứ tự quan trọng trên báo cáo hoặc trang web.

Tôi nghĩ rằng không có trường hợp nào khi sử dụng select * thì tốt hơn là sử dụng danh sách cột. Bạn có thể nghĩ rằng việc bảo trì sẽ dễ dàng hơn, nhưng trên thực tế, điều đó không và sẽ dẫn đến việc ứng dụng của bạn trở nên chậm hơn mà không có lý do khi các trường bạn không cần được thêm vào các bảng. Bạn cũng sẽ phải đối mặt với vấn đề sửa chữa những thứ sẽ không bị hỏng nếu bạn đã sử dụng danh sách cột, vì vậy thời gian bạn lưu không thêm cột được sử dụng hết việc này.

0
HLGEM

này, hãy thực tế sử dụng select * khi tạo mẫu và chọn các cột cụ thể khi triển khai và triển khai. từ góc độ kế hoạch thực hiện, cả hai đều tương đối giống nhau trên các hệ thống hiện đại. tuy nhiên, việc chọn các cột cụ thể sẽ giới hạn lượng dữ liệu phải được truy xuất từ ​​đĩa, được lưu trong bộ nhớ và gửi qua mạng.

cuối cùng, kế hoạch tốt nhất là chọn các cột cụ thể.

0
siculars

Cũng giữ những thay đổi trong tâm trí. Hôm nay, Chọn * chỉ chọn các cột mà bạn cần, nhưng ngày mai, nó cũng có thể chọn cột varbinary (MAX) mà tôi vừa thêm mà không cho bạn biết và hiện bạn cũng đang truy xuất tất cả 3.18 Gigabyte Dữ liệu nhị phân không phải là trong bảng ngày hôm qua.

0
Michael Stum

Hãy nghĩ về cái nào nhanh hơn. Nếu bạn có thể chọn chỉ dữ liệu bạn cần thì nó sẽ nhanh hơn. Tuy nhiên, khi kiểm tra, bạn có thể lấy tất cả dữ liệu để đánh giá dữ liệu nào có thể được lọc dựa trên nhu cầu kinh doanh.

0
mikedopp

Có những trường hợp CHỌN * tốt cho mục đích bảo trì, nhưng nói chung nên tránh.

Đây là những trường hợp đặc biệt như chế độ xem hoặc thủ tục được lưu trữ trong đó bạn muốn thay đổi trong các bảng bên dưới để truyền bá mà không cần phải đi và thay đổi mọi chế độ xem và lưu trữ được sử dụng bảng. Thậm chí sau đó, điều này có thể tự gây ra vấn đề, như trong trường hợp bạn có hai chế độ xem được tham gia. Một bảng bên dưới thay đổi và bây giờ chế độ xem không rõ ràng vì cả hai bảng đều có một cột có cùng tên. (Lưu ý điều này có thể xảy ra bất cứ khi nào bạn không đủ điều kiện cho tất cả các cột có tiền tố bảng). Ngay cả với các tiền tố, nếu bạn có cấu trúc như:

CHỌN A ., B. - bạn có thể gặp sự cố khi ứng dụng khách hiện gặp khó khăn khi chọn đúng trường.

Nói chung, tôi không sử dụng CHỌN * trừ khi tôi đưa ra quyết định thiết kế có ý thức và tính các rủi ro liên quan là thấp.

0
Cade Roux

Các SELECT *có thể sẽ ổn nếu bạn thực sự cần tất cả các cột - nhưng bạn vẫn nên liệt kê tất cả các cột riêng lẻ. Bạn chắc chắn không nên chọn tất cả các hàng từ một bảng - ngay cả khi ứng dụng & DB nằm trên cùng một máy chủ hoặc mạng. Việc chuyển tất cả các hàng sẽ mất thời gian, đặc biệt là khi số lượng hàng tăng lên. Bạn nên có ít nhất một mệnh đề where lọc kết quả và/hoặc trang kết quả để chỉ chọn tập hợp con của các hàng cần được hiển thị. Một số công cụ ORM tồn tại tùy thuộc vào ngôn ngữ ứng dụng bạn đang sử dụng để hỗ trợ truy vấn và phân trang tập hợp con của dữ liệu bạn cần. Ví dụ: trong .NET Linq to SQL, Entity Framework và nHibernate tất cả sẽ giúp bạn điều này.

0
bkaid

Sử dụng tên trường cụ thể, vì vậy nếu ai đó thay đổi bảng trên bạn, bạn sẽ không nhận được kết quả bất ngờ. Về chủ đề: LUÔN LUÔN chỉ định tên trường khi thực hiện thao tác chèn, vì vậy nếu bạn cần thêm một cột sau, bạn không phải quay lại và sửa chương trình của mình và thay đổi cơ sở dữ liệu cùng lúc trong bản phát hành sản xuất.

0
stu

Nếu bạn quan tâm đến tốc độ, hãy chắc chắn rằng bạn sử dụng các báo cáo đã chuẩn bị. Nếu không, tôi với ilitrite rằng những thay đổi là những gì bạn bảo vệ chính mình chống lại.

/ Allan

0
Allan Wind

Tôi thấy tên cột liệt kê đặc biệt quan trọng nếu các nhà phát triển khác có khả năng làm việc với mã hoặc cơ sở dữ liệu có thể thay đổi, do đó bạn luôn nhận được dữ liệu nhất quán.

0
Sam Cogan

Đây là một bài viết cũ, nhưng vẫn còn hiệu lực. Để tham khảo, tôi có một truy vấn rất phức tạp bao gồm:

  • 12 bàn
  • 6 tham gia còn lại
  • 9 tham gia bên trong
  • 108 cột tổng trên tất cả 12 bảng
  • Tôi chỉ cần 54 cột
  • Một thứ tự 4 cột theo mệnh đề

Khi tôi thực hiện truy vấn bằng Chọn *, sẽ mất trung bình 2869ms. Khi tôi thực hiện truy vấn bằng Chọn, phải mất trung bình 1513ms.

Tổng số hàng trả về là 13.949.

Không có nghi ngờ gì khi chọn tên cột có nghĩa là hiệu suất nhanh hơn Chọn *

Để truy vấn DB trực tiếp (chẳng hạn như tại Dấu nhắc sqlplus hoặc thông qua công cụ quản trị db), hãy chọn * nói chung là ổn - nó giúp bạn tránh được việc viết ra tất cả các cột.

Mặt khác, trong mã ứng dụng, tốt nhất là liệt kê các cột. Điều này có một số lợi ích:

  • Mã rõ ràng hơn
  • Bạn sẽ biết thứ tự kết quả quay trở lại (điều này có thể hoặc không quan trọng đối với bạn)
0
Morikal

Vâng, nó thực sự phụ thuộc vào số liệu và mục đích của bạn:

  1. Nếu bạn có 250 cột và muốn (thực sự) chọn tất cả, hãy sử dụng select * nếu bạn muốn về nhà cùng ngày :)
  2. Nếu mã hóa của bạn cần linh hoạt và bảng cần nhỏ, một lần nữa, chọn * giúp bạn mã nhanh hơn và duy trì dễ dàng hơn.
  3. Nếu bạn muốn kỹ thuật và hiệu suất mạnh mẽ: [.__.]
    • viết tên cột của bạn nếu chúng chỉ là một vài hoặc
    • viết một công cụ cho phép bạn dễ dàng chọn/tạo tên cột của mình

Theo nguyên tắc thông thường, khi tôi cần chọn tất cả các cột, tôi sẽ sử dụng "select *" trừ khi tôi có lý do rất cụ thể để làm khác (cộng với, tôi nghĩ là nhanh hơn trên các bảng có nhiều, nhiều cột)

Và cuối cùng, nhưng không kém phần quan trọng, làm thế nào bạn muốn thêm hoặc xóa một cột trong bảng để ảnh hưởng đến mã của bạn hoặc bảo trì của nó?

0
Notitze