在使用SQL Server2005/2008的最新jdbc驱动程序时，准备好的语句、视图和存储过程在性能方面有何比较？
在使用SQL Server 2005/2008的最新Microsoft jdbc驱动程序时，准备好的语句、视图和存储过程在性能方面有何比较？
如果我有一个带有一些动态where子句的普通老式select语句，我会看到从准备语句中的直接SQL转移到视图甚至存储过程中的好处吗？
更具体地说，像这样的内容如何：
select foo.name, bar.name, baz.name, belch.burp
from foo
inner join bar on foo.id=bar.fooID
inner join baz on bar.id=baz.barID
inner join belch on baz.id = belch.bazID
where foo.name like '%<USERINPUT>%' and bar.name like '%<USERINPUT>%'回答 3
Stack Overflow用户
发布于 2008-12-30 18:40:30
由于up的缓存执行计划，您不太可能看到显著的性能差异，因为执行计划也缓存在SQL Server 2005甚至更高版本的即席SQL中。
在参数嗅探可能会由于某些参数值的基数估计错误而对性能产生负面影响的情况下，可以使用WITH RECOMPILE指示器。
视图和存储过程的好处将体现在安全性和维护方面，其中的好处可能太多，无法在此详细介绍，但包括以下功能：
限制从SELECT语句读取受保护的数据，而不必在基础表上分配单独的列权限。
从其他SQL代码和应用程序中的多个位置重用参数化SP。
将应用程序SP作为系统的命名数据库接口组件进行检测、日志记录、性能分析和调整，而不会影响或重新部署应用程序代码。
重构数据库，而不影响或重新部署应用程序代码。
提供与数据库的抽象层和接口契约，该抽象层和接口契约提供对系统所需和提供的数据库服务的良好可见性，这可能包括自动生成关于接口的元数据的可能性，可以具有自动测试的单独层，并且还可以用作后端可移植性的分界点。
Stack Overflow用户
发布于 2008-12-30 20:01:43
您永远不会从这样的语句中获得良好的性能，无论您以何种方式将其表示为like语句，并使用通配符作为第一个字符，这意味着索引不会用于该字段。坦率地说，我们一直坚持我们的用户必须至少输入第一个字符才能进行搜索。如果您的数据不知道第一个字符，那么您可能有一个糟糕的设计和规范化问题(在一个字段中存储多位信息)。除了重新设计数据库之外，还没有很好的解决方法。
Stack Overflow用户
发布于 2008-12-30 17:17:15
取决于sql和您的应用程序。我不相信有一个包罗万象的答案，这可能不取决于司机。
如果您可以选择编写一个将大量数据带回中间层的查询来执行数据库可以轻松执行的操作，我建议让数据库进行计算并简单地返回结果。
https://stackoverflow.com/questions/400881
复制相似问题
腾讯云开发者
