Пейджинг через большой стол в sql 2005

У меня есть таблица с 15 столбцами и 6,5 млн. Записей. Мне нужно получить доступ к этой таблице со стороны C # с помощью пейджинга. Я написал СП, но для получения данных требуется около 1,30 минуты. вот мой Stored Proc –

Create Proc demo ( @startRowIndex int, @maximumRows int ) AS DECLARE @first_id int, @startRow int SET @startRowIndex = (@startRowIndex - 1) * @maximumRows IF @startRowIndex = 0 SET @startRowIndex = 1 SET ROWCOUNT @startRowIndex SELECT @first_id = RecordID FROM edd_business_listings_05282009 ORDER BY RecordID PRINT @first_id SET ROWCOUNT @maximumRows SELECT * FROM edd_business_listings_05282009 WHERE RecordID >= @first_id ORDER BY RecordID SET ROWCOUNT 0 

Кто-нибудь знает способ сделать это быстрее.

Может ли ваше приложение отправить последний идентификатор записи?

Сделайте работу с интерфейсом более сложной.

Создать демо Proc (@startRowID int, @maximumRows int) AS

SET ROWCOUNT @maximumRows

SELECT * FROM edd_business_listings_05282009 WHERE RecordID> @startRowID ORDER BY RecordID

SET ROWCOUNT 0

Попробуйте использовать ROW_NUMBER в SQL 2005: http://www.4guysfromrolla.com/webtech/010406-1.shtml

Подобная процедура помогла бы:

 CREATE PROCEDURE dbo.GetListingPaged ( @StartRowIndex int, @MaximumRows int ) AS SELECT RecordID, Field2 -- Not * FROM ( SELECT RecordID, Field2 -- Not * ROW_NUMBER() OVER (ORDER BY RecordID) AS RowRank FROM edd_business_listings_05282009 ) AS ListingWithRowNumbers WHERE RowRank > @StartRowIndex AND RowRank <= (@StartRowIndex + @MaximumRows) GO 

Хорошо, конечно, вот и моя догадка:

 Create Proc demo ( @startRowIndex int, @maximumRows int ) AS DECLARE @first_id int, @startRow int SET @startRowIndex = (@startRowIndex - 1) * @maximumRows IF @startRowIndex = 0 SET @startRowIndex = 1 SELECT TOP (@maximuRows) {'all columns except N'} FROM ( Select *, ROW_NUMBER() Over(Order by RecordID) as N from edd_business_listings_05282009 ) As t WHERE N >= @startRowIndex ORDER BY RecordID 

Лучшее решение будет сильно зависеть от

Как часто изменения данных

2. часто вызывается sproc и насколько глубоко пользователь будет типичным для всех страниц и

3.Выдайте много времени ожидания (если таковые имеются), которые вы можете принять в обновлении заказа.

Часто на бэкэнд веб-сайта ваши пользователи используют только первые несколько страниц, но бот-бот может взломать ваши глубокие страницы и, следовательно, заблокировать ваш процессор. Обычно поддерживать этот живой порядок можно только до определенной точки (например, используйте row_number () для первых нескольких сотен или тысяч строк), а затем переключитесь на денормализованный список заказов, который обновляется через некоторый интервал (возможно, ежечасно).

Попробуйте поместить индекс в столбец RecordId. Я думаю, что это происходит, когда вы выполняете сканирование всей таблицы до того, как строка имеет место, поэтому Sql может заказать все. Если у вас уже есть индекс, чем что-то еще, проблема. Я сделал этот же запрос в таблицах с вдвое большим количеством записей, и время выполнения не превышало 2 секунды.

Использование ROWCOUNT или Row_Number () должно технически выполнить ту же самую производительность, но я бы использовал Row_Number (), поскольку это более современный способ сделать это, и установка rowcount имеет гораздо более сложные функции, чем Row_Number (), что я не буду попасть в.

Если вы используете SQL Server 2005, вы можете попробовать

 SELECT field1, field2, fieldN FROM (SELECT ROW_NUMBER() OVER (ORDER BY RecordID) AS Row, field1, field2, fieldN FROM edd_business_listings_05282009) AS ListingsWithRowNumbers WHERE Row >= @startRowIndex AND Row <= @startRowIndex + @maximumRows 

Но в любом случае попытайтесь переосмыслить эту архитектуру. Какая польза для отображения миллионов записей (даже выгруженных) в пользовательском интерфейсе? Вы можете попытаться ограничить количество записей и запросить только подмножество изначально …

  • Получить общее количество строк при подкачке
  • Подкачка базы данных
  • Msgstr "Неправильный синтаксис около 'OFFSET' 'modift sql comm 2012 по 2008 год
  • Возврат итоговых записей из SQL Server при использовании ROW_NUMBER
  • Производительность пейджинга Nhibernate на большом столе (10 000 000 строк)
  • Есть ли проблема с производительностью с использованием Row_Number для реализации подкачки таблиц в Sql Server 2008?
  • Давайте будем гением компьютера.