Я полностью смущен этим. Я добавил покрывающий индекс в таблицу SQL Server 2017, и мои интеграционные тесты не сработали.
Вот простой пример SQL, иллюстрирующий проблему:
CREATE TABLE MyColumns (ColumnID INT PRIMARY KEY, LookupCodeTypeID INT)
INSERT INTO MyColumns (ColumnID, LookupCodeTypeID)
VALUES (18, 37)
CREATE TABLE MyCodes (CodeID INT PRIMARY KEY, CodeTypeID INT, Code NVARCHAR(50), IsDeleted BIT)
INSERT INTO MyCodes (CodeID, CodeTypeID, Code, IsDeleted)
VALUES (1, 12, 'North', 0), (2, 12, 'South', 0), (19, 37, '0', 0),
(20, 37, '1', 0), (21, 37, '2', 1), (22, 37, '3', 0)
SELECT CAST(Code AS INT) AS CodeIndex
FROM MyCodes
INNER JOIN MyColumns ON LookupCodeTypeID = CodeTypeID
WHERE ColumnID = 18 AND IsDeleted = 0
ORDER BY CodeIndex
-- This index was created for other reasons but the following SQL broke
CREATE NONCLUSTERED INDEX IX1_MyCodes ON MyCodes (CodeTypeID) INCLUDE (Code)
SELECT CAST(Code AS INT) AS CodeIndex
FROM MyCodes
INNER JOIN MyColumns ON LookupCodeTypeID = CodeTypeID
WHERE ColumnID = 18 AND IsDeleted = 0
ORDER BY CodeIndex
Индекс был создан для решения другой проблемы. в другом месте, но неудачные тесты привели меня к этому коду.
Из попытки создать пример для воспроизведения проблемы я вижу, что для этого кода добавление IsDeleted в индекс покрытия решит проблему, но этоне то, что я ожидал.
Поскольку тесты выявили проблему, я добавлю IsDeleted к покрывающему индексу.
Мой вопрос: ПОЧЕМУ произошел разрыв SQL и как я могу предсказатьчто еще может сломаться, поскольку только у нашего кода есть интеграционные тесты?