SELECT *SQL 명령을 작성할 때 SELECT특히 필요한 열에 더 효율적이기 때문에 일반적으로 사용 하는 것이 좋지 않다고 들었습니다 .
SELECT테이블의 모든 열에 필요한 경우 사용해야합니까
SELECT * FROM TABLE또는
SELECT column1, colum2, column3, etc. FROM TABLE이 경우 효율성이 정말로 중요합니까? SELECT *모든 데이터가 실제로 필요한 경우 내부적으로 더 최적 이라고 생각 하지만 데이터베이스에 대한 이해가 부족하다고 말하고 있습니다.
이 경우 모범 사례가 무엇인지 궁금합니다.
업데이트 : 나는 아마 내가 정말 할 수있는 유일한 상황 지정해야 합니다 을 할 수는 SELECT *내가 모든 열은 항상 검색 할 필요가 알고 어디 새로운 열이 추가 된 경우에도, 하나 개의 테이블에서 데이터를 선택하고있을 때입니다.
그러나 내가 본 응답을 감안할 때, 이것은 여전히 나쁜 생각처럼 보이고 SELECT *결코 더 많은 기술적 이유로 사용해서는 안됩니다.
답변
특정 열을 선택하는 것이 더 좋은 이유 중 하나는 SQL Server가 테이블 데이터를 쿼리하지 않고 인덱스에서 데이터에 액세스 할 가능성이 높아지기 때문입니다.
여기에 내가 쓴 게시물이 있습니다 : 선택 쿼리가 잘못된 인덱스 적용 범위를 갖는 실제 이유
데이터를 소비하는 모든 코드는 나중에 테이블 스키마의 변경 사항에 관계없이 동일한 데이터 구조를 갖기 때문에 변경하기가 덜 취약합니다.
답변
을 감안할 때 당신의 당신이 있음을 지정 하는 모든 열을 선택, 약간의 차이가 이 시간에이 . 그러나 데이터베이스 스키마가 변경됨을 인식하십시오. 당신이 사용하는 경우SELECT * , 당신의 코드는 그 새로운 데이터를 사용하거나 제시 할 준비가되어 있지 않더라도, 테이블에 새로운 열을 추가하게 될 것입니다. 이는 시스템이 예기치 않은 성능 및 기능 변경에 노출되고 있음을 의미합니다.
이 비용을 약간의 비용으로 기꺼이 기각 할 수도 있지만 필요하지 않은 열은 다음과 같아야합니다.
- 데이터베이스에서 읽기
- 네트워크를 통해 전송
- 프로세스에 마샬링
- (ADO 유형 기술의 경우) 메모리 내 데이터 테이블에 저장
- 무시 및 폐기 / 가비지 수집
항목 # 1에는 잠재적 인 커버링 색인을 제거하고 데이터 페이지로드 (및 서버 캐시 스 래싱)를 유발하고 행 / 페이지 / 테이블 잠금이 발생하는 등 다른 숨겨진 비용이 발생합니다.
열을 지정하는 *잠재적 절감 효과와 유일한 절약 효과를 비교하면 다음 과 같습니다.
- 프로그래머는 열을 추가하기 위해 SQL을 다시 방문 할 필요가 없습니다.
- SQL의 네트워크 전송이 더 작거나 빠릅니다
- SQL Server 쿼리 구문 분석 / 유효성 검사 시간
- SQL Server 쿼리 계획 캐시
항목 1의 경우 실제로는 추가 할 수있는 새로운 열을 사용하기 위해 코드를 추가 / 변경한다는 것이 현실입니다.
항목 2의 경우, 그 차이만으로도 다른 패킷 크기 나 수의 네트워크 패킷으로 이동할 수 없습니다. SQL 문 전송 시간이 주요 문제가되는 시점에 도달하면 먼저 문 비율을 줄여야합니다.
항목 3의 *경우 어쨌든 확장이 발생해야 하므로 비용을 절약 할 수 없습니다 . 이는 어쨌든 테이블 스키마를 참조하는 것을 의미합니다. 실제로 열을 나열하면 스키마에 대해 유효성을 검사해야하므로 동일한 비용이 발생합니다. 다시 말해 이것은 완전한 세척입니다.
항목 4의 경우 특정 열을 지정하면 쿼리 계획 캐시가 커질 수 있지만 다른 열 집합 (지정하지 않은 열)을 처리하는 경우 에만 가능합니다. 이 경우에, 당신은 원하는 게 필요에 따라 서로 다른 계획을 원하기 때문에 다른 캐시 항목을.
따라서 질문을 지정한 방식으로 인해 최종 스키마 수정에 직면 한 문제 복구에 문제가 발생합니다. 이 스키마를 ROM으로 굽는 경우 (발생), *완벽하게 허용됩니다.
그러나 내 일반적인 지침은 필요한 열만 선택해야한다는 것입니다. 즉, 때로는 모든 열을 요구하는 것처럼 보일 수 있지만 DBA 및 스키마 진화는 쿼리에 큰 영향을 줄 수있는 새로운 열이 나타날 수 있음을 의미합니다 .
내 충고는 항상 특정 열을 선택 해야한다는 것 입니다. 반복해서하는 일에 능숙 해 지므로 올바르게하는 습관을 가지십시오.
코드 변경없이 스키마가 변경 될 수있는 이유가 궁금하다면 감사 로깅, 유효 / 만료 날짜 및 DBA가 규정 준수 문제에 대해 체계적으로 추가하는 기타 유사한 사항을 고려하십시오. 미처리 변경의 또 다른 원인은 시스템 또는 사용자 정의 필드의 다른 곳에서 성능이 저하되는 것입니다.
답변
필요한 열만 선택해야합니다. 모든 열이 필요하더라도 SQL Server가 열에 대한 시스템 테이블을 쿼리하지 않아도되도록 열 이름을 나열하는 것이 좋습니다.
또한 누군가가 테이블에 열을 추가하면 응용 프로그램이 중단 될 수 있습니다. 프로그램은 예상하지 못한 열을 가져오고 처리 방법을 모를 수 있습니다.
이 외에도 테이블에 이진 열이 있으면 쿼리 속도가 훨씬 느려지고 더 많은 네트워크 리소스가 사용됩니다.
답변
select *나쁜 것에 는 네 가지 큰 이유가 있습니다 .
-
가장 중요한 실질적인 이유는 사용자가 열이 반환되는 순서를 마술로 알도록 강요하기 때문입니다. 명시 적으로하는 것이 낫습니다. 테이블 변경에 대해 보호합니다.
-
사용중인 열 이름이 변경되면 더 이상 존재하지 않거나 이름이 변경된 열을 사용하려고 할 때보다는 SQL 호출 시점에서 빨리 잡는 것이 좋습니다. )
-
열 이름을 나열하면 코드가 훨씬 더 자체 문서화되므로 읽기 쉽습니다.
-
네트워크를 통해 전송하는 경우 (또는 그렇지 않은 경우에도) 필요없는 열은 낭비입니다.
답변
누군가 열을 테이블에 추가 / 삽입해도 응용 프로그램에 영향을 미치지 않으므로 일반적으로 열 목록을 지정하는 것이 가장 좋습니다.
답변
서버의 경우 열 이름을 지정하는 것이 훨씬 빠릅니다. 그러나 만약
- 성능은 큰 문제가 아닙니다 (예를 들어, 이것은 각 테이블에 수백, 수천 또는 몇 백만 행이있는 웹 사이트 콘텐츠 데이터베이스입니다). 과
- 당신의 임무는 많은 작고 비슷한 응용 프로그램 을 만드는 것입니다 (예 : 공공 직면 컨텐츠 관리 웹 사이트) 공통 프레임 워크를 사용하기보다는 복잡한 일회성 응용 프로그램을 생성하는 단계; 과
- 유연성이 중요합니다 (각 사이트에 대한 db 스키마의 많은 사용자 정의).
그런 다음 SELECT *를 고수하는 것이 좋습니다. 프레임 워크에서 SELECT *를 많이 사용하면 새로운 웹 사이트 관리 콘텐츠 필드를 테이블에 도입 할 수 있으므로 CMS의 모든 이점 (버전 관리, 워크 플로 / 승인 등)을 제공하는 동시에 수십 점 대신 몇 점.
DB 전문가가 나를 싫어할 것임을 알고 있습니다. 계속 진행하십시오. 투표하십시오. 그러나 저의 세계에서는 개발자 시간이 부족하고 CPU주기가 풍부하므로 보존하는 것과 낭비하는 것을 적절하게 조정합니다.
답변
쿼리가 네트워크를 통해 전송되지 않더라도 SELECT *는 잘못된 방법입니다.
- 필요한 것보다 많은 데이터를 선택하면 쿼리 효율성이 떨어집니다. 서버는 추가 데이터를 읽고 전송해야하므로 시간이 걸리고 시스템 (다른 네트워크, 디스크, CPU 등)에 불필요한로드가 발생합니다. ). 또한 서버는 쿼리뿐만 아니라 쿼리를 최적화 할 수 없습니다 (예 : 쿼리에 커버링 인덱스 사용).
- 얼마 후 테이블 구조가 변경 될 수 있으므로 SELECT *는 다른 열 집합을 반환합니다. 따라서 응용 프로그램이 예기치 않은 구조의 데이터 집합을 가져 와서 다운 스트림 어딘가에서 중단 될 수 있습니다. 열을 명시 적으로 지정하면 알려진 구조의 데이터 집합을 얻거나 데이터베이스 수준 (예 : ‘열을 찾을 수 없음’)에서 명확한 오류가 발생합니다.
물론이 모든 것이 작고 간단한 시스템에는 중요하지 않습니다.
