Cfqueryparam с LIKE с подстановочным знаком медленнее, чем без использования cfqueryparam

[Изменить: отредактировано на основе предложений Ли

У меня постоянно возникает проблема с тем, где использовать

 column like <cfqueryparam cfsqltype="cf_sql_varchar" value="abc%" />

медленнее, чем примерно на 30 мс.

column like 'abc%'

До кэширования плана оба запроса выполняются примерно в одно и то же время ~60 мс. Последующие попадания приводят к 1 мс для запроса без cfqueryparam и 30 мс для запроса с использованием cfqueryparam. DSN отправляет unicode, а тип столбца — nvarchar. Я не замечаю такого поведения с "=", только с оператором LIKE. Этот конкретный столбец не индексируется.

Кто-нибудь знает, почему такое поведение происходит?


sql-server coldfusion coldfusion-8
person J.T.    schedule 10.08.2012    source источник
comment
Какая версия MS SQL и какие у вас настройки dsn? Вы отследили запросы с помощью профилировщика MS SQL? См. также эту ветку, в которой рассматриваются некоторые различия между varchar и nvarchar.   -  person Leigh    schedule 10.08.2012
comment
@ Leigh MSSQL2012, это все nvarchar, так что этот параметр не применяется. Даже если бы мы не использовали юникод, мы отправляем nvarchar в качестве параметра, а тип столбца — nvarchar. След выглядит вполне нормально.   -  person J.T.    schedule 10.08.2012
comment
Я не думаю, что ColdFusion 8 имеет тип cf_sql_nvarchar. IIRC, который не был представлен до CF10.   -  person Leigh    schedule 10.08.2012
comment
Кроме того, CF не выдает ошибку, если предоставленный cfsqltype недействителен. Я обычно просто по умолчанию cf_sql_char. Поэтому я бы сравнил трассировку и профиль двух запросов и посмотрел, что происходит за кулисами. Вот пример сведений, которые можно получить из трассировки dsn и профилировщика sql. Просто игнорируйте специфические вещи CF10.   -  person Leigh    schedule 10.08.2012
comment
Ничего себе, Ли, это огромная находка! Это потребует пересмотра всех наших индексов. Я могу только представить, что вы застряли с unicode dsn и не unicode dsn, когда вам нужна возможность работать как с nvar, так и с var для производительности. Вы знаете, это та же самая проблема, с которой я столкнулся в прошлом году в другом приложении, работающем под управлением sybase. Параметр cfqueryparam был несовместим с отметкой времени/датой и временем sybase. Это вызывало сканирование вместо поиска только в приложении cf.   -  person J.T.    schedule 12.08.2012
comment
Ли, я отредактировал свой исходный вопрос. При прочих равных условиях LIKE все еще медленнее.   -  person J.T.    schedule 13.08.2012
comment
@JT - Извините, только что увидел ваш ответ. К вашему сведению, если вы используете @ перед именем пользователя, этот человек получит уведомление, когда вы ответите. Re: При прочих равных условиях. Журнал dsn spy и ms sql trace точно совпадают?   -  person Leigh    schedule 19.08.2012
comment
@ Ли, я не смотрел журнал шпионажа dsn, но сообщу об этом. Что мне нужно посмотреть, так это поймать хиты и промахи с этим запросом.   -  person J.T.    schedule 28.08.2012
comment
@Дж.Т. - Хорошо. Причина изучения журналов и трассировки состояла в том, чтобы исключить различия в подготовке на стороне CF. Это было причиной в некоторых темах выше. Но если все действительно точно то же самое, то причина, вероятно, кроется в ms sql, как предположил Jaguar.   -  person Leigh    schedule 29.08.2012

Ответы (1)


arrow_upward
1
arrow_downward

Я видел подобное поведение с сервером sql при запросе с непараметризованными параметрами. Насколько я знаю запрос

select x from y where x.a like 'dog'

никогда не изменит план, статистику или выходные данные, если данные таблицы y не будут изменены. SQL Server может и обнаруживает это и сохраняет план/статистику/выходные данные в течение более длительного периода времени по сравнению с этим запросом:

select x from y where x.a like @p1

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

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

person Jaguar    schedule 22.08.2012
comment
У меня проблема с пониманием того, что именно вызывает попадание или промах кеша в этом случае. Я был занят настройкой некоторых других проблем, на которые Ли обратил мое внимание в других областях, поэтому я не возвращался к этому вопросу. Моя самая большая проблема сейчас — это наблюдение за тем, как кэш планов управляется для сложных запросов. - person J.T.; 28.08.2012