В чем смысл "Пропавшего фактора воздействия%" в плане выполнения SQL Server 2008?

Ответ 1

Это запрос 27 в пакете.

Вероятно, влияние, которое оно показывает на самом деле, относится к совершенно другому утверждению (1-26).

Кажется, что проблема связана с тем, как удары отображаются для планов оцененных в SSMS.

Две приведенные ниже партии содержат те же два утверждения, что и порядок обратный. Обратите внимание, что в первом случае он утверждает, что оба утверждения будут одинаково влиять на воздействие 99.38 и во втором 49.9818.

Таким образом, он показывает оценочное воздействие на экземпляр first, который встречается с этим отсутствующим индексом - не тот, который действительно связан с оператором.

Я не вижу этой проблемы в фактических планах выполнения, и правильное воздействие действительно показано в плане XML рядом с каждым утверждением даже в оценочном плане.

Я добавил сообщение Connect item об этой проблеме здесь. (Хотя, возможно, вы столкнулись с другой проблемой, поскольку 10% -ное воздействие, по-видимому, является точкой отсечения для отсутствующих параметров индекса, которые включены в план, и трудно понять, как это будет возможно по тем же причинам, что и в вопросе)

Примеры данных

CREATE TABLE T1
  (
     X INT,
     Y CHAR(8000)
  )

INSERT INTO T1
            (X)
SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY @@spid)
FROM   sys.all_objects o1,
       sys.all_objects o2 

Пакет 1

SELECT *
FROM T1
WHERE X = -1

SELECT *
FROM T1
WHERE X = -1
UNION ALL
SELECT *
FROM T1

Пакет 2

SELECT *
FROM T1
WHERE X = -1
UNION ALL
SELECT *
FROM T1

SELECT *
FROM T1
WHERE X = -1

XML для первого плана (сильно усеченный) ниже, показывая, что правильная информация находится в самом плане.

<?xml version="1.0" encoding="utf-16"?>
<ShowPlanXML>
  <BatchSequence>
    <Batch>
      <Statements>
        <StmtSimple StatementCompId="1">
          <QueryPlan>
            <MissingIndexes>
              <MissingIndexGroup Impact="99.938">
                <MissingIndex Database="[tempdb]" Schema="[dbo]" Table="[T1]">
                  <ColumnGroup Usage="EQUALITY">
                    <Column Name="[X]" ColumnId="1" />
                  </ColumnGroup>
                </MissingIndex>
              </MissingIndexGroup>
            </MissingIndexes>
          </QueryPlan>
        </StmtSimple>
      </Statements>
      <Statements>
        <StmtSimple StatementCompId="2">
          <QueryPlan>
           <MissingIndexes>
              <MissingIndexGroup Impact="49.9818">
                <MissingIndex Database="[tempdb]" Schema="[dbo]" Table="[T1]">
                  <ColumnGroup Usage="EQUALITY">
                    <Column Name="[X]" ColumnId="1" />
                  </ColumnGroup>
                </MissingIndex>
              </MissingIndexGroup>
            </MissingIndexes>
          </QueryPlan>
        </StmtSimple>
      </Statements>
    </Batch>
  </BatchSequence>
</ShowPlanXML>

Ответ 2

Предполагая, что интерпретация недостающего воздействия% идентична или аналогична интерпретации столбца avg_user_impact из системного представления sys.dm_db_missing_index_group_stats, тогда отсутствующий эффект% представляет (более или менее):

Среднее процентное преимущество, которое могут возникнуть в пользовательских запросах, если это отсутствовала группа индексов. Значение означает, что запрос стоимость будет снижаться в среднем на этот процент, если этот недостающий индекс группа была реализована.

Ответ 3

Спасибо за информацию всем. Мартин Смит, я считаю, нашел ошибку в результате этого, хотя я не уверен, что это такая же ошибка, как и то, что я вижу. На самом деле я не уверен, что моя проблема является ошибкой или по дизайну. Позвольте мне остановиться на некоторых новых наблюдениях:

Просматривая этот довольно большой план выполнения (62 запроса), я заметил, что рекомендация "Отсутствующий индекс" (и соответствующий Impact%), которую я упомянул в исходном вопросе, перечислены почти по каждому запросу в пакете 62 запросов. Как ни странно, многие из этих запросов даже не называют таблицу, для которой рекомендуется использовать индекс! Наблюдая это, я открыл XML и обыскал элемент "MissingIndexes", который показал, что, очевидно, 10 разных индексов, пропущенных без изменения Impact%. Почему план выполнения не показывает это визуально и вместо этого показывает только одну Missing Indezx, я не знаю. Я предполагаю, что это либо 1) ошибка, либо 2) она показывает только отсутствующий индекс с ВЫСОКИМ воздействием% - который я вижу пронизанным по всему плану.

Предложение, если вы испытываете это тоже: Удовлетворитесь XML с помощью визуального плана выполнения. Найдите элемент xml "MissingIndexes" и сопоставьте это с инструкциями, чтобы получить правильные результаты.

Я также читал из Microsoft http://technet.microsoft.com/en-us/library/ms345524(v=sql.105).aspx что отсутствующая статистика индекса поступает из группы DMV. Если Impact% на самом деле из этих DMV, то я также предполагаю, что Impact% основано на MUCH MUCH больше, чем просто Query/Statement в плане выполнения, рекомендованный индексом. Так что возьмите его с солью и используйте их мудро, основываясь на собственных знаниях вашей базы данных.

Я собираюсь оставить это открыто и не отмечать ничего как "ответ". Не стесняйтесь звонить людям!

Еще раз спасибо.

Ответ 4

Хорошо, позвольте мне посмотреть, могу ли я здесь прояснить ситуацию.

Все остальные операции по-прежнему будут стоить 0%, потому что DELETE в цикле занимает большую часть вашего процессора и время ввода-вывода. Однако это не означает, что другие операции не имеют затрат на процессор/память/IO, которые можно улучшить по этому запросу, добавив этот индекс. Особенно, если вы делаете цикл, по существу, своим сопоставлением в tableB для одной записи, а затем удаляете из таблицыA снова и снова. Поэтому наличие индекса, упрощающего сопоставление этих строк, ускорит удаление.