데이터의 논리적 구조 테이블 및 인덱스 구조 힙 구조 - Clustered Index가 없는 테이블의 경우 비클러스터형 인덱스 구조 트리 구조의 인덱스의 마지막 단계인 리프노드에 해당 인덱스 키의 값과 데이터 페이지의 참조 정보 저장 따라서 비클러스터형 인덱스 키만 가지고 조회를 하는 경우 데이터 페이지를 바라보지 않고 조회를 하게 되어 빠른 검색이 가능함 인덱스의 수정이 발생시 인덱스페이지가 추가되며 각 인덱스 페이지 간 이전, 다음 페이지의 관계가 맺어짐 (해시 테이블 과 같은 원리) 클러스터형 인덱스 구조 - Clustered Index를 가지고 있는 테이블 데이터 행은 Clulstered Index Key에 기반한 순서대로 저장됨 인덱스에 대한 키,값을 가진 리프노드가 없이 바로 해당 인덱스 키로..

데이터 파일 주 데이터 파일[.mdf]과 보조데이터 파일[.ndf]로 구분 기본[디스크가 꽉 찰 때까지 10%씩 자동 증가]로그 파일 가상 로그파일 [.ldf] 최소 단위 256kb로 구성 기본[최대 2TB (2008 기준) 10%씩 자동 증가] page page에 들어가는 항목 8가지 : [msdn 링크] 페이지 유형 내용 데이터 text in row가 ON으로 설정된 경우에 text, ntext, image, nvarchar(max), varchar(max), varbinary(max) 및 xml 데이터를 제외한 모든 데이터가 있는 데이터 행 인덱스 인덱스 항목 텍스트/이미지 큰 개체 데이터 형식: text, ntext, image, nvarchar(max), varchar(max), varbinar..

데이터가 있는 컬럼에 대해 인덱스가 만들어질 떄 이 컬럼 값의 히스토그램 및 관련 정보로 구성되는 통계(statistics)가 만들어진다. 검색 조건이 주어질 때 해당 컬럼으로 구성되는 인덱스를 사용할지 여부를 최적화기가 결정하게 되는데 이때 판단의 근거자료로 활용하는 것이 통계이다. 따라서 통계가 업데이트 되지 않은 시점에서 검색조건을 판단하게 되면 최적화된 검색이 이루어지지 않게 된다. 인덱스에 관한 통계는 DBCC SHOW_STATISTICS 명령을 통해 확인할 수 있다. (msdn 참조) 구문은 다음과 같다. DBCC SHOW_STATISTICS ( table_or_indexed_view_name , target ) [ WITH [ NO_INFOMSGS ] [ , n ] ] <..

쿼리 튜닝을 아무리 잘 하였다고 하더라도 데이터의 양에 따라 성능이 좌우될 수 있다. 많은 양의 insert, delete 및 update가 이루어지는 테이블의 경우 쉽사리 clustered index를 걸기 힘들다. 이는 인덱스의 재 갱신에 대한 부담이 크기 때문이며, 이런 경우 clustered index는 단순히 identity 컬럼으로 지정하고, 기타 컬럼을 index 지정하여 호출하게 된다. 하지만 이렇게 지정한 index도 문제가 발생할 소지가 있다. 많은 양의 delete와 insert, update가 이루어지면 점차적으로 index가 조각나버리게 된다. 이러한 인덱스 단편화 현상에 대한 체크가 가능하다. dbcc 명령어중 show contig라는 명령어이다. (msdn 참조) 문법은 다음과..

prototype 속성은 객체에 새로운 속성이나 메소드를 추가할 때 사용한다. 그냥 추가하면 되는데 왜 prototype이란 개념이 있을까? '함수의 호출 - 3. 생성자 호출 패턴'에서 사용한 호출 구문을 보자. var A = function(string) { this.aValue = string; this.getValue = function() { return this.aValue; } } var a = new A("a의 값"); document.write(a.getValue()); 예제1. 생성자 A는 aValue라는 속성과, getValue라는 메소드를 가지고 있다. 위에서 선언한 A 생성자를 prototype을 이용하면 다음과 같다. var A = function(string) { this.aV..