使用未确定数量的参数时,如何避免动态SQL？

我有一个类似StackOverflow的标记系统,用于我正在处理的数据库.我正在编写一个存储过程,根据WHERE子句中未确定数量的标记查找结果.可以有0到10个标签之间的任何位置来过滤结果.例如,用户可能正在搜索标记为“apple”,“orange”和“banana”的项目,并且每个结果必须包含所有3个标记.我的查询变得更加复杂,因为我还在处理标记的交叉引用表,但出于这个问题的目的,我不会进入那个.

我知道我可以做一些字符串操作并向exec()函数提供一个查询来处理这个问题,但我宁愿不解决与动态SQL相关的性能问题.我认为最好是SQL缓存存储过程的查询计划.

在这种情况下,您使用了哪些技术来避免动态SQL？

根据大众需求,这是我正在使用的查询：

SELECT ft.[RANK],s.shader_id,s.page_name,s.name,s.description,s.download_count,s.rating,s.price FROM shader s 
INNER JOIN FREETEXTTABLE(shader,*,@search_term) AS ft ON s.shader_id = ft.[KEY]
WHERE EXISTS(SELECT tsx.shader_id FROM tag_shader_xref tsx INNER JOIN tag t ON tsx.tag_id = t.tag_id WHERE tsx.shader_id = s.shader_id AND t.tag_name = 'color')
AND EXISTS(SELECT tsx.shader_id FROM tag_shader_xref tsx INNER JOIN tag t ON tsx.tag_id = t.tag_id WHERE tsx.shader_id = s.shader_id AND t.tag_name = 'saturation')
ORDER BY ft.[RANK] DESC

这是功能性但硬编码.你会看到我设置它来寻找’颜色’和’饱和度’标签.

解决方法

具体到你的问题是这里的部??分：http://www.sommarskog.se/dyn-search-2005.html#AND_ISNOTNULL

还要考虑到(直接)动态解决方案不一定比(可能是复杂的)静态解决方案慢,因为查询计划仍然可以缓存：请参阅http://www.sommarskog.se/dyn-search-2005.html#dynsql

因此,您必须根据实际数据量仔细测试/衡量您的选项,同时考虑实际查询(例如,使用一个或两个参数进行搜索可能比使用十个搜索更常见,等等)

编辑：提问者给出了一个很好的理由在评论中对此进行优化,从而将“过早”警告移开：

然而,(标准;)警告词适用：这很像过早优化！ – 你确定这个sproc会被调用,通常情况下使用动态SQL会明显变慢(也就是说,与应用程序中正在进行的其他事情相比)？

（编辑：南京站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!