Подготовленный отчет очень медленный по сравнению с прямым заявлением

Я выполняю нагрузочное тестирование в базе данных SQL Server. В таблице, которую я тестирую, содержится около 800 миллионов записей. Я использую Jmeter JDBC запрос для тестирования.Подготовленный отчет очень медленный по сравнению с прямым заявлением

Я бегу запрос похож на ниже:

select column1, column2, column3, column4 from table_name where table_key='32CharString'

Здесь table_key первичный ключ на столе, и она имеет длину varchar(32).

В Jmeter JDBC-запросе, если я жестко задал таблицу_имя, запрос выполняется в ~ 170 миллисекунд.

select column1, column2, column3, column4 from table_name 
where table_key='1234567890abcdef1234567890abcdef';

Вместо если я передать его в качестве параметра в том же запросе, используя подготовленное заявление, запрос выполняется успешно примерно 900+ секунд.

select column1, column2, column3, column4 from table_name where table_key=?

Parameter = 1234567890abcdef1234567890abcdef Type = VARCHAR

Я не могу понять, как там это много разница во времени выполнения запроса. Укажите некоторые указатели

источник

2016-02-01 ramcvasudevan

В основном, вам нужно сравнить планы выполнения. Без этой информации я могу только рекомендовать вам прочитать это http://blogs.msdn.com/b/sqlprogrammability/archive/2008/11/26/optimize-for-unknown-a-little-known-sql-server- 2008-feature.aspx – krtek

По крайней мере, включите в свой вопрос [MVCE] (https://stackoverflow.com/help/mcve) (минимальный, полный и проверяемый пример). Вы отправили запрос и параметр, но это не полный фрагмент кода. Чтобы правильно ответить на этот вопрос, укажите весь соответствующий контекст, в этом случае фрагмент кода с «PreparedStatement». Вы можете указать это, нажав 'edit' под своим вопросом, затем вставьте код в свой вопрос. Затем выберите этот код и нажмите кнопку '{}', чтобы правильно отформатировать код. –

Существуют случаи, когда разные значения параметров могут приводить к другому плану оптимизации. Затем этот план оптимизации кэшируется и используется при следующем запуске запроса с разными значениями параметров. Но план оптимизации - не лучший план для измененного запроса. Поэтому вам нужно сравнить планы выполнения и оптимизировать выполнение. Для начала включите опцию OPTION (RECOMPILE) ', больше о sniffing параметров https://blogs.technet.microsoft.com/mdegre/2011/11/06/what-is-parameter-sniffing/ – krtek

«Параметр = 1234567890abcdef1234567890abcdef Тип = varchar« кажется мне подозрительным. В частности, «varchar(<missing length here>)». Моя теория заключается в том, что она параметризуется как более широкий тип varchar (скажем varchar(300)), и SQL Server делает следующее «select <col list> from table_name where cast(table_key as varchar(300)) = ?». Что для SQL Server означает, что он должен касаться каждой строки в вашей таблице.

Чтобы подтвердить свою теорию, вы можете посмотреть планы выполнения для вашего ad hoc и ваших подготовленных заявлений. Если я прав, вы должны увидеть поиск в своем специальном плане и сканирование в подготовленном заявлении. Более того, я думаю, вы также увидите вычислительную скалярную операцию в вашем подготовленном заявлении для преобразования upconverver в любой тип данных, который выбирает подготовка к заявлению.

источник

2016-02-01 15:42:29

Подготовленный отчет очень медленный по сравнению с прямым заявлением

ответ

Смежные вопросы