Tại sao CHỌN * được coi là có hại?

Tại sao SELECT *thực hành xấu? Điều đó có nghĩa là ít mã hơn để thay đổi nếu bạn thêm một cột mới mà bạn muốn?

Tôi hiểu đó SELECT COUNT(*)là một vấn đề về hiệu năng trên một số DB, nhưng nếu bạn thực sự muốn mọi cột thì sao?

Có ba lý do chính:

• Không hiệu quả trong việc di chuyển dữ liệu đến người tiêu dùng. Khi bạn CHỌN *, bạn thường lấy nhiều cột từ cơ sở dữ liệu hơn ứng dụng của bạn thực sự cần để hoạt động. Điều này khiến nhiều dữ liệu di chuyển từ máy chủ cơ sở dữ liệu đến máy khách, làm chậm truy cập và tăng tải cho máy của bạn, cũng như mất nhiều thời gian hơn để di chuyển qua mạng. Điều này đặc biệt đúng khi ai đó thêm các cột mới vào các bảng bên dưới không tồn tại và không cần thiết khi người tiêu dùng ban đầu mã hóa quyền truy cập dữ liệu của họ.

• Vấn đề lập chỉ mục. Xem xét một kịch bản mà bạn muốn điều chỉnh một truy vấn đến mức hiệu suất cao. Nếu bạn đã sử dụng * và nó trả về nhiều cột hơn mức bạn thực sự cần, máy chủ thường sẽ phải thực hiện các phương thức đắt tiền hơn để truy xuất dữ liệu của bạn so với cách khác. Ví dụ: bạn sẽ không thể tạo một chỉ mục bao gồm các cột trong danh sách CHỌN của bạn và ngay cả khi bạn đã làm (bao gồm tất cả các cột [ shudder ]), anh chàng tiếp theo đã quay lại và thêm một cột vào bên dưới bảng sẽ làm cho trình tối ưu hóa bỏ qua chỉ số bao phủ được tối ưu hóa của bạn và bạn có thể thấy rằng hiệu suất của truy vấn của bạn sẽ giảm đáng kể mà không có lý do rõ ràng.

• Vấn đề ràng buộc. Khi bạn CHỌN *, có thể truy xuất hai cột cùng tên từ hai bảng khác nhau. Điều này thường có thể sụp đổ người tiêu dùng dữ liệu của bạn. Hãy tưởng tượng một truy vấn tham gia hai bảng, cả hai bảng đều chứa một cột có tên là "ID". Làm thế nào để người tiêu dùng biết đó là cái gì? CHỌN * cũng có thể gây nhầm lẫn các chế độ xem (ít nhất là trong một số phiên bản SQL Server) khi cấu trúc bảng cơ bản thay đổi - chế độ xem không được xây dựng lại và dữ liệu quay lại có thể vô nghĩa . Và điều tồi tệ nhất là bạn có thể cẩn thận đặt tên cho các cột của mình theo bất cứ điều gì bạn muốn, nhưng anh chàng tiếp theo có thể không có cách nào biết rằng anh ta phải lo lắng về việc thêm một cột sẽ va chạm với sự phát triển của bạn tên.

Nhưng nó không tệ cho CHỌN *. Tôi sử dụng nó một cách tự do cho các trường hợp sử dụng này:

• Truy vấn đặc biệt. Khi cố gắng gỡ lỗi một cái gì đó, đặc biệt là khỏi một cái bàn hẹp mà tôi có thể không quen thuộc, CHỌN * thường là người bạn tốt nhất của tôi. Nó giúp tôi chỉ nhìn thấy những gì đang diễn ra mà không cần phải thực hiện một loạt nghiên cứu về tên cột bên dưới là gì. Điều này trở thành một "cộng" càng lớn thì tên cột càng dài.

• Khi * có nghĩa là "một hàng". Trong các trường hợp sử dụng sau đây, CHỌN * vẫn ổn, và có tin đồn rằng đó là một kẻ giết người hiệu suất chỉ là truyền thuyết đô thị có thể có giá trị từ nhiều năm trước, nhưng bây giờ thì không:

  SELECT COUNT(*) FROM table;

  trong trường hợp này, * có nghĩa là "đếm các hàng". Nếu bạn sử dụng tên cột thay vì *, nó sẽ tính các hàng trong đó giá trị của cột đó không phải là null . COUNT (*), đối với tôi, thực sự đưa ra khái niệm rằng bạn đang đếm hàng và bạn tránh các trường hợp cạnh lạ do NULL bị loại khỏi tập hợp của bạn.

  Tương tự với loại truy vấn này:

  SELECT a.ID FROM TableA a
  WHERE EXISTS (
      SELECT *
      FROM TableB b
      WHERE b.ID = a.B_ID);

  trong bất kỳ cơ sở dữ liệu nào có giá trị muối, * chỉ có nghĩa là "một hàng". Nó không quan trọng những gì bạn đặt trong truy vấn con. Một số người sử dụng ID của b trong danh sách CHỌN hoặc họ sẽ sử dụng số 1, nhưng IMO những quy ước đó khá vô lý. Ý bạn là "đếm hàng" và đó là những gì * biểu thị. Hầu hết các tối ưu hóa truy vấn hiện có đủ thông minh để biết điều này. (Mặc dù thành thật mà nói, tôi chỉ biết điều này là đúng với SQL Server và Oracle.)

Ký tự dấu hoa thị, "*", trong câu lệnh SELECT là viết tắt cho tất cả các cột trong (các) bảng có liên quan đến truy vấn.

Hiệu suất

Tốc *ký có thể chậm hơn vì:

• Không phải tất cả các trường đều được lập chỉ mục, buộc quét toàn bộ bảng - kém hiệu quả hơn
• Những gì bạn lưu để gửi SELECT *qua dây có nguy cơ quét toàn bộ bảng
• Trả lại nhiều dữ liệu hơn mức cần thiết
• Trả về các cột theo dõi bằng cách sử dụng loại dữ liệu có độ dài thay đổi có thể dẫn đến chi phí tìm kiếm

Bảo trì

Khi sử dụng SELECT *:

• Ai đó không quen thuộc với codebase sẽ bị buộc phải tham khảo tài liệu để biết cột nào được trả về trước khi có thể thực hiện các thay đổi có thẩm quyền. Làm cho mã dễ đọc hơn, giảm thiểu sự mơ hồ và công việc cần thiết cho những người không quen thuộc với mã giúp tiết kiệm nhiều thời gian và công sức hơn trong thời gian dài.
• Nếu mã phụ thuộc vào thứ tự cột, SELECT *sẽ ẩn một lỗi đang chờ xảy ra nếu một bảng có thứ tự cột thay đổi.
• Ngay cả khi bạn cần mọi cột tại thời điểm truy vấn được viết, đó có thể không phải là trường hợp trong tương lai
• việc sử dụng phức tạp hồ sơ

Thiết kế

SELECT *là một mô hình chống :

• Mục đích của truy vấn ít rõ ràng hơn; các cột được sử dụng bởi ứng dụng này mờ đục
• Nó phá vỡ quy tắc mô đun về việc sử dụng gõ nghiêm ngặt bất cứ khi nào có thể. Rõ ràng là gần như phổ biến hơn.

Khi nào nên "CHỌN *"?

Có thể chấp nhận sử dụng SELECT *khi có nhu cầu rõ ràng cho mọi cột trong (các) bảng liên quan, trái ngược với mọi cột tồn tại khi truy vấn được viết. Cơ sở dữ liệu sẽ mở rộng nội bộ * vào danh sách cột đầy đủ - không có sự khác biệt về hiệu suất.

Mặt khác, liệt kê rõ ràng mọi cột sẽ được sử dụng trong truy vấn - tốt nhất là trong khi sử dụng bí danh bảng.

Ngay cả khi bạn muốn chọn mọi cột ngay bây giờ, bạn có thể không muốn chọn mọi cột sau khi ai đó thêm một hoặc nhiều cột mới. Nếu bạn viết truy vấn với SELECT *bạn, bạn sẽ gặp rủi ro rằng đến một lúc nào đó, ai đó có thể thêm một cột văn bản khiến truy vấn của bạn chạy chậm hơn mặc dù bạn không thực sự cần cột đó.

Điều đó có nghĩa là ít mã hơn để thay đổi nếu bạn thêm một cột mới mà bạn muốn?

Cơ hội là nếu bạn thực sự muốn sử dụng cột mới thì bạn sẽ phải thực hiện khá nhiều thay đổi khác cho mã của mình. Bạn chỉ tiết kiệm , new_column- chỉ một vài ký tự gõ.

Nếu bạn đặt tên cho các cột trong câu lệnh CHỌN, chúng sẽ được trả về theo thứ tự được chỉ định và do đó có thể được tham chiếu một cách an toàn bằng chỉ số. Nếu bạn sử dụng "CHỌN *", cuối cùng bạn có thể nhận được các cột theo thứ tự tùy ý và do đó chỉ có thể sử dụng các cột theo tên một cách an toàn. Trừ khi bạn biết trước những gì bạn sẽ muốn làm với bất kỳ cột mới nào được thêm vào cơ sở dữ liệu, hành động chính xác có thể xảy ra nhất là bỏ qua nó. Nếu bạn sẽ bỏ qua bất kỳ cột mới nào được thêm vào cơ sở dữ liệu, sẽ không có lợi ích gì khi truy xuất chúng.

Trong rất nhiều tình huống, CHỌN * sẽ gây ra lỗi khi chạy trong ứng dụng của bạn, thay vì tại thời điểm thiết kế. Nó che giấu kiến ​​thức về thay đổi cột hoặc tham chiếu xấu trong các ứng dụng của bạn.

Nếu bạn thực sự muốn mọi cột, tôi chưa thấy sự khác biệt về hiệu suất giữa chọn (*) và đặt tên cho các cột. Trình điều khiển để đặt tên cho các cột có thể chỉ đơn giản là rõ ràng về những cột bạn muốn thấy trong mã của mình.

Tuy nhiên, thông thường, bạn không muốn mọi cột và chọn (*) có thể dẫn đến công việc không cần thiết cho máy chủ cơ sở dữ liệu và thông tin không cần thiết phải được truyền qua mạng. Không thể gây ra sự cố đáng chú ý trừ khi hệ thống được sử dụng nhiều hoặc kết nối mạng chậm.

Hãy nghĩ về nó như giảm sự ghép nối giữa ứng dụng và cơ sở dữ liệu.

Để tóm tắt khía cạnh 'mùi mã':
SELECT *tạo ra sự phụ thuộc động giữa ứng dụng và lược đồ. Hạn chế sử dụng của nó là một cách làm cho sự phụ thuộc được xác định rõ hơn, nếu không, việc thay đổi cơ sở dữ liệu có nhiều khả năng làm hỏng ứng dụng của bạn.

Nếu bạn thêm các trường vào bảng, chúng sẽ tự động được bao gồm trong tất cả các truy vấn của bạn nơi bạn sử dụng select *. Điều này có vẻ thuận tiện, nhưng nó sẽ làm cho ứng dụng của bạn chậm hơn vì bạn đang tìm nạp nhiều dữ liệu hơn mức bạn cần và nó thực sự sẽ làm hỏng ứng dụng của bạn tại một số điểm.

Có giới hạn về số lượng dữ liệu bạn có thể tìm nạp trong mỗi hàng của kết quả. Nếu bạn thêm các trường vào các bảng của mình để kết quả cuối cùng vượt quá giới hạn đó, bạn sẽ nhận được thông báo lỗi khi bạn cố chạy truy vấn.

Đây là loại lỗi khó tìm. Bạn thực hiện thay đổi ở một nơi và nó sẽ nổ tung ở một nơi khác không thực sự sử dụng dữ liệu mới. Nó thậm chí có thể là một truy vấn ít được sử dụng hơn nên phải mất một thời gian trước khi ai đó sử dụng nó, điều này khiến cho việc kết nối lỗi với thay đổi thậm chí còn khó khăn hơn.

Nếu bạn chỉ định trường nào bạn muốn trong kết quả, bạn sẽ an toàn trước loại tràn này.

Tham khảo lấy từ bài viết này.

Không bao giờ đi với "CHỌN *",

Tôi chỉ tìm thấy một lý do để sử dụng "CHỌN *"

Nếu bạn có yêu cầu đặc biệt và tạo môi trường động khi thêm hoặc xóa cột sẽ tự động xử lý bằng mã ứng dụng. Trong trường hợp đặc biệt này, bạn không yêu cầu thay đổi mã ứng dụng và cơ sở dữ liệu và điều này sẽ tự động ảnh hưởng đến môi trường sản xuất. Trong trường hợp này, bạn có thể sử dụng LỰA CHỌN * CHỌN.

Nói chung, bạn phải phù hợp với kết quả của bạn SELECT * ...vào các cấu trúc dữ liệu thuộc nhiều loại khác nhau. Nếu không chỉ định thứ tự mà kết quả đang đến, có thể rất khó để sắp xếp mọi thứ đúng cách (và các trường khó hiểu hơn sẽ dễ bỏ lỡ hơn nhiều).

Bằng cách này, bạn có thể thêm các trường vào các bảng của mình (ngay cả ở giữa chúng) vì nhiều lý do mà không vi phạm mã truy cập sql trên tất cả các ứng dụng.

Sử dụng SELECT *khi bạn chỉ cần một vài cột có nghĩa là nhiều dữ liệu được truyền hơn bạn cần. Điều này thêm xử lý trên cơ sở dữ liệu và tăng độ trễ khi nhận dữ liệu đến máy khách. Thêm vào đó là nó sẽ sử dụng nhiều bộ nhớ hơn khi được tải, trong một số trường hợp nhiều hơn đáng kể, chẳng hạn như các tệp BLOB lớn, chủ yếu là về hiệu quả.

Tuy nhiên, ngoài điều này, sẽ dễ thấy hơn khi xem truy vấn những cột nào đang được tải, mà không phải tìm kiếm những gì trong bảng.

Có, nếu bạn thêm một cột phụ, nó sẽ nhanh hơn, nhưng trong hầu hết các trường hợp, bạn muốn / cần thay đổi mã của mình bằng cách sử dụng truy vấn để chấp nhận các cột mới và có khả năng nhận được các cột bạn không ' t muốn / mong đợi có thể gây ra vấn đề. Ví dụ: nếu bạn lấy tất cả các cột, sau đó dựa vào thứ tự trong một vòng lặp để gán các biến, sau đó thêm một cột hoặc nếu các lệnh của cột thay đổi (thấy điều đó xảy ra khi khôi phục từ bản sao lưu), nó có thể loại bỏ mọi thứ.

Đây cũng là một lý do tương tự tại sao nếu bạn đang thực hiện, INSERTbạn phải luôn chỉ định các cột.

Tôi không nghĩ rằng thực sự có thể có một quy tắc chăn cho việc này. Trong nhiều trường hợp, tôi đã tránh CHỌN *, nhưng tôi cũng đã làm việc với các khung dữ liệu trong đó CHỌN * rất có lợi.

Như với tất cả mọi thứ, có lợi ích và chi phí. Tôi nghĩ rằng một phần của phương trình lợi ích và chi phí chỉ là mức độ kiểm soát của bạn đối với các cơ sở dữ liệu. Trong trường hợp CHỌN * hoạt động tốt, các cấu trúc dữ liệu được kiểm soát chặt chẽ (đó là phần mềm bán lẻ), do đó, không có nhiều rủi ro khi ai đó sẽ theo dõi một trường BLOB khổng lồ vào một bảng.

Chọn với tên cột làm tăng xác suất công cụ cơ sở dữ liệu có thể truy cập dữ liệu từ các chỉ mục thay vì truy vấn dữ liệu bảng.

CHỌN * hiển thị hệ thống của bạn với hiệu suất và chức năng bất ngờ thay đổi trong trường hợp khi lược đồ cơ sở dữ liệu của bạn thay đổi vì 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ù, mã của bạn chưa được chuẩn bị để sử dụng hoặc trình bày dữ liệu mới đó.

Ngoài ra còn có lý do thực dụng hơn: tiền. Khi bạn sử dụng cơ sở dữ liệu đám mây và bạn phải trả tiền cho dữ liệu được xử lý, không có lời giải thích nào để đọc dữ liệu mà bạn sẽ loại bỏ ngay lập tức.

Ví dụ: BigQuery :

Giá truy vấn

Giá truy vấn đề cập đến chi phí chạy các lệnh SQL và các hàm do người dùng xác định. BigQuery tính phí cho các truy vấn bằng cách sử dụng một số liệu: số byte được xử lý.

và Kiểm soát chiếu - Tránh CHỌN * :

Thực hành tốt nhất: Điều khiển chiếu - Chỉ truy vấn các cột mà bạn cần.

Phép chiếu đề cập đến số lượng cột được đọc bởi truy vấn của bạn. Chiếu các cột thừa phát sinh thêm I / O (lãng phí) và cụ thể hóa (viết kết quả).

Sử dụng SELECT * là cách đắt nhất để truy vấn dữ liệu. Khi bạn sử dụng CHỌN *, BigQuery sẽ quét toàn bộ mọi cột trong bảng.

Hiểu các yêu cầu của bạn trước khi thiết kế lược đồ (nếu có thể).

Tìm hiểu về dữ liệu, 1) lập chỉ mục 2) loại lưu trữ được sử dụng, 3) công cụ hoặc tính năng của nhà cung cấp; tức là ... bộ nhớ đệm, khả năng trong bộ nhớ 4) kiểu dữ liệu 5) kích thước của bảng 6) tần suất truy vấn 7) khối lượng công việc liên quan nếu tài nguyên được chia sẻ 8) Kiểm tra

A) Yêu cầu sẽ thay đổi. Nếu phần cứng không thể hỗ trợ khối lượng công việc dự kiến, bạn nên đánh giá lại cách cung cấp các yêu cầu trong khối lượng công việc. Về cột bổ sung vào bảng. Nếu cơ sở dữ liệu hỗ trợ các chế độ xem, bạn có thể tạo chế độ xem được lập chỉ mục (?) Cho dữ liệu cụ thể với các cột được đặt tên cụ thể (so với chọn '*'). Định kỳ xem xét dữ liệu và lược đồ của bạn để đảm bảo bạn không bao giờ gặp phải hội chứng "Rác vào" -> "Rác ra".

Giả sử không có giải pháp nào khác; bạn có thể tính đến những điều sau đây Luôn có nhiều giải pháp cho một vấn đề.

1) Lập chỉ mục: Việc chọn * sẽ thực hiện quét bảng. Tùy thuộc vào các yếu tố khác nhau, điều này có thể liên quan đến việc tìm kiếm đĩa và / hoặc tranh chấp với các truy vấn khác. Nếu bảng đa mục đích, đảm bảo tất cả các truy vấn đều có hiệu suất và thực hiện bên dưới thời gian mục tiêu của bạn. Nếu có một lượng lớn dữ liệu và mạng của bạn hoặc tài nguyên khác không được điều chỉnh; bạn cần phải tính đến điều này Cơ sở dữ liệu là một môi trường chia sẻ.

2) loại lưu trữ. Tức là: nếu bạn đang sử dụng ổ SSD, đĩa hoặc bộ nhớ. Thời gian I / O và tải trên hệ thống / cpu sẽ khác nhau.

3) DBA có thể điều chỉnh cơ sở dữ liệu / bảng để có hiệu suất cao hơn không? Giả sử vì bất kỳ lý do gì, các đội đã quyết định chọn '*' là giải pháp tốt nhất cho vấn đề; DB hoặc bảng có thể được tải vào bộ nhớ. (Hoặc phương pháp khác ... có thể phản hồi được thiết kế để phản hồi với độ trễ 2-3 giây? --- trong khi quảng cáo phát để kiếm doanh thu của công ty ...)

4) Bắt đầu tại đường cơ sở. Hiểu các loại dữ liệu của bạn và cách trình bày kết quả. Các kiểu dữ liệu nhỏ hơn, số lượng trường làm giảm lượng dữ liệu được trả về trong tập kết quả. Điều này để lại tài nguyên có sẵn cho các nhu cầu hệ thống khác. Các tài nguyên hệ thống thường có một giới hạn; "Luôn luôn" làm việc dưới các giới hạn này để đảm bảo sự ổn định và hành vi có thể dự đoán được.

5) kích thước của bảng / dữ liệu. chọn '*' là phổ biến với các bảng nhỏ. Chúng thường phù hợp với bộ nhớ và thời gian phản hồi nhanh. Một lần nữa .... xem lại yêu cầu của bạn. Lập kế hoạch cho tính năng creep; luôn có kế hoạch cho các nhu cầu hiện tại và có thể trong tương lai.

6) Tần suất truy vấn / truy vấn. Hãy nhận biết các khối lượng công việc khác trên hệ thống. Nếu truy vấn này tắt mỗi giây và bảng nhỏ. Tập kết quả có thể được thiết kế để ở trong bộ nhớ cache / bộ nhớ. Tuy nhiên, nếu truy vấn là một quy trình hàng loạt thường xuyên với Gigabyte / Terabyte dữ liệu ... bạn có thể tốt hơn để dành tài nguyên bổ sung để đảm bảo khối lượng công việc khác không bị ảnh hưởng.

7) Khối lượng công việc liên quan. Hiểu cách các tài nguyên được sử dụng. Mạng / hệ thống / cơ sở dữ liệu / bảng / ứng dụng được dành riêng hay chia sẻ? Các bên liên quan là ai? Đây là cho sản xuất, phát triển, hoặc QA? Đây có phải là một "sửa chữa nhanh" tạm thời. Bạn đã thử nghiệm kịch bản? Bạn sẽ ngạc nhiên khi có bao nhiêu vấn đề có thể tồn tại trên phần cứng hiện tại. (Có, hiệu suất nhanh ... nhưng thiết kế / hiệu suất vẫn bị suy giảm.) Hệ thống có cần thực hiện 10K truy vấn mỗi giây so với 5-10 truy vấn mỗi giây không. Là máy chủ cơ sở dữ liệu dành riêng, hoặc thực hiện các ứng dụng khác, giám sát thực thi trên tài nguyên được chia sẻ. Một số ứng dụng / ngôn ngữ; O / S sẽ tiêu thụ 100% bộ nhớ gây ra các triệu chứng / vấn đề khác nhau.

8) Kiểm tra: Kiểm tra lý thuyết của bạn và hiểu càng nhiều càng tốt. Vấn đề lựa chọn '*' của bạn có thể là một vấn đề lớn hoặc có thể là điều bạn thậm chí không cần phải lo lắng.