SQL Server не использует XML-индексы для запроса набора строк XML

Надеюсь, кто-то может помочь в этом.

Нам нужно вернуть поле данных из столбца XML набора строк в SQL. Подпрограмма работает, но не использует ни один из созданных индексов XML (первичные + вторичные по значению / пути / свойства, но без выборочных индексов XML). Из-за количества XML постоянное измельчение с помощью Query Engine значительно замедляет запросы. Кто-нибудь знает, как заставить SQL Server (2012) фактически использовать индексы XML в столбце XML?

Не существует различий в скорости, чтение данных или планирование различий с индексами XML выключены или включены, поэтому они определенно не используются.

Пример запроса (@Field - это требуемое имя поля, @XmlData XML).

@XmlData.value(
      'declare namespace rs="urn:schemas-microsoft-com:rowset";
      declare namespace z="#RowsetSchema";
      (/xml/rs:data/rs:insert/z:row[@fm_field=sql:variable("@Field")]/@fm_data)[1]','nvarchar(255)')

Пример XML-фрагмента ...

<xml xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema">
  <s:Schema id="RowsetSchema">
    <s:ElementType name="row" content="eltOnly" rs:updatable="true">
      <s:AttributeType name="fm_field" rs:number="1" rs:write="true">
        <s:datatype dt:type="string" dt:maxLength="255" rs:precision="0" rs:fixedlength="true" rs:maybenull="false" />
      </s:AttributeType>
      <s:AttributeType name="fm_data" rs:number="2" rs:write="true">
        <s:datatype dt:type="string" dt:maxLength="255" rs:precision="0" rs:fixedlength="true" rs:maybenull="false" />
      </s:AttributeType>
      <s:extends type="rs:rowbase" />
    </s:ElementType>
  </s:Schema>
  <rs:data>
    <rs:insert>
      <z:row fm_field="ABSOLVELIA" fm_data="No" />
      <z:row fm_field="ADJNO" fm_data="" />
      <z:row fm_field="AIRPORTS" fm_data="No" />

sql-server,xml,performance,indexing,

1

Ответов: 2


1 принят

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

Существует потенциально большое (ist) количество XML-данных (около 15 тыс. В среднем на каждую запись с наборами записей в миллионах), что потенциально может иметь несколько бит размера TB каждый (большинство из них меньше всего на несколько сотен ГБ, поэтому они более управляемы).

Он принимает все одноядерные процессоры (XML обрабатывается одним ядром в SQL-процессоре из-за процессов нижнего уровня, используемых SQL для его синтаксического анализа), поэтому любой синтаксический анализ XML-информации берет навсегда без возможности бросить на нее больше ядер ( мы используем современную ферму серверов 3GHz + VM для этого бита).

Чтобы ускорить отчет, я добавил индексированное представление для клиента по более чем 400 атрибутам поля XML, которые они хотят сообщить для интеллектуального анализа данных, этот индекс построен из резервной копии (они не хотят, чтобы база данных в реальном времени изменялась или что-либо, что замедляет вставку или иметь что-либо, воспроизводящее его, или, действительно, HA и т. д. в прямом эфире, поэтому представление Indexed создается из резервной копии).

Формат XML не изменяется, поэтому данные, хранящиеся в атрибутах (поле / данные формата набора строк), останавливают использование SQL из любого типа индекса XML (я знаю, что индексы XML являются cr @ p из прошлого опыта, поэтому я сжимал соломинку).

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

Я могу закодировать многопоточный предварительный измельчитель на C #, чтобы получить скорость и основное использование, но надеялся, что SQL имеет работоспособный ответ, который я пропустил.

Спасибо, что нашли время, чтобы посмотреть как-нибудь люди.


0

Вы можете прочитать это . Индекс XML поможет в очень немногих ситуациях ... Некоторые сценарии даже ухудшатся ...

Один сценарий, где XML-индекс помог бы: Представьте себе данные, связанные с столбцом XML. Есть много строк. Каждая строка содержит огромный XML. Где-то в этом XML есть информация, что продукт имеет категорию «abc». Теперь вы хотите отфильтровать все строки таблицы, где вы найдете продукт с данной категорией.

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

Если я хорошо понимаю ваш пример, запроса нет, где индекс XML может считаться полезным.

Вы не предоставляете достаточно информации ...

  • В вашем примере отображается XML-переменная: откуда этот XML?
  • Есть ли только один XML или вы читаете много XML-файлов из файла, или это / эти XML-файлы, живущие в таблице?
  • Много ли <rs:insert>узлов или только один?
  • Где производительность бутылочной шее? Чтение одного крошечного XML не может быть медленным ...

Мой волшебный хрустальный шар говорит мне, что ваша проблема находится где-то в другом месте. Читайте о проблеме XY .

Если вам нужна помощь, вы должны предоставить тестовый сценарий. Пожалуйста, прочитайте Как задать хороший вопрос SQL и как создать MCVE

SQL-сервер, XML, производительность, индексация,
Похожие вопросы
Яндекс.Метрика