Проблема с типом данных varbinary(max) на сервере Sql

Я создал таблицу с двумя столбцами с типом данных varbinary(max). Я сохраняю файлы PDF в двоичном формате в этих столбцах. Нет проблем при вставке файлов PDF в эти столбцы. Но когда я выбираю даже одну запись только с одним столбцом типа varbinary в запросе select, получение записи занимает около одной минуты. Размер вставленного pdf-файла составляет 1 МБ. Вот SQL-запрос для получения одной записи:

select binarypdffile from gm_packet where jobpacketid=1

Пожалуйста, предложите, есть ли способ улучшить производительность с типом данных varbinary.


person Rajbir Singh    schedule 13.04.2015    source источник
comment
какую версию вы используете 2008, 2008 R2 или 2014?   -  person ughai    schedule 14.04.2015
comment
можете ли вы добавить схему и индексы для таблицы gm_packet   -  person ughai    schedule 14.04.2015
comment
Что это за сетевое соединение? Это единственная реальная причина для этого, которую я могу себе представить.   -  person usr    schedule 14.04.2015
comment
@ughai, спасибо за ответ. Я использую как 2008 R2, так и 2014. Если я добавлю индекс в gm_packet, то вставка будет очень медленной, так как индекс всегда перестраивается во время вставки.   -  person Rajbir Singh    schedule 15.04.2015
comment
@usr Я просто выполняю SQL-запрос в SSMS, и получение этой записи занимает слишком много времени.   -  person Rajbir Singh    schedule 15.04.2015
comment
@RajbirSingh - можете ли вы добавить структуру таблицы и существующие индексы в свой вопрос, это поможет вам получить более качественные ответы. Также добавьте статистику по столбцу jobpacketid   -  person ughai    schedule 15.04.2015
comment
И что это за сетевое подключение? Насколько это быстро? Это высокая задержка? Ваш комментарий не касается моего вопроса.   -  person usr    schedule 15.04.2015


Ответы (1)


Не могли бы вы попробовать и рассчитать время следующих запросов:

SELECT cnt = COUNT(*) INTO #test1 FROM gm_packet WHERE jobpacketid = 1

SELECT binarypdffile INTO #test2 FROM gm_packet WHERE jobpacketid = 1

Первый проверяет, сколько времени потребуется, чтобы найти запись. Если это медленно, добавьте индекс в поле jobpacketid. Предполагая, что эти значения поступают последовательно, я бы не беспокоился о производительности, поскольку записи будут добавляться в будущем. В противном случае вам может потребоваться время от времени перестраивать индекс.

Второй проверяет, сколько времени требуется для извлечения данных из таблицы (и сохранения их обратно в другую таблицу). Поскольку никакие данные не выходят из «системы», она должна показывать «необработанную производительность базы данных» без какого-либо «внешнего» влияния.

Ни то, ни другое не должно быть очень длинным. Если это не так, но выполнение исходного запроса в SSMS и получение двоичных данных в сетке по-прежнему занимает «долгое время», то я предполагаю, что это либо проблема с сетью (wifi?), либо SSMS просто очень плохая при представлении блоба в графическом интерфейсе; это уже было замечено =)

person deroby    schedule 09.11.2015