V... будет работать быстрее, ..., потому, что проверка на СУЩЕСТВОВАНИЕ множества (достаточно убедиться, что записей >0) (почти) всегда быстрее проверки на попадание в множество (перебор значений). Когда разработчикам удается сделать IN по времени выполнения не хуже exists для каких-то конкретных ситуаций - они пишут об этом самыми крупными красными буквами на заглавных страницах своих сайтов.

ага. Доходит до идиотизма (в Аксессе) сплошь и рядом:
Select a from t where t.id IN (select трам-пам-пам, без ссылок на поля t из внешнего) (1)
считается часами. Ибо:
пусть в t - млн записей, а (select трам-пам-пам) за долю секунды возвращает {набор}, т.что такой-вот запрос считается в лет
Select a from t where t.id IN ({набор}) (2)
Но изначальный набор будет считаться не так, как вам кажется естественным - вернуть набор из внутреннего in, а потом, воспользовавшись индексом, получить результат из большой таблицы. Нет, будет считаться ТОЧНО так же как и экзист, (где, естественно, внутрь экзистного селекта передается t.id, и примерно с той же скоростью), т.е. для каждой записи из t, будет заново пересчитываться весь внутренний запрос (как будто он поменялся с предыдущей записи) и т.п. В таких случаях получение {набора} из внутреннего запроса отдельно и подстановка его в виде строки (значений с разделителями) во внешний (какой-нить ф-ей) ускоряет запросы на несколько порядков.