Я изучаю проблему со следующей информацией:
У нас была таблица журналирования с примерно 90 тыс. Записей, в которых вставка занимала несколько секунд (примерно от 10 до 20 секунд) в крайних случаях. В одном из столбцов таблицы хранится XML как тип данных XML. XML не анализируется во время вставки, а просто сохраняется.
Мы попытались усечь таблицу, предполагая, что проблема связана с количеством записей (хотя 90 КБ казались «нормальными»), а вставки по-прежнему работают плохо.
Хотя я знаю, что есть и другие проблемы, которые могут затруднить возникновение проблемы, какие идеи «сначала проверьте», которые могут помочь мне отладить эту проблему? Заранее благодарим за любые предложения и помощь.
Это наверное то же самое, что и https://stackoverflow.com/questions/2782378/which-inserts-faster-xml-field-or-varcharmax-field/2783521#2783521
Повторю свой совет от SO:
Применяйте хорошо проверенную и проверенную методологию исследования производительности, например Ожидания и очереди. Гадание ни к чему не приведет.
Ах, XML анализируется, извините.
Тип данных XML НЕ хранит данные как текст, он разбивает их на стиль внутренней структуры ключ / значение, и для этого он должен их анализировать;) Это сделано для облегчения поиска, кстати. ;)
Итак, извините, сервер анализирует XML.
Что вы считаете узким местом? ЦПУ? IO? Замки?
У вставок не должно быть отношения производительности к длине таблицы, которое можно измерить, если только вы не сделаете что-то совершенно глупое, например, уникальное ограничение БЕЗ индекса (и, следовательно, сканирование таблицы при каждой вставке). Прежде чем давать совет, вам нужно начать изучать настоящие причины, по которым это занимает так много времени, и что происходит на сервере.
Посмотрите, как вы выбрали для хранения данных. Вот руководство по хранению xml на 2005 год. Различные уровни достоверности документов могут повлиять на производительность. Также взгляните на основы для мониторинга производительности