밀론 이상의 행이있는 테이블이 있습니다. 이 표는 tiff 개의 이미지를 색인하는 데 사용됩니다. 각 이미지에는 date, number 등과 같은 필드가 있습니다. 사용자에게 500 개의 일괄 처리 이미지를 색인화합니다. 먼저 500 행을 삽입 한 다음 500 개의 업데이트를 수행하거나 사용자가 색인 생성을 완료하면 더 나은지 알아야합니다. 모든 데이터와 함께 500 개의 인서트를하십시오. 매우 중요한 것은 제가 처음에 500 개의 인서트를 작성하면, 전날 밤에 할 수 있기 때문에 이번에는 무료입니다.삽입 비용 대 SQL Server의 업데이트
질문 : 삽입 또는 삽입 및 업데이트를하는 것이 더 좋은 이유는 무엇입니까? 각 이미지에 대해 id 값을 정의했으며 필드에 다른 인덱스가 있습니다.
SQL 서버의 업데이트 결과 고스트 행이 생깁니다. 즉, Sql은 행 하나를 교차하여 새 행을 삽입합니다. 교차 행은 나중에 삭제됩니다.
삽입 및 업데이트 모두 이러한 방식으로 페이지 분할을 유발할 수 있습니다. 둘 다 효과적으로 데이터를 '추가'합니다. 업데이트가 먼저 오래된 것을 플래그로 표시합니다.
이 업데이트의 맨 위에는 많은 데이터가 업데이트보다 오래 걸릴 수있는 행을 먼저 찾아야합니다.
인서트는 항상 빠르게 처리됩니다. 특히 순서가 있거나 기본 테이블에 클러스터형 인덱스가없는 경우에는 더욱 빠릅니다.
테이블에 더 많은 양의 데이터를 삽입 할 때 현재 인덱스를 살펴보고 변경하고 빌드하는 데 시간이 오래 걸릴 수 있습니다. 인덱스 중간에 값을 추가하면 항상 속도가 느려집니다.
당신은 주소록에 추가하는 것처럼 생각할 수: 미스터 Z 그냥 마지막 페이지에 추가 할 수 있습니다, 당신이 씨 M.
나는 데이타베이스 사람이 아니지만, 삽입이 수행하는 동안 업데이트가 조회를 필요로하므로 한 번에 삽입하는 것이 더 빠를 것이라고 생각한다.
삽입물을 먼저 수행 한 다음 몇 가지 이유로 업데이트가 더 좋은 것으로 보입니다. 거래량이 적은 시간에 삽입하게됩니다. 삽입물에는 더 많은 데이터가 있으므로이 작업을 수행하는 것이 좋습니다.
업데이트를 위해 id 값 (아마도 인덱싱 됨)을 사용하고 있으므로 업데이트의 오버 헤드가 매우 낮습니다. 또한 업데이트하는 동안 데이터가 적습니다.
일괄 처리 (500 개 삽입/업데이트) 수준에서 트랜잭션을 해제하고 개별 레코드에 사용하여 일부 오버 헤드를 줄일 수도 있습니다.
마지막으로 최종 결정을 내리기 전에이를 테스트하여 서버의 실제 성능을 확인하십시오.
각 쿼리에 대한 실행 계획은 어느 것이 더 비싸야하는지 알려줍니다. 실질적인 제한 요소는 디스크에 쓰는 것이므로 perfmon을 실행하는 동안 쿼리를 통해 쓰기가 더 많이 발생하는지 확인하고 디스크 큐가 가장 길어 지거나 (오래 걸리는 경우) 몇 가지 테스트를 실행해야 할 수도 있습니다.
이것은 잘랐다가 건조한 질문이 아닙니다. 크리슈나와 갈리 지안의 포인트가 있습니다.
업데이트의 경우 업데이트로 인해 고정 길이 필드가 영향을받는 경우 영향이 줄어 듭니다. varchar 또는 blob 필드를 업데이트하는 경우 새 값이 이전 값의 길이를 초과하면 업데이트 도중 페이지 분할 비용을 추가 할 수 있습니다.
삽입이 더 빠르게 실행될 것 같습니다. 그들은 lookup을 필요로하지 않는다. (당신이 update 할 때 당신은 기본적으로 where 절을 가지고 select와 같은 일을한다.) 또한 삽입은 업데이트 방식과 같이 행을 잠그지 않으므로 동시에 테이블에 대해 발생하는 선택을 방해하지 않습니다.
조반니에 대한 중간에 공간을 발견해야합니다 동안, 그것은 또한 것이다 인덱싱 (클러스터 또는 비 클러스터) 및 채우기 비율과 같은 다른 문제에 의존합니다. 귀하의 특정 상황은 귀하의 진행 방식에 크게 기여할 것입니다. – Galwegian