it-swarm-ko.tech

어느 것이 더 빠르거나 가장 좋습니까? SELECT * 또는 SELECT column1, colum2, column3 등

SELECT *은 SQL 명령을 작성할 때 일반적으로 사용하는 것이 좋지 않다는 말을 들었습니다. 특히 필요한 열 SELECT에 대해 더 효율적이기 때문입니다.

테이블의 모든 열을 SELECT해야하는 경우 사용해야합니다

SELECT * FROM TABLE

또는

SELECT column1, colum2, column3, etc. FROM TABLE

이 경우 효율성이 정말로 중요합니까? 모든 데이터가 실제로 필요한 경우 SELECT *가 내부적으로 더 최적이라고 생각하지만 데이터베이스에 대한 이해가 부족하다고 말하고 있습니다.

이 경우 모범 사례가 무엇인지 궁금합니다.

PDATE : 아마 실제로 want 할 유일한 상황은 SELECT *를 수행하는 것이 하나에서 데이터를 선택할 때임을 지정해야합니다. 새 열을 추가하더라도 모든 열을 항상 검색해야한다는 것을 알고있는 테이블.

그러나 내가 본 응답을 감안할 때, 이것은 여전히 ​​나쁜 생각처럼 보이고 SELECT *는 내가 기술적 인 많은 이유로 절대 사용해서는 안됩니다.

155
Dan Herbert

특정 열을 선택하는 것이 더 좋은 이유 중 하나는 SQL Server가 테이블 데이터를 쿼리하지 않고 인덱스에서 데이터에 액세스 할 가능성이 높아지기 때문입니다.

여기에 내가 쓴 게시물이 있습니다 : 선택 쿼리가 잘못된 인덱스 적용 범위

데이터를 소비하는 코드는 나중에 테이블 스키마의 변경 사항에 관계없이 동일한 데이터 구조를 갖기 때문에 변경하기가 덜 취약합니다.

158
Jon Galloway

your 사양을 지정하면 are 모든 열을 선택하면 차이가 거의 없습니다 현재. 그러나 데이터베이스 스키마가 변경됨을 인식하십시오. SELECT * 코드에 새로운 데이터를 사용하거나 제시 할 준비가되어 있지 않더라도 테이블에 새 열을 추가하려고합니다. 이는 시스템이 예기치 않은 성능 및 기능 변경에 노출되고 있음을 의미합니다.

이 비용을 약간의 비용으로 기꺼이 기각 할 수도 있지만 필요하지 않은 열은 다음과 같아야합니다.

  1. 데이터베이스에서 읽기
  2. 네트워크를 통해 전송
  3. 프로세스에 마샬링
  4. (ADO 유형 기술의 경우) 메모리 내 데이터 테이블에 저장
  5. 무시 및 폐기/가비지 수집

항목 # 1에는 잠재적 인 커버링 인덱스를 제거하고 데이터 페이지로드 (및 서버 캐시 스 래싱)를 유발하고 행/페이지/테이블 잠금이 발생하는 등 많은 숨겨진 비용이 발생합니다.

열을 지정할 때의 절약 효과와 * 그리고 유일하게 절약 가능한 것은

  1. 프로그래머는 열을 추가하기 위해 SQL을 다시 방문 할 필요가 없습니다.
  2. SQL의 네트워크 전송이 더 작거나 빠릅니다
  3. SQL Server 쿼리 구문 분석/유효성 검사 시간
  4. SQL Server 쿼리 계획 캐시

항목 1의 경우 실제로는 추가 할 수있는 새로운 열을 사용하기 위해 코드를 추가/변경한다는 것이 현실입니다.

항목 2의 경우, 그 차이만으로도 다른 패킷 크기 또는 수의 네트워크 패킷으로 푸시 할 수 없습니다. SQL 문 전송 시간이 주요 문제가되는 시점에 도달하면 먼저 문 비율을 줄여야합니다.

항목 3의 경우 * 어쨌든 테이블 스키마를 참조해야합니다. 실제로 열을 나열하면 스키마에 대해 유효성을 검사해야하므로 동일한 비용이 발생합니다. 다시 말해 이것은 완전한 세척입니다.

항목 4의 경우, 특정 열을 지정할 때 쿼리 계획 캐시는 더 커지지 만 다른 열 집합 (지정하지 않은 열)을 처리하는 경우 only가 될 수 있습니다. 이 경우 필요에 따라 다른 계획을 원하기 때문에 do want 다른 캐시 항목이 있습니다.

따라서 질문을 지정한 방식으로 인해 최종 스키마 수정에 직면 한 문제의 복원력이 저하됩니다. 이 스키마를 ROM (발생))으로 굽는 경우 * 완벽하게 허용됩니다.

그러나 필자의 일반적인 지침은 필요한 열만 선택해야한다는 것입니다. 즉 때때로 모든 열을 요구하는 것처럼 보이지만 DBA 및 스키마 진화는 일부 새로운 열이 쿼리에 큰 영향을 줄 수 있습니다.

내 충고는 항상 특정 열을 선택해야한다는 것입니다. 반복해서하는 일에 능숙 해 지므로 올바르게하는 습관을 가지십시오.

코드 변경없이 스키마가 변경 될 수있는 이유가 궁금하다면 감사 로깅, 유효/만료 날짜 및 DBA가 규정 준수 문제에 대해 체계적으로 추가하는 기타 유사한 사항을 고려하십시오. 미처리 변경의 또 다른 원인은 시스템 또는 사용자 정의 필드의 다른 곳에서 성능이 저하되는 것입니다.

57
IDisposable

필요한 열만 선택해야합니다. 모든 열이 필요하더라도 SQL Server가 열에 대한 시스템 테이블을 쿼리하지 않아도되도록 열 이름을 나열하는 것이 좋습니다.

또한 누군가가 테이블에 열을 추가하면 응용 프로그램이 중단 될 수 있습니다. 프로그램은 예상하지 못한 열을 가져오고 처리 방법을 모를 수 있습니다.

이 외에도 테이블에 이진 열이 있으면 쿼리 속도가 훨씬 느려지고 더 많은 네트워크 리소스가 사용됩니다.

33
Giorgi

select *는 나쁜 것입니다 :

  1. 가장 중요한 실질적인 이유는 사용자가 열이 반환되는 순서를 마술로 알도록 강요하기 때문입니다. 명시 적으로하는 것이 낫습니다. 테이블 변경에 대해 보호합니다.

  2. 사용중인 열 이름이 변경되면 더 이상 존재하지 않거나 이름이 변경된 열을 사용하려고 할 때보다는 SQL 호출 시점에서 일찍 잡는 것이 좋습니다. )

  3. 열 이름을 나열하면 코드가 훨씬 더 자체 문서화되므로 읽기 쉽습니다.

  4. 네트워크를 통해 전송하는 경우 (또는 그렇지 않은 경우에도) 필요하지 않은 열은 낭비입니다.

30
pkh

열 목록을 지정하는 것은 보통 최상의 옵션입니다. 누군가 열을 테이블에 추가/삽입해도 응용 프로그램에 영향을 미치지 않기 때문입니다.

9
ilitirit

서버의 경우 열 이름을 지정하는 것이 훨씬 빠릅니다. 그러나 만약

  1. 성능은 큰 문제가 아님 (예를 들어, 이것은 각 테이블에 수백, 수천 또는 수백만 행이있는 웹 사이트 콘텐츠 데이터베이스입니다); 과
  2. 귀하의 임무는 복잡한 일회성 응용 프로그램을 만드는 대신 공통 프레임 워크를 사용하여 많은 작고 유사한 응용 프로그램 (예 : 공개 컨텐츠 관리 웹 사이트)을 만드는 것입니다. 과
  3. 유연성이 중요합니다 (각 사이트에 대한 db 스키마의 많은 사용자 정의);

그런 다음 SELECT *를 고수하는 것이 좋습니다. 프레임 워크에서 SELECT *를 많이 사용하면 새로운 웹 사이트 관리 콘텐츠 필드를 테이블에 도입 할 수 있으므로 CMS의 모든 이점 (버전 관리, 워크 플로/승인 등)을 제공하는 동시에 수십 점 대신 몇 점.

DB 전문가가이 점 때문에 나를 미워할 것임을 알고 있습니다. 계속 진행하십시오. 투표하십시오.하지만 저의 세계에서는 개발자 시간이 부족하고 CPU주기가 풍부하므로 보존하는 것과 낭비하는 것을 적절하게 조정합니다.

7
Herb Caudill

쿼리가 네트워크를 통해 전송되지 않더라도 SELECT *는 잘못된 방법입니다.

  1. 필요한 것보다 많은 데이터를 선택하면 쿼리 효율성이 떨어집니다. 서버는 추가 데이터를 읽고 전송해야하므로 시간이 걸리고 시스템 (다른 네트워크, 디스크, CPU 등)에 불필요한로드가 발생합니다. ). 또한 서버는 쿼리뿐만 아니라 쿼리를 최적화 할 수 없습니다 (예 : 쿼리에 커버링 인덱스 사용).
  2. 얼마 후 테이블 구조가 변경 될 수 있으므로 SELECT *는 다른 열 집합을 반환합니다. 따라서 응용 프로그램이 예기치 않은 구조의 데이터 집합을 가져 와서 다운 스트림 어딘가에서 중단 될 수 있습니다. 열을 명시 적으로 지정하면 알려진 구조의 데이터 집합을 얻거나 데이터베이스 수준에서 '열을 찾을 수 없음'과 같은 명확한 오류가 발생합니다.

물론이 모든 것이 작고 간단한 시스템에는 중요하지 않습니다.

6
VladV

성능 측면에서는 특정 열이있는 SELECT가 더 빠를 수 있습니다 (모든 데이터를 읽을 필요는 없음). 쿼리에서 실제로 모든 열을 사용하는 경우 명시 적 매개 변수가있는 SELECT가 여전히 선호됩니다. 모든 속도 차이는 기본적으로 눈에 띄지 않으며 거의 ​​일정합니다. 언젠가는 스키마가 변경 될 것이며, 이로 인한 문제를 방지하기위한 좋은 보험입니다.

4
Yann Ramin

필요한 필드와 필요한 숫자 만 선택해야합니다.

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

데이터베이스 외부에서 동적 쿼리는 주입 공격 및 변형 된 데이터의 위험이 있습니다. 일반적으로 저장 프로 시저 또는 매개 변수화 된 쿼리를 사용하여이 문제를 해결합니다. 또한 (실제로 큰 문제는 아니지만) 서버는 동적 쿼리가 실행될 때마다 실행 계획을 생성해야합니다.

4
Matthew Abbott

"select *"의 문제점은 실제로 필요하지 않은 데이터를 가져올 수 있다는 것입니다. 실제 데이터베이스 쿼리 중에 선택한 열이 실제로 계산에 추가되지 않습니다. 실제로 "무거운"것은 클라이언트로의 데이터 전송이며, 실제로 필요하지 않은 열은 네트워크 대역폭을 낭비하고 쿼리가 반환되기를 기다리는 시간을 늘리는 것입니다.

"select * ..."에서 가져온 모든 열을 사용하더라도 지금까지만 가능합니다. 나중에 테이블/뷰 레이아웃을 변경하고 더 많은 열을 추가하는 경우 필요하지 않더라도 선택 항목에 열을 가져 오기 시작합니다.

"select *"문이 잘못된 또 다른 점은 뷰 작성입니다. "select *"를 사용하여보기를 작성하고 나중에 테이블에 열을 추가하면,보기 정의와 리턴 된 데이터가 일치하지 않으므로 다시 작동하려면보기를 다시 컴파일해야합니다.

"select *"를 작성하는 것이 유혹에 있다는 것을 알고 있습니다. 왜냐하면 실제로 쿼리에 모든 필드를 수동으로 지정하는 것을 좋아하지 않기 때문입니다. /보기에 버그를 제거하거나 앱을 최적화하는 데 많은 시간과 노력을 들이지 않고 필드를 지정하는 노력.

3
Alexandre Brasil

열을 명시 적으로 나열하는 것이 성능에는 좋지만 열중하지 마십시오.

따라서 모든 데이터를 사용하는 경우 단순성을 위해 SELECT *를 시도하십시오 (열이 많고 JOIN ... 쿼리를 수행하는 것이 끔찍할 수 있음). 그런 다음 측정하십시오. 열 이름이 명시 적으로 나열된 쿼리와 비교하십시오.

성능에 대해 추측하지 말고 측정하십시오!

명시 적 목록은 큰 데이터 (예 : 게시물 또는 기사 본문)가 포함 된 열이 있고 주어진 쿼리에 필요하지 않은 경우에 가장 유용합니다. 그런 다음 응답으로 반환하지 않으면 DB 서버는 시간, 대역폭 및 디스크 처리량을 절약 할 수 있습니다. 쿼리 결과도 작아서 모든 쿼리 캐시에 적합합니다.

3
Paweł Hajdan

sQL Server는 열을 검색하기 위해 열을 조회 할 필요가 없으므로 열을 확실히 정의해야합니다. 열을 정의하면 SQL이 해당 단계를 건너 뛸 수 있습니다.

3
Nick Berardi

한 번 생각하면 SQL은 쿼리 할 때마다 "wtf is *"라고 생각할 필요가 없습니다. 게다가 누군가가 나중에 쿼리에 실제로 필요하지 않은 열을 테이블에 추가 할 수 있으며이 경우 모든 열을 지정하면 더 좋습니다.

3
BrewinBombers

* 또는 열을 사용하는 경우 속도 측면에서 동일하게 선택됩니다.

차이점은 속도가 아니라 메모리에 관한 것입니다. 여러 열을 선택하면 SQL Server는 요청한 모든 열에 대한 모든 데이터를 포함하여 쿼리를 제공하기 위해 메모리 공간을 할당해야합니다 (한 열만 사용하더라도).

성과 측면에서 중요한 것은 귀하의 WHERE 조항과 JOIN, OUTER JOIN 등의 수에 크게 의존하는 면제 계획입니다 ...

질문에 대해서는 SELECT *를 사용하십시오. 모든 열이 필요한 경우 성능 차이가 없습니다.

2
Jorge Córdoba

결과가 너무 큽니다. SQL 엔진에서 클라이언트로 결과를 생성하고 보내는 속도가 느립니다.

일반 프로그래밍 환경 인 클라이언트 측은 행 수가 클 수 있으므로 (예 : 수천만 행) 결과를 필터링하고 처리하도록 설계되지 않아야합니다 (예 : WHERE 절, ORDER 절).

2
kennytm

응용 프로그램에서 얻을 것으로 예상되는 각 열의 이름을 지정하면 열이 여전히 (순서대로) 존재하는 한 누군가가 테이블을 변경하면 응용 프로그램이 중단되지 않습니다.

2
Don

모든 필드에 대한 데이터를 가져와야하는 경우에만 명시적인 필드 이름을 사용하는 것이 더 빠르지 않습니다.

클라이언트 소프트웨어는 반환 된 필드의 순서에 의존해서는 안되므로 말도 안됩니다.

그리고 어떤 필드가 존재하는지 아직 알지 못하기 때문에 *를 사용하여 모든 필드를 가져와야 할 수도 있습니다 (매우 역동적 인 데이터베이스 구조).

명시 적 필드 이름을 사용할 때의 또 다른 단점은 이름이 많고 길면 코드 및/또는 쿼리 로그를 읽는 것이 더 어렵다는 것입니다.

따라서 규칙은 다음과 같아야합니다. 모든 필드가 필요한 경우 *를 사용하고 서브 세트 만 필요한 경우 명시 적으로 이름을 지정하십시오.

2
user9385

DB 서버의 버전에 따라 다르지만 최신 버전의 SQL은 계획을 캐시 할 수 있습니다. 귀하의 데이터 액세스 코드로 가장 유지 관리가 쉬운 것은 무엇이든 사용하십시오.

1
Keith

원하는 열을 정확하게 작성하는 것이 더 좋은 방법은 테이블 구조의 향후 변경 가능성 때문입니다.

인덱스 기반 접근 방식을 사용하여 수동으로 데이터를 읽고 쿼리 결과로 데이터 구조를 채우는 경우 나중에 열을 추가/제거 할 때 문제가 무엇인지 파악하는 데 어려움이 있습니다.

더 빠른 것에 관해서는, 나는 그들의 전문 지식을 다른 사람들에게 미루겠습니다.

1
dpollock

정의에 따라 내부 조인이있는 경우 조인 열의 데이터가 반복되므로 모든 열이 필요하지는 않습니다.

SQl 서버에 열을 나열하는 것이 어렵거나 시간이 오래 걸리는 것과는 다릅니다. 개체 브라우저에서 끌어다 놓기 만하면됩니다 (단어 열에서 끌어서 한 번에 모두 얻을 수 있음). 시스템에서 영구적으로 성능을 저하 시키려면 (네트워크를 통해 인덱스 사용을 줄이고 불필요한 데이터를 전송하기 때문에 비용이 많이 들기 때문에) 데이터베이스가 변경 될 때 예기치 않은 문제가 발생할 가능성이 높아집니다 (때로는 열이 추가됨) 예를 들어 개발 시간을 1 분 미만으로 절약하는 것은 근시안적이고 전문적이지 않습니다.

1
HLGEM

위의 모든 사람들이 말한 것 :

읽을 수있는 유지 보수 가능한 코드를 찾으려면 다음과 같이하십시오.

위젯 선택, foo, bar;

즉시 읽을 수 있고 의도를 보여줍니다. 당신이 그 전화를하면 당신이 돌아 오는 것을 알고 있습니다. 위젯에 foo 및 bar 열만있는 경우 *를 선택하면 되돌릴 항목을 계속 생각하고 순서가 올바르게 맵핑되는지 등을 확인해야합니다. 그러나 위젯에 더 많은 열이 있지만 foo에만 관심이있는 경우 및 bar, 와일드 카드를 쿼리하면 반환 된 내용 중 일부만 사용하면 코드가 지저분 해집니다.

1
Faisal

열 수와 같은 메타 데이터를 얻으려면 SELECT *가 필요합니다.

1
Mark Etable

다른 사람들이 말한 것을 더하기 위해, 선택한 모든 열이 인덱스에 포함되면 SQL에서 추가 데이터를 찾는 대신 결과 집합이 인덱스에서 가져옵니다.

1
Mike

대부분의 문제와 마찬가지로 달성하려는 대상에 따라 다릅니다. 테이블의 모든 열을 허용하는 DB 그리드를 만들려면 "Select *"가 정답입니다. 그러나 특정 열만 필요하고 쿼리에서 열을 추가하거나 삭제하는 작업이 드물게 수행되는 경우 개별적으로 지정하십시오.

또한 서버에서 전송하려는 데이터의 양에 따라 다릅니다. 열 중 하나가 메모, 그래픽, 얼룩 등으로 정의되어 있고 해당 열이 필요하지 않은 경우 "Select *"를 사용하지 않는 것이 좋습니다. 그렇지 않으면 많은 양의 데이터를 얻을 수 있습니다 원하면 성능이 저하 될 수 있습니다.

1
Mark

효율성이 중요한지 여부는 프로덕션 데이터 세트의 크기 (및 성장률)에 따라 다릅니다. 데이터 집합이 그렇게 크지 않고 빠르게 커지지 않을 경우 개별 열을 선택하면 성능상의 이점이 많지 않을 수 있습니다.

더 큰 데이터 세트와 더 빠른 데이터 증가 속도로 인해 성능 이점이 점점 더 중요 해지고 있습니다.

차이점이 있는지 여부를 그래픽으로 보려면 쿼리 분석기를 사용하여 SELECT * 및 동등한 SELECT col1, col2 등에 대한 쿼리 실행 계획을 확인하는 것이 좋습니다. 두 쿼리 중 어느 것이 더 효율적인지 알려줄 것입니다. 다양한 볼륨의 테스트 데이터를 생성하여 타이밍이 무엇인지 확인할 수도 있습니다.

0
Scott Lawrence

이 문제로 인해 곤경에 빠졌지 만 여러 테이블의 필요한 값을 하나의 액세스하기 쉬운 View로 미리 결합한 SQL Server Views에서 거의 모든 데이터를 검색하기 때문에 select *를 사용합니다.

그런 다음 새 필드가 기본 테이블에 추가 될 때 변경되지 않는보기의 모든 열을 원합니다. 이것은 데이터의 출처를 변경할 수 있다는 추가 이점이 있습니다. View의 FieldA는 한 번에 계산 된 다음 정적으로 변경할 수 있습니다. 어느 쪽이든 View가 FieldA를 제공합니다.

이것의 장점은 내 데이터 레이어가 데이터 세트를 가져올 수 있다는 것입니다. 그런 다음 객체를 내 BL로 전달한 다음 객체를 만들 수 있습니다. 내 주요 응용 프로그램은 객체를 알고 상호 작용합니다. 심지어 데이터 행을 전달할 때 객체가 자체 생성되도록 허용합니다.

물론, 나는 유일한 개발자이므로 도움이됩니다. :)

0
klkitchens

매번 선택하려는 열을 절대적으로 정의하십시오. 하지 말아야 할 이유가 없으며 성능 향상은 그만한 가치가 있습니다.

"SELECT *"옵션을 제공해서는 안됩니다.

0
cazlab

모든 열이 필요한 경우 SELECT *를 사용하지만 순서를 변경하면 결과를 소비 할 때 색인이 아닌 이름으로 액세스 할 수 있습니다.

나는 목록을 얻는 방법에 대한 의견을 무시할 것입니다-기회가 파싱되고 명명 된 열의 유효성을 검사하는 것은 처리 시간과 같지 않습니다. 조기 최적화하지 마십시오 ;-)

0
DamienG

이 둘의 주요 차이점은 앞뒤로 전달되는 데이터의 양입니다. "select *"및 "select col1 ... 그러나 행당 15 개의 열 대 행당 5 개의 열을 전송하는 것은 10 열의 차이입니다.

0
Jeff Hubbard

실행 효율성 측면에서 나는 큰 차이점을 알지 못합니다. 그러나 프로그래머의 효율성을 위해 필드 이름을 작성합니다.

  • 숫자로 색인을 작성해야하거나 운전자가 얼룩 값에 대해 웃기게 행동하고 명확한 순서가 필요한 경우 순서를 알고 있습니다.
  • 더 많은 필드를 추가해야하는 경우 필요한 필드 만 읽습니다.
  • 레코드 세트/행의 빈 값이 아닌 필드의 철자가 틀리거나 필드 이름을 바꾸면 SQL 오류가 발생합니다.
  • 무슨 일이 일어나고 있는지 더 잘 읽을 수 있습니다.
0
Erik

여러 사람들이 열을 지정하는 데 훨씬 오래 걸린다고 생각하는 것 같습니다. 개체 브라우저에서 열 목록을 끌어다 놓을 수 있으므로 쿼리에서 열을 지정하는 데 약간의 시간이 걸릴 수 있습니다 (열이 많고 별도의 행에 두는 데 시간이 걸리는 경우). 사람들은 왜 그렇게 시간이 많이 걸리다고 생각합니까?

0
HLGEM

스키마가 변경되고 추가 열이 필요하지 않은 경우를 대비하여 항상 필요한 열을 지정하는 것이 좋습니다.

또한 테이블 이름으로 열 이름을 규정하십시오. 쿼리에 조인이 포함 된 경우 중요합니다. 테이블 자격이 없으면 어떤 열이 어느 테이블에서 왔는지 기억하기 어려울 수 있으며, 비슷한 이름의 열을 다른 테이블 중 하나에 추가하면 쿼리가 중단 될 수 있습니다.

0
mxsscott

성능 현명한 나는 둘 다 동등한 의견을 보았다. 그러나 유용성 측면에는 +와-가 있습니다.

쿼리에서 (select *)를 사용하고 일부 테이블을 변경하고 이전 쿼리에 필요하지 않은 새 필드를 추가하는 경우 불필요한 오버 헤드가 발생합니다. 새로 추가 된 필드가 Blob 또는 이미지 필드이면 어떻게 되나요 ??? 쿼리 응답 시간이 실제로 느려질 것입니다.

반면 (select col1, col2, ..)를 사용하고 테이블이 변경되어 새 필드가 추가되고 결과 필드에 해당 필드가 필요한 경우 테이블 변경 후 항상 선택 쿼리를 편집해야합니다.

그러나 항상 쿼리에서 select col1, col2, ...를 사용하고 나중에 테이블이 변경되면 쿼리를 변경하는 것이 좋습니다.

0
Lahiru Cooray

정의에 의해 결합 becaseu가있는 경우 성능이 select *를 사용하지 않는 것이 특히 중요합니다. 두 개 이상의 필드에 동일한 데이터가 있습니다. 데이터베이스 서버에서 응용 프로그램 또는 웹 서버로 필요없는 데이터를 보내는 네트워크 리소스를 낭비하지 않으려 고합니다. select *를 사용하는 것이 더 쉬워 보이지만 나쁜 습관입니다. 열 이름을 쿼리로 쉽게 드래그 할 수 있으므로 대신 수행하십시오.

Select *를 사용할 때 발생하는 또 다른 문제는 테이블 중간에 새 필드를 추가하기로 선택한 바보가 있다는 것입니다 (항상 나쁜 습관입니다). select *를 삽입의 기초로 사용하면 갑자기 열 순서가 잘못 될 수 있습니다 데이터 무결성에있어 매우 나쁜 일이 될 수있는 사회 보장 번호를 명예 (비화자가 아닌 예를 선택하기 위해 지불 할 수있는 금액)에 사회 보장 번호를 삽입하려고 할 수 있습니다. 선택이 삽입이 아닌 경우에도 데이터가 보고서 또는 웹 페이지에서 갑자기 마모 된 순서로 표시되면 고객에게 좋지 않습니다.

열 목록을 사용하는 것보다 select *를 사용할 때 상황이 없다고 생각합니다. 유지 관리가 더 쉽다고 생각할 수도 있지만 실제로는 필요하지 않은 필드를 테이블에 추가해도 아무런 이유없이 응용 프로그램이 느려지거나 느려지지 않습니다. 또한 열 목록을 사용하면 깨지지 않은 문제를 해결하는 문제에 직면해야하므로 열을 추가하지 않고 저장하는 시간이 오래 걸립니다.

0
HLGEM

야 실용적. 프로토 타이핑시 select *를 사용하고 구현 및 배포시 특정 열을 선택하십시오. 실행 계획 관점에서 보면 현대 시스템에서는 둘 다 비교적 동일합니다. 그러나 특정 열을 선택하면 디스크에서 검색하고 메모리에 저장하며 네트워크를 통해 전송해야하는 데이터의 양이 제한됩니다.

궁극적으로 가장 좋은 계획은 특정 열을 선택하는 것입니다.

0
siculars

또한 변경 사항을 명심하십시오. 오늘 Select *는 필요한 열만 선택하지만 내일은 방금 추가하지 않은 varbinary (MAX) 열을 선택할 수도 있으며 이제는 그렇지 않은 3.18GB의 이진 데이터를 모두 검색하고 있습니다. 어제 테이블에.

0
Michael Stum

어느 쪽이 더 빠른지 생각해 봅시다. 필요한 데이터 만 선택할 수 있으면 더 빠릅니다. 그러나 테스트시 비즈니스 요구에 따라 필터링 할 수있는 데이터를 판단하기 위해 모든 데이터를 가져올 수 있습니다.

0
mikedopp

유지 관리 목적으로 SELECT *가 좋은 경우가 있지만 일반적으로 피해야합니다.

이는 테이블을 사용하는 모든 뷰와 저장 프로 시저를 이동하거나 변경할 필요없이 기본 테이블의 변경 내용을 전파하려는 뷰 또는 저장 프로 시저와 같은 특수한 경우입니다. 그렇더라도 조인 된 두 개의 뷰가있는 경우와 같이 문제 자체가 발생할 수 있습니다. 하나의 기본 테이블이 변경되고 두 테이블의 이름이 같은 열을 가지기 때문에 뷰가 모호합니다. (이것은 테이블 접두어로 모든 열을 한정하지 않을 때 언제든지 발생할 수 있습니다). 접두사를 사용하더라도 다음과 같은 구문이있는 경우

SELECT A ., B.-클라이언트가 올바른 필드를 선택하는 데 어려움이있을 수 있습니다.

일반적으로 의식적인 디자인 결정을 내리고 관련 위험을 낮게 고려하지 않는 한 SELECT *를 사용하지 않습니다.

0
Cade Roux

SELECT *might 실제로 모든 열이 필요한 경우에는 괜찮지 만 여전히 개별적으로 나열해야합니다. 앱과 DB가 동일한 서버 또는 네트워크에 있더라도 테이블에서 모든 행을 선택해서는 안됩니다. 모든 행을 전송하는 데는 특히 행 수가 증가함에 따라 시간이 걸립니다. 최소한 결과를 필터링하는 where 절이 있어야하고 /거나 결과를 페이징하여 표시해야하는 행의 서브 세트 만 선택하십시오. 필요한 데이터의 하위 집합을 쿼리하고 페이징하는 데 사용하는 앱 언어에 따라 여러 가지 ORM 도구가 있습니다. 예를 들어 .NET Linq to SQL, Entity Framework 및 nHibernate에서 모두 도움이 될 것입니다.

0
bkaid

특정 필드 이름을 사용하므로 누군가가 테이블을 변경하면 예기치 않은 결과가 발생하지 않습니다. 주제 : 항상 삽입을 수행 할 때 필드 이름을 지정하므로 나중에 열을 추가해야하는 경우 프로덕션 릴리스에서 프로그램을 수정하고 데이터베이스를 동시에 변경할 필요가 없습니다.

0
stu

속도가 걱정된다면 준비된 진술을 사용하십시오. 그렇지 않으면 나는 변화가 당신이 자신을 보호하는 것이라고 ilitirit와 함께 있습니다.

앨런

0
Allan Wind

다른 개발자가 코드로 작업하거나 데이터베이스가 변경되어 항상 일관된 데이터를 얻는 경우 열 이름을 나열하는 것이 특히 중요합니다.

0
Sam Cogan

이전 게시물이지만 여전히 유효합니다. 참고로 다음과 같이 구성된 매우 복잡한 쿼리가 있습니다.

  • 12 테이블
  • 6 왼쪽 조인
  • 내부 조인 9 개
  • 12 개 테이블 모두에서 총 108 개의 열
  • 54 열만 필요합니다
  • 4 열 Order By 절

Select *를 사용하여 쿼리를 실행하면 평균 2869ms가 걸립니다. Select를 사용하여 쿼리를 실행하면 평균 1513ms가 걸립니다.

리턴 된 총 행은 13,949입니다.

열 이름을 선택한다는 것은 의심 할 여지가 없습니다.

Sqlplus 프롬프트 또는 db 관리 도구를 통해 DB를 직접 쿼리하려면 *를 선택하십시오. 일반적으로 모든 열을 작성하지 않아도됩니다.

반면에 응용 프로그램 코드에서는 열을 열거하는 것이 가장 좋습니다. 여기에는 몇 가지 이점이 있습니다.

  • 코드가 더 명확합니다
  • 결과가 다시 나오는 순서를 알 수 있습니다 (중요하거나 중요하지 않을 수 있음).
0
Morikal

글쎄, 그것은 실제로 당신의 통계와 목적에 달려 있습니다 :

  1. 250 개의 열이 있고 실제로 열을 모두 선택하려면 같은 날 집으로 돌아가려면 select *를 사용하십시오.
  2. 코딩에 유연성이 필요하고 필요한 테이블이 작 으면 *를 선택하면 코딩 속도가 빨라지고 유지 관리가 쉬워집니다.
  3. 강력한 엔지니어링 및 성능을 원하는 경우 :
    • 열 이름이 몇 개인 경우 열 이름을 쓰거나
    • 열 이름을 쉽게 선택/생성 할 수있는 도구 작성

일반적으로 모든 열을 선택해야 할 때 특별한 이유가없는 한 "select *"를 사용합니다.

마지막으로, 테이블에서 열을 추가 또는 삭제하여 코드 또는 유지 관리에 어떤 영향을 미치겠습니까?

0
Notitze