2009-10-09 3 views
0

각 요청을 웹 사이트의 웹 처리기에 기록하는 "기록"테이블이 있습니다. 이 문에 1050 행에 대한SQL Server 2005의 로깅 테이블 성능 향상

/****** Object: Table [dbo].[HistoryRequest] Script Date: 10/09/2009 17:18:02 ******/ 
SET ANSI_NULLS ON 
GO 

SET QUOTED_IDENTIFIER ON 
GO 

CREATE TABLE [dbo].[HistoryRequest](
    [HistoryRequestID] [uniqueidentifier] NOT NULL, 
    [CampaignID] [int] NOT NULL, 
    [UrlReferrer] [nvarchar](512) NOT NULL, 
    [UserAgent] [nvarchar](512) NOT NULL, 
    [UserHostAddress] [nvarchar](15) NOT NULL, 
    [UserHostName] [nvarchar](512) NOT NULL, 
    [HttpBrowserCapabilities] [xml] NOT NULL, 
    [Created] [datetime] NOT NULL, 
    [CreatedBy] [nvarchar](100) NOT NULL, 
    [Updated] [datetime] NULL, 
    [UpdatedBy] [nvarchar](100) NULL, 
CONSTRAINT [PK_HistoryRequest] PRIMARY KEY CLUSTERED 
(
    [HistoryRequestID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] 

GO 

ALTER TABLE [dbo].[HistoryRequest] WITH CHECK ADD CONSTRAINT [FK_HistoryRequest_Campaign] FOREIGN KEY([CampaignID]) 
REFERENCES [dbo].[Campaign] ([CampaignId]) 
GO 

ALTER TABLE [dbo].[HistoryRequest] CHECK CONSTRAINT [FK_HistoryRequest_Campaign] 
GO 

37초 :

SELECT * 
    FROM HistoryRequest AS hr 
WHERE Created > '10/9/2009' 
ORDER BY Created DESC 

사람이를 가속화하기위한 anysuggestions이 있습니까 여기에 테이블 정의는? CREATED 열에 PK 인덱스와 일반 인덱스가있는 클러스터 된 인덱스가 있습니다. 나는 유일한 색인을 시도했다. 그리고 그것은 어딘가에 중복 된 엔트리가 있다고 불평했다 - 예상 할 수있다.

어떤 통찰력도 환영합니다!

답변

1

큰 세트에서 XML 열을 가져올 때 이례적인 행동을 보았습니다. 인덱스를 Created back에 배치 한 다음 select 문에 열을 지정하십시오. XML은 생략하십시오. 이것이 결과의 반환 시간에 어떻게 영향을 미치는지보십시오.

+0

나는 이것을 가지고 놀 것이다. 감사! –

+0

XML 열을 꺼내 새로 만든 테이블 (HistoryRequestExtended)에 놓았습니다. 이 한 가지 조치로 인해 내 성명서가 해제되었으며 다시 신속하게 비명을 지르고 있습니다. (SELECT *를 사용하는 것만 큼 "틀린"것조차도). 감사! :) –

+0

안녕하세요. 문제가 없습니다. 이런 식으로 SQL 2005 데이터베이스의 상점에서 XML 데이터 형식을 사용하지 않는 이유가 있습니다. 대신 우리는 ntext에 데이터를 저장하고 모든 XML 항목을 코드로 처리하는 경향이 있습니다. SQL 2008에서이 기능이 개선되었는지 몇 달 후 알 계획입니다. –

1

로그 테이블의 경우 uniqueidentifier 열은 필요하지 않습니다. 당신도 그것에 대해 질의 할 가능성이 없기 때문에 클러스터 된 인덱스에 대한 좋은 후보는 아닙니다. 샘플 쿼리는 "Created"이지만 아직 인덱스가 없습니다. "생성 된"값의 범위에서 자주 질의하는 경우 반드시 고유하지는 않더라도 클러스터링을위한 좋은 후보가됩니다.

OTOH 외래 키는 Campaign에서 자주 쿼리하는 것이 좋습니다.이 경우 해당 열에서 클러스터링을 수행하는 것이 적절할 수 있으며 삽입 된 키를 인덱스에 분산시키는 것이 더 효과적 일 수 있습니다. 대용 키 시간 소인은 순차적 순서로 레코드를 추가합니다. 이는 노드 섹터가 덜 랜덤하게 채워지기 때문에 시간이 지남에 따라 순차적으로 작업합니다.

단지 로그 테이블 인 경우 왜 감사 감사 열이 있습니까? 일반적으로 쓰기 전용입니다.

4

비공개 색인 (생성됨)에 대해 모든 열 (*)을 요청하고 있습니다. 대규모 데이터 세트에서는 Index Tipping Point에 클러스터 된 인덱스 검색이 클러스터되지 않은 인덱스 범위 탐색 및 책갈피 조회보다 더 효율적이라는 것을 알 수 있습니다.

* 항상 필요합니까? 그렇다면 일반적인 액세스 패턴이 이와 같으면 그에 따라 테이블을 구성하고 가장 왼쪽의 클러스터 된 키를 만들어야합니다.

그렇지 않으면 커버 할 수있는 쿼리로 쿼리를 변경하십시오. 예 : 비 클러스터형 인덱스에서 다루는 HistoryRequestID와 Created 만 선택하십시오. 더 많은 필드가 필요한 경우 클러스터되지 않은 인덱스에 포함 된 열로 추가하십시오. 그러나 추가 스태킹 공간과 IO 로그 쓰기 시간이 추가됩니다.

+0

죄송합니다 - SELECT *는 SQL Mangler에서 벗어났습니다. 나는 실제 코드를 이렇게 쓰지 않는다. 나는 문제를 추적하려고했고 "SELECT *"로 데이터를 파고 있었다. 나는 또한 정확한 진술에 대한 질의 계획을 세웠고 100 %가 인덱스 스캔을 했음에도 테이블 스캔은 보여지지 않았습니다. –

+0

클러스터 된 인덱스 스캔 또는 클러스터되지 않은 dindex 스캔 이었습니까? 클러스터형 인덱스 스캔은 "테이블 스캔"과 동일합니다. 클러스터형 인덱스 *가 테이블이기 때문입니다. –

0

색인을 다시 작성하십시오. 테이블 이름 다음에 WITH (NOLOCK) 절을 사용하십시오. 실제 환경 (예 : 로그 파일)에서 자주 사용되는 테이블에 대해 실행중인 긴 (ish) 쿼리를 실행하려는 경우에 해당됩니다. 기본적으로 쿼리 마이그레이션은 일부 최신 레코드를 놓치지 만 테이블에 자물쇠를 열지는 않아 추가 오버 헤드가 발생합니다.

+0

또한 더 자주 사용하려면 날짜 열의 클러스터를 placign하십시오. – redcalx