Что делает SQL-оператор sargable?
В строке запроса нет ключевого слова запроса, а также есть дополнительная скобка. Это должно быть следующим
fetch({
query: `
query transactions {
transactions(limit: 3) {
tid
terminalNo
issuerId
}
}
`,
})
3 ответа
Наиболее распространенная вещь, которая делает запрос неразборчивым , - это включение поля внутри функции в предложении where:
SELECT ... FROM ...
WHERE Year(myDate) = 2008
Оптимизатор SQL не может использовать индекс myDate, даже если он существует. Буквально придется оценивать эту функцию для каждой строки таблицы. Намного лучше использовать:
WHERE myDate >= '01-01-2008' AND myDate < '01-01-2009'
Некоторые другие примеры:
Bad: Select ... WHERE isNull(FullName,'Ed Jones') = 'Ed Jones'
Fixed: Select ... WHERE ((FullName = 'Ed Jones') OR (FullName IS NULL))
Bad: Select ... WHERE SUBSTRING(DealerName,4) = 'Ford'
Fixed: Select ... WHERE DealerName Like 'Ford%'
Bad: Select ... WHERE DateDiff(mm,OrderDate,GetDate()) >= 30
Fixed: Select ... WHERE OrderDate < DateAdd(mm,-30,GetDate())
Не делайте этого:
WHERE Field LIKE '%blah%'
Это вызывает сканирование таблицы / индекса, поскольку значение LIKE начинается с символа подстановки.
Не делайте этого:
WHERE FUNCTION(Field) = 'BLAH'
Это вызывает сканирование таблицы / индекса.
Сервер базы данных должен будет сравнить FUNCTION () с каждой строкой таблицы, а затем сравнить ее с BLAH.
Если возможно, сделать это в обратном порядке:
WHERE Field = INVERSE_FUNCTION('BLAH')
This запустит INVERSE_FUNCTION () для параметра один раз и все равно разрешит использование индекса.
В этом ответе я предполагаю, что база данных имеет достаточные индексы покрытия. Есть достаточно вопросов по этой теме .
Во многих случаях определяемость запроса определяется переломным моментом связанных индексов. Переломный момент определяет разницу между поиском и сканированием индекса при соединении одной таблицы или набора результатов с другой. Один поиск, конечно, намного быстрее, чем сканирование всей таблицы, но когда вам нужно искать много строк, сканирование может иметь больше смысла.
Так что, помимо прочего, оператор SQL более уместен, когда оптимизатор ожидает, что число результирующих строк в одной таблице будет меньше, чем переломный момент возможного индекса в следующей таблице.
Вы можете найти подробное сообщение и пример здесь .