/*
SET NOCOUNT ON
CREATE TABLE #tmp(userId INT NOT NULL, productId INT NOT NULL, CONSTRAINT pk_Temp PRIMARY KEY(userid, productId))
DECLARE @u INT = 0
DECLARE @p INT = 0
WHILE @u < 100000
BEGIN
SET @u = @u + 1
WHILE @p < 29
BEGIN
SET @p = @p + 1
IF RAND() * 100 < 99
BEGIN
INSERT INTO #tmp
VALUES (@u, @p)
END
END
SET @p = 0
END
SET NOCOUNT OFF
DROP TABLE #tmp
DROP INDEX ix_TempOne ON #tmp
CREATE NONCLUSTERED INDEX ix_TempOne ON #tmp (userId)
DROP INDEX ix_TempTwo ON #tmp
CREATE NONCLUSTERED INDEX ix_TempTwo ON #tmp (userId) INCLUDE(productId)
DROP INDEX ix_TempThree ON #tmp
CREATE NONCLUSTERED INDEX ix_TempThree ON #tmp (productId)
DROP INDEX ix_TempFour ON #tmp
CREATE NONCLUSTERED INDEX ix_TempFour ON #tmp (productId) INCLUDE (userId)
*/
begin transaction t1
IF OBJECT_ID('tempdb..#tmp2') IS NOT NULL
DROP TABLE #tmp2
DECLARE @date DATETIME = GETDATE()
SELECT userId INTO #tmp2 FROM #tmp WHERE userId BETWEEN (SELECT FLOOR(RAND() * (100+1)+1)) AND (SELECT FLOOR(RAND() * (100000+1)+1))
SELECT DISTINCT productId FROM #tmp WHERE UserId IN (SELECT UserId FROM #tmp2)
SELECT CAST(DATEDIFF(millisecond, @date, GETDATE()) AS VARCHAR) + ' miliseconds' + CHAR(10)
Это пример, похожий на одну из наших кеш-таблиц, по которой мы фильтровали.
На основе результирующего набора (созданного в # tmp2) мы хотим знать, какой ProductId по-прежнему соответствует отфильтрованным параметрам.
(Случайная часть просто добавлена для создания динамического набора результатов)
В настоящее время я установил первичный ключ для userId и productId и у меня есть индекс «TempTwo» и «TempFour» в моей базе данных, но запрос по-прежнему будет вызывать 400-1000 миллисекунд, когда я хочу, чтобы он был меньше 100 миллисекунд. .
Можно ли мне изменить концепцию таблицы или изменить способ сбора информации, чтобы получить результат в течение 100 миллисекунд?
Таблица является кеш-таблицей, которая обновляется только один раз.