Доброго времени суток!
Всех с праздником!
Dmitry Yemanov пишет:
Может. В данном случае индекс в detail-таблице был использован для
предиката t2.id2 = 3, для которого есть ровно одна запись. Отсюда 10
чтений. Это недочет оптимизатора, конечно, но ведь равенство имеет
приоритет над distinct (т.к. потенциально сильнее ограничивает выборку).
А, дошло, спасибо.
Даже, если бы движок начинал анализ с условия t2.id2 = 3
(которое действительно требует 10 чтений), что ему мешает
использовать этот же индекс для t1.ID1 is not distinct from t2.ID2 ?
А вот это вопрос хороший. Надо будет покопаться. Подозреваю, что
стоимость с двумя индексами оказывается выше, чем с одним.
Наверное, на практике преимуществ действительно не будет. Впрочем, можно
построить синтетический пример, на котором использование двух индексов
должно дать выигрыш
table1 - содержит 10 записей с id = 3 и 990 с id = 0
table2 - содержит 1000 записей с id = 3 и 9000 с id = 1
select * from table1 t1 left join table2 t2
on t1.ID is not distinct from t2.ID and t2.id = 3
При использовании одного индекса для t2.id = 3 - 1000*1000 чтений
table2, если использовать два - 1000*10.
Впрочем, пример с is not distinct, к сожалению, изначально кривой - ясно
же, что t1.ID is not distinct from t2.ID and t2.id = 3 равносильно
t1.id = t2.id and t2.id = 3. Возможно, стоило взять вместо is not
distinct неравенство для большего правдоподобия.
P.S.
Все же непонятно, почему для полностью эквивалентных запросов с
OR-связкой из предыдущего поста получаем такую разницу в числе чтений.
Сервер не использует индекс для t2.ID2 is null?
С уважением, Евгений
