условие для создания готового оператора с помощью cfqueryparam? - PullRequest
Новая
       0

условие для создания готового оператора с помощью cfqueryparam?

2 голосов
/ 04 августа 2011

Становится ли cfquery подготовленным утверждением, если есть 1 cfqueryparam? Или есть другие условия?

Что происходит, когда предложение ORDER BY или FROM является динамическим? Будет ли каждая уникальная комбинация готовым утверждением?

А что происходит, когда мы делаем cfloop с INSERT, с каждым значением cfqueryparam'ed и вызываем cfquery с различным числом итераций?

Есть ли потенциальные проблемы со слишком большим количеством подготовленных утверждений?

Как БД обрабатывает подготовленное утверждение? Будут ли они преобразованы во что-то похожее на процедуру хранения?

При каких обстоятельствах мы не должны использовать подготовленное заявление?

Спасибо!

Ответы [ 2 ]

5 голосов
/ 04 августа 2011

Я могу ответить на некоторые части вашего вопроса:

запрос станет подготовленным состоянием, пока существует один <queryparam. Я в прошлом добавил where 1 = <cfqueryparam value="1" к запросам, у которых не было динамических параметров, чтобы они запускались как readyStatements

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

Предполагая, что вы используете драйверы, поставляемые с ColdFusion, если вы включите флажок «Активность журнала» в расширенной панели настройки DataSource, то вы получите очень подробную информацию о том, как CF взаимодействует с БД и когда он создает новое подготовленное состояние и повторно использует их. Я бы порекомендовал попробовать это для себя, так как здесь задействовано очень много факторов (настройка БД, драйвер, версия CF и т. Д.). Если вы используете ведение журнала БД, перезапустите CF перед запуском тестового кода, чтобы вы могли увидеть, как он создает подготовленные операторы, в противном случае вы просто увидите, что он повторно использует операторы по ID, не видя, что это за операторы. 1009 *

2 голосов
/ 04 августа 2011

Кроме того, если вы спрашиваете о планах выполнения, то в этом участвует больше, чем просто число, сгенерированное PreparedStatement.Это огромная тема и зависит от базы данных.У меня нет хватки администратора, но я могу ответить на несколько вопросов о MS SQL.

Что происходит, когда предложение ORDER BY или предложение FROM является динамическим?Будет ли каждая уникальная комбинация готовым утверждением?

База sql отличается.Таким образом, вы получите отдельные планы выполнения для каждого уникального ORDER BY предложения.

И что произойдет, когда мы делаем cfloop с INSERT, с каждым значением cfqueryparam'ed и вызываем cfquery с различным числом итераций?

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

Представление sys.dm_exec_cached_plans очень полезно для просмотра того, какие планы кэшируются и как часто они используются. 

SELECT  p.usecounts, p.cacheobjtype, p.objtype, t.text 
FROM    sys.dm_exec_cached_plans p
        CROSS APPLY sys.dm_exec_sql_text( p.plan_handle) t
ORDER BY p.usecounts DESC

Чтобы сначала очистить кэш, используйте DBCC FLUSHPROCINDB.Очевидно, не использует его на рабочем сервере. 

DECLARE @ID int
SET @ID = DB_ID(N'YourTestDatabaseName')
DBCC FLUSHPROCINDB( @ID )
...