Cfqueryparam与通配符LIKE一起使用时比不使用cfqueryparam更慢

Question

我经常遇到一个问题，就是在使用“

”标签时出现了问题。

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

比起其他方式，这种方法慢了大约30毫秒。

column like 'abc%'

在计划被缓存之前，两个查询的运行时间大约相同，约为60毫秒。后续的命中导致没有使用cfqueryparam的查询需要1毫秒，而使用cfqueryparam的查询需要30毫秒。DSN正在发送Unicode，列类型为nvarchar。我只注意到这种行为与“LIKE”运算符有关，而与“=”无关。这个特定的列没有索引。

有人知道为什么会出现这种行为吗？

- J.T.

---

你使用的是哪个版本的MS SQL，以及你的dsn设置是什么？你是否使用ms sql分析器跟踪查询？此外，请参考这个帖子，它涉及到一些varchar和nvarchar之间的区别。链接：https://dev59.com/o2PVa4cB1Zd3GeqP8LWT#10555204 - Leigh

我认为ColdFusion 8没有cf_sql_nvarchar类型。如果我没记错的话，这个类型是在CF10中引入的。 - Leigh

另外，如果提供的 cfsqltype 无效，CF 不会抛出错误。通常情况下会默认使用 cf_sql_char。因此，我会比较这两个查询的跟踪和概要，并查看幕后发生了什么。这里有一个示例，可以从 DSN 跟踪和 SQL 分析器中获取详细信息。只需忽略 CF10 特定的内容即可。 - Leigh

@JT - 抱歉，刚看到你的回复。如果你在用户名前面使用@，那么当你回复时，该用户会收到通知。关于“所有事情都相等”的问题-DSN间谍日志和MS SQL跟踪是否完全相同？ - Leigh

@Leigh，我没有查看dsn spy日志，但我会报告。我需要查看的是这个查询的catch hits和misses。 - J.T.

Answer 1

我曾经在使用非参数化参数查询 SQL Server 时看到过类似的行为。据我所知，查询语句

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

只要表格y的数据没有被修改，计划、统计或输出就永远不会改变。SQL Server可以检测到这一点，并将计划/统计/输出存储更长的时间，与此查询相比：

select x from y where x.a like @p1

任何可能的参数值之间都没有共同点。实际上，您说在计划被缓存后，您会看到性能差异，这是因为不仅缓存了计划。

我还见过一种情况，即查询优化器从未对参数化查询使用有效的索引-而对于非参数化查询则使用-必须使用索引查询提示。

- Jaguar

---

我遇到了一个问题，不太明白在这种情况下是什么触发了缓存命中或未命中。我一直在解决Leigh在其他领域提出的一些问题，所以还没有回到这个查询。我目前最大的困难是观察如何管理复杂查询的计划缓存。 - J.T.