Сколько времени занимает выбор в запросе при выборе из таблицы с ~ 200 миллионами строк в SQL Server 2005? - PullRequest
Новая
       38

Сколько времени занимает выбор в запросе при выборе из таблицы с ~ 200 миллионами строк в SQL Server 2005?

0 голосов
/ 29 марта 2011

У меня есть таблица с 193 569 270 строк в базе данных SQL Server 2005.В таблице представлены действия, выполняемые пользователями нашего сайта.Таблица определяется как: 

<b>Name</b>                  <b>DataType</b>
ID                    int (identity)             PK
ActivityTime          datetime
PersonID              int                        (should be an FK, but isn't)
ActivityTypeID        int                        (should be an FK, but isn't)
Data1                 varchar(50)
Data2                 varchar(50)

У меня есть следующие индексы: 

CREATE NONCLUSTERED INDEX [_MS_Sys_3] ON [dbo].[tblPersonActivity] ([PersonID] ASC)
INCLUDE ( [ID], [ActivityTime], [ActivityTypeID], [Data1], [Data2]) 
WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [IX_Activity] ON [dbo].[tblPersonActivity] ([PersonID] ASC, [ActivityTypeID] ASC, ActivityTime] ASC)
WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [IX_tblPersonActivity_PersonArchive] ON [dbo].[tblPersonActivity] ([ActivityTime] ASC)
INCLUDE ([ID], [PersonID], [ActivityTypeID], [Data1], [Data2]) 
WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

ALTER TABLE [dbo].[tblPersonActivity] ADD  CONSTRAINT [PK_tblPersonActivity] PRIMARY KEY CLUSTERED ([ID] ASC)
WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

Это запрос, который я написал: 

declare @archiveDate            datetime
declare @curDate                datetime
declare @startDate              datetime
declare @curYear                int
declare @preYear                int

set @curDate = getdate()
set @curYear = year(@curDate)
set @preYear = @curYear - 1
set @archiveDate = @curDate
set @startDate = cast(('1/1/' + cast(@preYear as varchar(4))) as datetime)

declare @InactivePersons table
    (PersonID       int     not null PRIMARY KEY)

insert into @InactiveBuyers
    select 
        b.PersonID 
    from 
        HBM.dbo.tblPersons b with (INDEX(IX_tblPersons_InactiveDate_PersonID), nolock)
    where 
        b.InactiveDate is not null 
        and b.InactiveDate  '1/1/1900' 
        and b.InactiveDate  '12/31/1899' 
        and b.InactiveDate = @StartDate

ПоследнийКогда я выполнял запрос, он выполнялся более 1 дня, прежде чем я его убил.Я что-то пропустил или это займет столько времени?

Спасибо за любую помощь, которую вы можете оказать.

Уэйн Э. Пфеффер

1 Ответ

0 голосов
/ 29 марта 2011

Нет, это не займет много времени, если ваша база данных правильно настроена и проиндексирована.

Сначала вам нужно создать эти ФК! Нет оправдания тому, что они не обеспечивают целостность ваших данных. ФК должны иметь свои собственные индексы.

Неактивные даты не отображаются в вашей структуре таблицы. Это поле даты? Сделайте это одним, если это не так, или вы тратите время, делая неявные преобразования. 

b.InactiveDate is not null 
        and b.InactiveDate  '1/1/1900' 
        and b.InactiveDate  '12/31/1899' 
        and b.InactiveDate = @StartDate

Это все, где пункт не имеет смысла. Если вы ищете записи, которые соответствуют @startdate, то вам ничего не нужно.

Проверьте план выполнения, чтобы увидеть, где это занимает так много времени, что-то вызывает сканирование таблицы.

И если в таблице будет большое количество записей varaible, то временная таблица будет работать быстрее. Вы не говорите, что делаете с этой таблицей в оставшейся части процесса, вы уверены, что это оператор вставки, который занимает больше всего времени или что-то еще, что вы делаете?

...