Самый эффективный способ хранения запросов и количества больших данных SQL

Question

У меня есть база данных SQL Server с большим объемом данных (65 миллионов строк в основном текст, всего 8 ГБ). Данные меняются только один раз в неделю. У меня есть веб-приложение ASP.NET, которое будет выполнять несколько SQL-запросов к этим данным, которые будут подсчитывать количество строк, удовлетворяющих различным условиям. Поскольку данные меняются только один раз в неделю, каков наиболее эффективный способ хранения как SQL-запросов, так и их количества за неделю? Должен ли я хранить его в базе данных или в приложении?

Answer 1

Если данные изменяются только один раз в неделю, как часть и в конце этого (ETL?) Процесса, выполните «базовые» подсчеты и сохраните результаты в таблице в базе данных.После этого вместо длинных запросов к большим таблицам вы можете просто запросить эти небольшие сводные таблицы.

Answer 2

Если вам не требуется точное точное количество строк до 100%, вы можете запросить внутреннюю информацию SQL Server:

Select so.name as 'TableName', si.rowcnt as 'RowCount'
from sysobjects so
inner join sysindexes si on so.id = si.id 
where so.type = 'u' and indid < 2

Очень быстро выполняется и не требует дополнительных таблиц. Не точно, где происходит много обновлений, но может быть достаточно точным для предполагаемого использования. [Спасибо комментаторам!]

Обновление : немного покопался, и это дает точные результаты (медленнее из-за суммы, но все же быстро):

SELECT OBJECT_SCHEMA_NAME(ps.object_id) AS SchemaName, 
       OBJECT_NAME(ps.object_id) AS ObjectName, 
       SUM(ps.row_count) AS row_count
FROM sys.dm_db_partition_stats ps
JOIN sys.indexes i ON i.object_id = ps.object_id
                      AND i.index_id = ps.index_id
WHERE i.type_desc IN ('CLUSTERED','HEAP')
AND OBJECT_SCHEMA_NAME(ps.object_id) <> 'sys'
GROUP BY ps.object_id
ORDER BY OBJECT_NAME(ps.object_id), OBJECT_SCHEMA_NAME(ps.object_id)

Ref .

Помните, что хранимая информация о количестве не всегда была 100% в SQL Server 2000. Для новой таблицы, созданной в 2005 году, Подсчет будет точным. Но для таблицы, которая существовала в 2000 году и сейчас проживает в 2005 году через восстановление или обновление, вам нужно запустить (только один раз после переезда в 2005) либо sp_spaceused @updateusage = N'true 'или DBCC UPDATEUSAGE с опцией COUNT_ROWS.

Answer 3

Запросы должны храниться в виде хранимых процедур или представлений, в зависимости от сложности.

Для вашей ситуации я бы рассмотрел индексированных представлений.

Они позволяют вам обоимсохранить запрос и результирующий набор для таких вещей, как агрегация, которые иначе не могут быть проиндексированы.

В качестве бонуса оптимизатор запросов «знает», что он также имеет эти данные, поэтому, если вы проверяете счетчик или что-то еще, сохраненное в индексе представления в другом запросе (даже в том, который не ссылается на представление напрямую)он все еще может использовать эти сохраненные данные.