실제로 세 가지 주요 이유가 있습니다.

• 소비자에게 데이터를 옮기는 데 비효율적입니다. SELECT *를 선택하면 응용 프로그램이 실제로 작동 해야하는 것보다 데이터베이스에서 더 많은 열을 검색하는 경우가 많습니다. 이로 인해 더 많은 데이터가 데이터베이스 서버에서 클라이언트로 이동하여 액세스 속도가 느려지고 시스템의로드가 증가하며 네트워크를 통해 이동하는 데 더 많은 시간이 소요됩니다. 이것은 존재하지 않았고 원래 소비자가 데이터 액세스를 코딩 할 때 필요하지 않은 기본 테이블에 새 열을 추가 할 때 특히 그렇습니다.

• 인덱싱 문제 쿼리를 높은 수준의 성능으로 조정하려는 시나리오를 고려하십시오. *를 사용하고 실제로 필요한 것보다 많은 열을 반환하는 경우 서버는 종종 다른 방법보다 데이터를 검색하는 데 더 비싼 방법을 수행해야합니다. 예를 들어, SELECT 목록의 열을 포괄하는 인덱스를 만들 수 없으며, (모든 열 [ shudder ]를 포함하여 ), 주변에 와서 열을 추가 한 다음 사람을 포함하더라도 표를 사용하면 최적화 도구가 최적화 된 커버리지 색인을 무시하게되므로 쿼리 성능이 명백한 이유없이 크게 떨어질 수 있습니다.

• 바인딩 문제. SELECT *를 선택하면 서로 다른 두 테이블에서 같은 이름의 두 열을 검색 할 수 있습니다. 이것은 종종 데이터 소비자를 망칠 수 있습니다. 두 테이블에 “ID”라는 열이있는 두 개의 테이블을 조인하는 쿼리를 상상해보십시오. 소비자는 어느 것이 어느 것인지 어떻게 알 수 있습니까? SELECT *는 기본 테이블 구조가 변경 될 때 뷰 (적어도 일부 버전에서는 SQL Server)를 혼동 할 수 있습니다 . 뷰가 다시 작성되지 않고 다시 오는 데이터가 넌센스 일 수 있습니다 . 그리고 최악의 부분은 원하는대로 열 이름을 지정할 수 있지만 다음에 오는 사람은 이미 개발 한 열과 충돌 할 열을 추가하는 것에 대해 걱정할 필요가 없다는 것입니다. 이름.

그러나 SELECT *에 모두 나쁜 것은 아닙니다. 나는이 사용 사례에 그것을 자유롭게 사용합니다.

• 임시 쿼리. 특히 익숙하지 않은 좁은 테이블에서 무언가를 디버깅하려고 할 때 SELECT *가 종종 내 가장 친한 친구입니다. 기본 열 이름이 무엇인지에 대한 연구를 수행하지 않고도 진행중인 일을 볼 수 있습니다. 이것은 열 이름이 길수록 더 큰 “플러스”가됩니다.

• *가 “행”을 의미 할 때. 다음 유스 케이스에서 SELECT *는 괜찮으며 성능 킬러라는 소문은 수년 전에 일부 유효성이 있었지만 현재는 그렇지 않은 도시 전설 일뿐입니다.

  SELECT COUNT(*) FROM table;

  이 경우 *는 “행 수 계산”을 의미합니다. * 대신 열 이름을 사용하는 경우 해당 열의 값이 null이 아닌 행을 계산합니다 . COUNT (*)는 실제로 행 수를 세는 개념을 고수하고 집계에서 NULL이 제거되어 발생하는 이상한 대소 문자를 피합니다.

  이 유형의 쿼리도 마찬가지입니다.

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

  소금의 가치가있는 모든 데이터베이스에서 *는 “행”을 의미합니다. 하위 쿼리에 넣은 내용은 중요하지 않습니다. 일부 사람들은 SELECT 목록에서 b의 ID를 사용하거나 숫자 1을 사용하지만 IMO는 그 관례가 거의 의미가 없습니다. 당신이 의미하는 것은 “행 수를 세는 것”이며, 그것이 *를 의미하는 것입니다. 대부분의 쿼리 최적화 프로그램은이를 알기에 충분히 똑똑합니다. (솔직히 말해서, 나는 이것이 SQL Server와 Oracle 에서만 사실이라는 것을 알고 있습니다.)

답변