SELECT *가 왜 유해한 것으로 간주됩니까?

왜 SELECT *나쁜 습관이 있습니까? 원하는 새 열을 추가하면 변경하는 코드가 적지 않습니까?

SELECT COUNT(*)일부 DB의 성능 문제 라는 것을 알고 있지만 실제로 모든 열을 원한다면 어떻게해야합니까?

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

• 소비자에게 데이터를 옮기는 데 비효율적입니다. 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 에서만 사실이라는 것을 알고 있습니다.)

SELECT 문에서 별표 문자 "*"는 쿼리와 관련된 테이블의 모든 열에 대한 축약 형입니다.

공연

*속기이 될 수 느린 이유는

• 모든 필드가 색인화되는 것은 아니므로 전체 테이블 스캔이 필요합니다. 효율성은 떨어집니다.
• SELECT *와이어 로 전송하기 위해 저장 한 항목으로 전체 테이블 스캔 위험
• 필요한 것보다 더 많은 데이터 반환
• 가변 길이 데이터 유형을 사용하여 후행 열을 리턴하면 검색 오버 헤드가 발생할 수 있습니다.

유지

사용시 SELECT *:

• 코드베이스에 익숙하지 않은 사람은 문서를 참조하여 유능한 변경을 수행하기 전에 어떤 열이 반환되는지 알고 있어야합니다. 코드를 더 읽기 쉽게 만들고 코드에 익숙하지 않은 사람들에게 필요한 모호함과 작업을 최소화하면 장기적으로 더 많은 시간과 노력을 절약 할 수 있습니다.
• 코드가 열 순서에 의존하는 SELECT *경우 테이블의 열 순서가 변경된 경우 발생하는 오류를 숨 깁니다.
• 쿼리가 작성 될 때 모든 열이 필요하더라도 앞으로는 그렇지 않을 수 있습니다
• 사용법이 프로파일 링을 복잡하게한다

디자인

SELECT *입니다 안티 패턴 :

• 쿼리의 목적은 덜 분명합니다. 응용 프로그램에서 사용하는 열이 불투명합니다
• 가능할 때마다 엄격한 타이핑을 사용하는 것에 대한 모듈성 규칙을 위반합니다. 명시 적으로 거의 보편적으로 좋습니다.

"SELECT *"는 언제 사용해야합니까?

그것은 사용하는 것이 허용의 SELECT *쿼리가 작성 될 때 존재하는 모든 열 반대로 테이블 (들)의 모든 컬럼에 대한 명시 적 필요성 참여가있을 때. 데이터베이스는 *를 전체 열 목록으로 내부적으로 확장하므로 성능 차이는 없습니다.

그렇지 않으면 테이블 별칭을 사용하는 동안 쿼리에 사용될 모든 열을 명시 적으로 나열하십시오.

지금 모든 열을 선택하려는 경우에도 누군가 하나 이상의 새 열을 추가 한 후 모든 열을 선택하지 않을 수 있습니다. 쿼리를 작성하면 SELECT *어떤 시점에서 누군가 텍스트 열을 추가하여 실제로 해당 열이 필요하지 않더라도 쿼리 실행 속도가 느려질 위험이 있습니다.

원하는 새 열을 추가하면 변경하는 코드가 적지 않습니까?

실제로 새 열을 사용하려면 어쨌든 코드를 상당히 많이 변경해야 할 가능성이 있습니다. , new_column입력하는 것만으로 저장 만 됩니다.

SELECT 문의 열 이름을 지정하면 지정된 순서대로 열이 반환되므로 숫자 인덱스로 안전하게 참조 될 수 있습니다. "SELECT *"를 사용하면 임의의 순서로 열을 수신하게되므로 이름으로 만 열을 안전하게 사용할 수 있습니다. 데이터베이스에 추가되는 새 열로 수행 할 작업을 미리 알지 못하는 경우 가장 가능한 올바른 조치는 무시하는 것입니다. 데이터베이스에 추가되는 새 열을 무시하려는 경우 열을 검색해도 아무런 이점이 없습니다.

많은 상황에서 SELECT *는 디자인 타임이 아닌 애플리케이션에서 런타임시 오류를 발생시킵니다. 열 변경에 대한 지식이나 응용 프로그램의 잘못된 참조를 숨 깁니다.

모든 열을 정말로 원한다면 select (*)와 열 이름 지정 사이의 성능 차이를 보지 못했습니다. 열 이름을 지정하는 드라이버는 코드에서 어떤 열을 보게 될지 명시적일 수 있습니다.

그러나 모든 컬럼을 원하지는 않으며 select (*)로 인해 데이터베이스 서버에 불필요한 작업이 발생하고 불필요한 정보가 네트워크를 통해 전달되어야합니다. 시스템을 많이 사용하거나 네트워크 연결이 느린 경우가 아니면 눈에 띄는 문제가 발생하지 않습니다.

앱과 데이터베이스 간의 연결을 줄이는 것으로 생각하십시오.

'코드 냄새'측면을 요약하려면
SELECT *앱과 스키마 사이에 동적 종속성을 만듭니다. 사용을 제한하는 것은 종속성을보다 명확하게 정의하는 한 가지 방법입니다. 그렇지 않으면 데이터베이스를 변경하면 응용 프로그램이 충돌 할 가능성이 커집니다.

테이블에 필드를 추가하면을 사용하는 모든 쿼리에 필드가 자동으로 포함됩니다 select *. 이 방법은 편리해 보이지만 필요한 것보다 많은 데이터를 가져 오면 응용 프로그램 속도가 느려질 수 있으며 실제로 응용 프로그램이 특정 시점에 충돌 할 수 있습니다.

결과의 각 행에서 페치 할 수있는 데이터 양에는 제한이 있습니다. 결과가 해당 한계를 초과하도록 테이블에 필드를 추가하면 조회를 실행하려고 할 때 오류 메시지가 표시됩니다.

찾기 어려운 오류입니다. 한 곳에서 변경하면 실제로 새 데이터를 전혀 사용하지 않는 다른 곳에서 폭발합니다. 자주 사용하지 않는 쿼리 일 수도 있으므로 누군가가 쿼리를 사용하기까지 시간이 걸리므로 오류를 변경 사항에 연결하기가 더 어려워집니다.

결과에 원하는 필드를 지정하면 이러한 종류의 오버 헤드 오버플로로부터 안전합니다.

이 기사에서 가져온 참조.

"SELECT *"를 사용하지 마십시오.

"SELECT *"를 사용해야하는 이유는 하나뿐입니다.

열을 추가하거나 삭제할 때 특별한 요구 사항이 있고 동적 환경을 만든 경우 응용 프로그램 코드로 자동 처리합니다. 이 특별한 경우 응용 프로그램 및 데이터베이스 코드를 변경할 필요가 없으며 이는 프로덕션 환경에 자동으로 영향을 미칩니다. 이 경우“SELECT *”를 사용할 수 있습니다.

일반적으로 SELECT * ...다양한 유형의 데이터 구조에 결과를 맞추어야합니다 . 결과가 도착하는 순서를 지정하지 않으면 모든 것을 올바르게 정렬하는 것이 까다로울 수 있습니다 (더 모호한 필드는 놓치기가 훨씬 쉽습니다).

이렇게하면 응용 프로그램 전체에서 SQL 액세스 코드를 손상시키지 않고 여러 가지 이유로 테이블에 필드를 추가 할 수 있습니다 (중간에도).

SELECT *몇 개의 열만 필요할 때 사용 하면 필요한 것보다 훨씬 많은 데이터가 전송됩니다. 이는 데이터베이스에 처리를 추가하고 클라이언트에 데이터를 가져올 때 대기 시간을 증가시킵니다. 이것에 추가하면로드 할 때 더 많은 메모리를 사용하고 경우에 따라 큰 BLOB 파일과 같이 훨씬 더 많은 메모리를 사용하므로 대부분 효율성에 관한 것입니다.

그러나이 외에도 테이블에있는 내용을 찾을 필요없이 쿼리에서 열이로드되는 열을 확인할 수 있습니다.

예, 여분의 열을 추가하면 더 빠를 수 있지만 대부분의 경우 쿼리를 사용하여 코드를 변경하여 새 열을 수락해야합니다. 어쨌든 열을 가져올 가능성이 있습니다. t 원하는 / 예상 문제가 발생할 수 있습니다. 예를 들어, 모든 열을 가져 와서 루프에서 순서를 사용하여 변수를 할당 한 다음 변수를 추가하거나 열 순서가 변경되면 (백업에서 복원 할 때 발생하는 것으로 보임) 모든 것을 버릴 수 있습니다.

이것은 또한 당신이하고있는 경우 INSERT항상 열을 지정 해야하는 이유와 같은 종류의 이유 입니다.

나는 이것에 대한 담요 규칙이 실제로있을 수 있다고 생각하지 않습니다. 많은 경우에, 나는 SELECT *를 피했지만 SELECT *가 매우 유익한 데이터 프레임 워크를 다루었습니다.

모든 것과 마찬가지로 혜택과 비용이 있습니다. 이익 대 비용 방정식의 일부는 데이터 구조에 대한 제어력이 얼마나 큰가에 달려 있다고 생각합니다. SELECT *가 제대로 작동하는 경우 데이터 구조가 엄격하게 제어되어 (소매 소프트웨어), 누군가가 거대한 BLOB 필드를 테이블에 넣을 위험이별로 없었습니다.

열 이름으로 선택하면 데이터베이스 엔진이 테이블 데이터를 쿼리하지 않고 인덱스에서 데이터에 액세스 할 가능성이 높아집니다.

SELECT *는 테이블에 새 열을 추가하기 때문에 데이터베이스 스키마가 변경되는 경우 시스템에서 예기치 않은 성능 및 기능 변경에 노출됩니다. 그러나 코드에서 해당 새 데이터를 사용하거나 제시 할 준비가되어 있지 않습니다.

더 실용적인 이유가 있습니다 : 돈. 클라우드 데이터베이스를 사용하고 처리 된 데이터에 대해 비용을 지불해야하는 경우 즉시 버릴 데이터를 읽는 방법에 대한 설명이 없습니다.

예를 들면 다음과 같습니다. BigQuery :

쿼리 가격

쿼리 가격은 SQL 명령 및 사용자 정의 함수 실행 비용을 나타냅니다. BigQuery는 하나의 측정 항목 (처리 된 바이트 수)을 사용하여 쿼리 비용을 청구합니다.

및 제어 투영-SELECT *를 피하십시오 .

모범 사례 : 투영 제어-필요한 열만 쿼리하십시오.

프로젝션은 쿼리에서 읽은 열 수를 나타냅니다. 초과 열을 투영하면 추가 (낭비) I / O 및 구체화 (결과 작성)가 발생합니다.

데이터를 쿼리하는 가장 비싼 방법은 SELECT *를 사용하는 것입니다. SELECT *를 사용하면 BigQuery는 테이블의 모든 열을 전체 스캔합니다.

스키마를 디자인하기 전에 요구 사항을 이해하십시오 (가능한 경우).

데이터, 1) 인덱싱 2) 사용 된 스토리지 유형, 3) 공급 업체 엔진 또는 기능에 대해 학습 즉, 캐싱, 인 메모리 기능 4) 데이터 유형 5) 테이블 크기 6) 쿼리 빈도 7) 리소스가 공유되는 경우 관련 작업 부하 8) 테스트

A) 요구 사항은 다양합니다. 하드웨어가 예상 워크로드를 지원할 수없는 경우 워크로드에서 요구 사항을 제공하는 방법을 다시 평가해야합니다. 테이블에 추가 열에 대해. 데이터베이스가 뷰를 지원하는 경우 특정 명명 된 열이있는 특정 데이터의 인덱스 된 뷰 (?)를 만들 수 있습니다 ( '*'선택). 데이터 및 스키마를 정기적으로 검토하여 "쓰레기 제거"-> "쓰레기 제거"증후군에 빠지지 않도록하십시오.

다른 해결책이 없다고 가정합니다. 다음을 고려할 수 있습니다. 문제에 대한 여러 가지 해결책이 항상 있습니다.

1) 인덱싱 : select *는 테이블 스캔을 실행합니다. 다양한 요소에 따라 디스크 검색 및 / 또는 다른 쿼리와의 경합이 포함될 수 있습니다. 테이블이 다목적 인 경우 모든 쿼리가 제대로 수행되고 목표 시간 이하로 실행되는지 확인하십시오. 많은 양의 데이터가 있고 네트워크 또는 기타 리소스가 조정되지 않은 경우 이 점을 고려해야합니다. 데이터베이스는 공유 환경입니다.

2) 저장 유형. 즉, SSD, 디스크 또는 메모리를 사용하는 경우. I / O 시간과 시스템 / CPU의로드는 다양합니다.

3) DBA가 더 높은 성능을 위해 데이터베이스 / 테이블을 조정할 수 있습니까? 어떤 이유로 든 팀은 선택된 '*'가 문제에 대한 최상의 솔루션이라고 결정했습니다. DB 또는 테이블을 메모리에로드 할 수 있습니다. (또는 다른 방법 ... 응답은 2-3 초 지연으로 응답하도록 설계 되었습니까? --- 광고가 회사 수익을 얻기 위해 재생되는 동안 ...)

4) 기준선에서 시작하십시오. 데이터 유형 및 결과 표시 방법을 이해하십시오. 데이터 유형이 작을수록 필드 수는 결과 집합에 반환되는 데이터 양을 줄입니다. 따라서 다른 시스템 요구에 따라 리소스를 사용할 수 있습니다. 시스템 리소스에는 일반적으로 제한이 있습니다. '항상'은 안정성과 예측 가능한 행동을 보장하기 위해 이러한 한계 아래에서 작동합니다.

5) 테이블 / 데이터 크기. 작은 테이블에서 일반적으로 '*'를 선택하십시오. 일반적으로 메모리에 적합하며 응답 시간이 빠릅니다. 다시 .... 요구 사항을 검토하십시오. 기능 크리프 계획; 항상 현재와 가능한 미래의 요구를 계획하십시오.

6) 질의 빈도. 시스템의 다른 워크로드에주의하십시오. 이 쿼리가 매초마다 실행되고 테이블이 작습니다. 결과 세트는 캐시 / 메모리에 유지되도록 설계 할 수 있습니다. 그러나 쿼리가 기가 바이트 / 테라 바이트의 데이터를 가진 빈번한 일괄 처리 프로세스 인 경우 다른 워크로드에 영향을 미치지 않도록 추가 리소스를 할당하는 것이 좋습니다.

7) 관련 작업량. 자원이 어떻게 사용되는지 이해하십시오. 네트워크 / 시스템 / 데이터베이스 / 테이블 / 애플리케이션이 전용 또는 공유입니까? 이해 관계자는 누구입니까? 생산, 개발 또는 QA를위한 것입니까? 이것은 일시적인 "빠른 수정"입니다. 시나리오를 테스트 했습니까? 현재 하드웨어에 얼마나 많은 문제가 존재할 수 있는지 놀랄 것입니다. (예, 성능은 빠르지 만 디자인 / 성능은 여전히 ​​저하됩니다.) 시스템은 초당 10K 쿼리와 초당 5-10 쿼리를 수행해야합니까? 데이터베이스 서버가 전용이거나 다른 응용 프로그램을 수행하는 경우 공유 리소스에서 모니터링이 실행됩니다. 일부 응용 프로그램 / 언어; O / S는 메모리의 100 %를 소비하여 다양한 증상 / 문제를 일으 킵니다.

8) 시험 : 이론을 시험하고 가능한 한 많이 이해하십시오. 선택한 '*'문제는 큰 문제 일 수도 있고 걱정할 필요가없는 것일 수도 있습니다.