Добрый день коллеги. Почему такое расхождение? Пробовал полностью перестроить индексы

с обновлением статистики. Не помогло.

Не совсем понял Ваши действия. Надо либо Rebuild всех индексов, либо update statistics with full scan

Объясню. Недавно работаю на текущем месте. Заметил что в большинстве запросов такая ситуация как на скрине, оптимизатор запросов неверно рассчитывает количество строк. Вчера уже взял пример запроса, на тестовой базе попробовал поиграться с индексами на конкретной таблице. Перестраивал индекс, обновлял статистику, удалял индексы и заново создавал, результат не меняется. при любых манипуляциях одинаковое время выполнения и количество строк. При этом сам скуль показывает что фрагментация индексов 0.

Так надо слать DDL таблиц Запрос План - полностью , не огрызок И тогда можно обсуждать

Хорошо. Попозже скину сам запрос и план обслуживание который использовал для индексов.

План обслуживания не нужен. Нужен план запроса

Понял, спасибо.

Вообще количество записей в узле плана запроса не Обязательно должно совпадать с реальным количеством записей это во-первых не нужно, во-вторых невозможно Потому что эти количества рассчитываются оптимизатором приблизительно на основе усреднённой статистики И то что там в узлах цифры показываются не те, что в реальности ни на что на самом деле не влияет, потому что оптимизатору запросов важны относительные количества записей в разных вариантах плана запроса чтобы выбрать тот или иной план по стоимости А вот абсолютное значение этих показателей Ну на самом деле это стоимости плана элементов плана и плана целиком, они не важны. И если у тебя в итоге выбирается правильный Ну то есть адекватный и хороший план запроса, то в общем-то беспокоиться больше не о чем

Может такое произойти из-за неоптимального запроса со стороны 1С?

это из 1с запрос?

да

Это даже постановка вопроса неверна, запрос может быть не оптимальным, но стоимость шагов плана может быть верной

Ну и самое главное не надо перестраивать индексы бездумно только из-за того что стоимости в планах по твоему мнению какие-то там кривые

Несовпадение ожидаемого и полученного количества строк влияет на длительность работы запроса. Типы соединений таблиц оптимизатор выбирает опираясь на ожидания. Если реально читается больше, то и запрос работает медленнее. Если бы оценка была точнее, то оптимизатор мог выбрать другой тип соединения или порядок работы с таблицами.

это была попытка найти решение

Не влияет я выше написал Почему

ну то етсь оптимизатор ожидал 3 строки и выбрал нестед луп а прилетело на несколько порядков больше и типа длительность не поменяется да?

Оценка оптимизатором количество записей то есть по сути Это стоимость шага запроса она не может быть точной в принципе и она не обязана совпадать с реальными значениями количество записей она и даётся пользователь в плане только как какая-то характеристическая оценка стоимости этого плана Она не должна и не может совпадать с реально количеством записей это в принципе невозможно

не поменяется относительно чего?

Это какой-то поток сознания.

вот и я так предположил что от этого может зависеть время выполнения запроса

ну епт не делай вид тчо не понимаешь относительно того если бы прилетело 3 строки как и ожидал

Я просто набираю через Google диктат Он иногда лажает

Ну так если бы прилетело три строки то это гипотетическая ситуация, её никогда не могло быть, и с ней сравнивать бессмысленно

dta_index - это похоже на индекс, предложенный Database Engine Tuning Advisor. Я бы с осторожностью подходил к таким индексам - он может предлагать покрывающие индексы на десятки столбцов, что в большинстве случаев неоптимально.

то есть? лучше не трогать если сомневаешься?

В данном случае, надо посмотреть на его структуру, оценить соотношение read/update, размер по отношению к таблице.

В общем случае - такие индексы слепо не создавать.