2015-01-22 2 views
0

두 테이블의 인덱스에 문제가 있습니다. 인덱스인덱스 조각화 SQL Server

CREATE TABLE [dbo].[Table2] 
(
    [Table2_ID] [int] IDENTITY(1,1) NOT NULL, 
    [TracID] [uniqueidentifier] NOT NULL, 
    [F_URL] [nvarchar](1500) NULL, 
    [S_URL] [nvarchar](100) NULL, 
    [Time] [datetime] NULL, 

    CONSTRAINT [PK_Table2] PRIMARY KEY CLUSTERED ([Table2_ID] 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].[Table2] WITH CHECK 
    ADD CONSTRAINT [FK_Table2_Table] 
    FOREIGN KEY([TracID]) REFERENCES [dbo].[Table] ([Web_Visitor_ID]) 
GO 

ALTER TABLE [dbo].[Table2] CHECK CONSTRAINT [FK_Table2_Table] 
GO 

지수

CREATE NONCLUSTERED INDEX [IX_TracID] ON [dbo].[Table2] 
(
    [TracID] ASC 
) 
    WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
      SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, 
      ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 

CREATE TABLE [dbo].[Table] 
(
    [ID] [uniqueidentifier] NOT NULL, 
    [IP] [nvarchar](15) NULL, 
    [Referrer] [nvarchar](1000) NULL, 
    [Domain] [nvarchar](100) NULL, 
    [RegID] [int] NULL, 
    [Agent] [nvarchar](500) NULL, 

    CONSTRAINT [PK_Table] PRIMARY KEY CLUSTERED 
    ([ID] 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].[Table] 
    ADD CONSTRAINT [DF_Table_ID] DEFAULT (newsequentialid()) FOR [ID] 
GO 

그리고 인덱스

CREATE NONCLUSTERED INDEX [Reg_ID] ON [dbo].[Table] 
(
    [RegID] ASC 
) 
    WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
     SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, 
     ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 

그리고 다른 테이블 : 여기

은 테이블을 만들기위한 코드입니다

첫 번째 표에는 약 6 백만 개의 행과 두 번째 8 백만 개의 행 (매일 2 천 개)이 있습니다.

인덱스가 4 시간 내에 최대 99 %까지 조각화되기 때문에 문제가 있습니다.

나는 쿼리 (sys.columns) 바이트의 크기를 얻을를 실행하고 결과를

이있다
Table 1     Table 2 
name  bytes   name  bytes 
ID   16    ID   4 
IP   30    TracID  16 
Referrer 2000   F_URL  3000 
Domain  200   S_URL  200 
RegID  4    Time   8 
Agent  1000 

사람이 나를 단편화를 해결하기 위해 도움이되는 몇 가지 아이디어 마녀가 있습니까?

+0

인덱스를 다시 작성하는 예약 된 유지 관리 .... –

답변

0

조각 모음이 필요하십니까? 적절한 하드웨어를 사용하면 조각화가 더 이상 중요하지 않습니다. 많은 고학년 SQL 사람들은 여전히 ​​그것을 권장하지만 실제로는 대부분의 경우 과거의 유물입니다.

두 가지 이유가 있습니다. 첫째, 모든 읽기는 RAM에 캐시되어야합니다 (그렇지 않은 경우 더 많은 RAM이 필요합니다. 저렴한 가격으로 조각 모음에 소비하는 노력보다 더 많은 돈을 벌 수 있습니다). 둘째, SSD는 검색 시간을 없애므로 조각화는 부적합합니다. 이 두 가지 변경으로 인해 조각 모음에 소요되는 시간은 일반적으로 낭비됩니다.

+0

99 %의 조각화 된 인덱스를 사용하면 저장 프로 시저가 0.5에서 5 시간 (시간 기간에 따라 다름)에서 작동하지만 조각화 된 인덱스가 0 % 인 경우 분당 20 분 미만으로 끝납니다. 먼저 색인을 수정하는 데 사용하고 그 후에는 저장소 프로 시저를 최적화하기 위해 계속 작업합니다. –

+0

하드웨어는 8GB RAM, 가상 sas 디스크 및 4 코어 프로세서입니다. –

+0

데이터베이스의 캐시 적중률은 얼마입니까? – James