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

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

SELECT테이블의 모든 열에 필요한 경우 사용해야합니까

SELECT * FROM TABLE

또는

SELECT column1, colum2, column3, etc. FROM TABLE

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

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

업데이트 : 나는 아마 내가 정말 할 수있는 유일한 상황 지정해야 합니다 을 할 수는 SELECT *내가 모든 열은 항상 검색 할 필요가 알고 어디 새로운 열이 추가 된 경우에도, 하나 개의 테이블에서 데이터를 선택하고있을 때입니다.

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

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

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

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

을 감안할 때 당신의 당신이 있음을 지정 하는 모든 열을 선택, 약간의 차이가 이 시간에이 . 그러나 데이터베이스 스키마가 변경됨을 인식하십시오. 당신이 사용하는 경우SELECT * , 당신의 코드는 그 새로운 데이터를 사용하거나 제시 할 준비가되어 있지 않더라도, 테이블에 새로운 열을 추가하게 될 것입니다. 이는 시스템이 예기치 않은 성능 및 기능 변경에 노출되고 있음을 의미합니다.

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

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

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

열을 지정하는 *잠재적 절감 효과와 유일한 절약 효과를 비교하면 다음 과 같습니다.

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

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

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

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

항목 4의 경우 특정 열을 지정하면 쿼리 계획 캐시가 커질 수 있지만 다른 열 집합 (지정하지 않은 열)을 처리하는 경우 에만 가능합니다. 이 경우에, 당신은 원하는 게 필요에 따라 서로 다른 계획을 원하기 때문에 다른 캐시 항목을.

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

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

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

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

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

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

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

select *나쁜 것에 는 네 가지 큰 이유가 있습니다 .

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

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

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

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

누군가 열을 테이블에 추가 / 삽입해도 응용 프로그램에 영향을 미치지 않으므로 일반적으로 열 목록을 지정하는 것이 가장 좋습니다.

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

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

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

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

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

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

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

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

지금까지 여기에 대답 한 많은 이유가 있습니다. 여기에 언급되지 않은 또 다른 이유가 있습니다.

열 이름을 명시 적으로 지정하면 도로를 유지 관리하는 데 도움이됩니다. 어느 시점에서 변경 또는 문제 해결을 수행하고 "사용 된 열이 어디에 있는지"묻는 메시지가 나타납니다.

이름을 명시 적으로 나열한 경우 모든 저장 프로 시저, 뷰 등을 통해 해당 열에 대한 모든 참조를 찾는 것이 간단합니다. DB 스키마에 대한 CREATE 스크립트를 덤프하고이를 통해 텍스트를 검색하십시오.

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

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

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

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

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

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

열을 명시 적으로 나열하는 것이 성능에는 좋지만 열광 할 필요는 없습니다.

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

성능을 추측하지 말고 측정하십시오!

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

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

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

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

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

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

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

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

모든 필드의 데이터를 가져와야하는 경우에만 명시 적 필드 이름을 *보다 사용하는 것이 더 빠릅니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

읽을 수있는 유지 관리 가능한 코드를 찾으려면 다음과 같은 작업을 수행하십시오.

위젯 선택, foo, bar;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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