Алексей,

Вам invm не просто так ссылку скинул.
Скорее всего дело в top, скорее всего используется row goal. В 2017 CU3 в плане показывается используется он или нет.
Для того чтобы посчитать кол-во строк ему нужно знать селективность соеденеия и кол-во строк в таблице.
Если интересно покапайтесь с включенными (НЕ ДОКУМЕНТИРОВАННЫМИ) флагами: 3604, 2363
Также можно использовать флаги 8607 и 8712, на выходе дерево физических оператор.
Подробнее http://www.queryprocessor.ru/rowgoal-on-non-uniform-distribution/

Алексей,

Немного дополню свой ответ простым примером.
Предположим у нас есть таблица Table (id int, num int), статистика свежая, есть PK по id, по num ничего нет. В таблице 65552 строки, num равен id, т.е. по сути поле тоже уникально, на нем нет индекса, но есть статистика.
Теперь я выполню:


Вернулось 7 строк. План обычный - Select --> Top --> Clust. scan
Смотрим на ожидание, если смотреть без флага 9130, то est. num of rows 7, чтобы увидеть нужной нам на плане, включает этот флаг, теперь фильтр у нас в плане "отдельно", теперь ожидание у нас 459.323 (Actual num of rows 7). Также можно посмотреть ожидание RowGoal с помощью 8607, 8612, как в ссылке выше.
Теперь разбираемя откуда он взял 459.323. Включаем флаг 2363 и смотрим. Сначала посмотрим какую статистику он загрузил, там должна быть строчка : Loaded histogram for column : Table.num from stats with id = 2 (у меня, у вас может быть другое). Смотрим что это за статистика, можно через sys.stats с нашим object_id.
Далее здесь смотри selectivity для нашего скана, она равна 0.0152398, в данном случае она считается 999\65552 (причем 6552 это данные с статистики)
Также ниже можно увидеть кардинальность нашего фильтра, это будет 999: 0.0152398 * 65552 (а вот сейчас 65552 это уже метаданные нашей таблицы, т.е. если бы в к примеру у нас в таблице было 64500 строк, но в статистике было бы 65552, то эта цифра была бы 982.968: 0.0152398 * 64500. Кстати, если в таком случе убрать top, то это будет наш estimated number of rows у скана), но в случае с RowGoal, эти данные как я понимаю не используются (конкретно в моем примере).
Я отвлекся, так откуда взялось 459.323, да все просто, зная селективность оптимизатор, учитывая равномерное распределение данные может оценить, сколько надо отсканить чтобы получить 7 строк : 7\0.0152398, если бы был top 6 то ожидаемое кол-во строк было бы 393.706

P.S. Не буду делать вида что полностью понимаю все кишки оптимизатора, на эту тему преступно мало статей, поэтому возможно где-то ошибся, скажу спасибо если меня поправят.

TaPaK,

Я это понимаю, я имел ввиду что в данном случе, без соедения, когда from просто из одной таблицы и используется rowgoal то кардинальность считается, но не влияет на кол-во ожидаемых строк.
А так да, кардинальность используется дальше, к прмиру я задавал Дмитрию вопрос, скопирую его сюда.

I have one more question, it doesn't relate to this article, but it's about estimator.

There is a query:

SELECT *
FROM [TSQL2012].[dbo].[Employees] as e
join sales.Orders as o on e.ID = o.empid
where (e.ID > 63000 and e.ID < 65000) or e.ID = 1

Employees has 63900 rows (in stat 65552), orders has 830 (in stat 830).
At the top of the plan there's seek on Employess Clustered index, at the bottom scan on Orders.
Selectivity of the seek is 0.0305101 and estimated number of rows 1949.6
Scan has selectivity of 1 and and estimated number of rows 830.
Then there is merge join, it has selectvity 7.40964e-005 and estimated number of rows 119.9
I understand how it calculated 119.9 ( 7.40964e-005 * 1949.6 * 830), but i don't understand where he got 7.40964e-005.
I have read your article http://www.queryprocessor.c...
And it uses CselCalcExpressionComparedToExpression calculator, but in your article you didn't explain how exactly it calculate selectivity for this calculator.
I hope you explain that.
You write very interesting articles.Thanks again.

Здесь видно что кардинальность использовалась в merge join для подсчета estimated number of rows.