为什么 NHibernate 生成的参数化 SQL 与存储过程一样快？
https://stackoverflow.com/questions/50346
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我的一位同事声称，即使执行路径被缓存，从 ORM 生成的参数化 SQL 也无法像存储过程一样快。对这个顽固的开发者有什么帮助吗？
其他提示
第 1 轮 - 您可以启动探查器跟踪并比较执行时间。
对于大多数人来说，说服他们的最好方法是“向他们展示证明”。在这种情况下，我将创建几个基本测试用例以检索相同的数据集，然后使用存储过程与NHIBERNATE进行多长时间。一旦你得到结果，就把它交给他们，大多数持怀疑态度的人应该屈服于证据。
我只想在 Rob 的回答中添加一些内容：
首先，确保测试用例中涉及的数据量与生产值相似。换句话说，如果您的查询通常针对具有数十万或行的表，则创建这样的测试环境。
其次，除了使用 nHibernate 生成的查询和 s'proc 调用之外，其他一切都相同。希望您可以通过简单地更换提供者来执行测试。
最后，要认识到，通常存在的风险不仅仅是存储过程与存储过程。ORM。考虑到这一点，测试应该考虑所有因素：执行时间、内存消耗、可扩展性、调试能力等。
这里的问题是你已经接受了举证责任。你不太可能像那样改变别人的想法。不管你喜欢与否，人们——甚至程序员——都太情绪化，不容易被逻辑所左右。你需要把举证责任放回他身上——让他说服你否则——这将迫使他自己进行研究并找到答案。
使用存储过程的一个更好的论据是安全性。如果你使用 仅有的 存储过程，与 不 动态 sql，您可以禁用应用程序数据库用户的 SELECT、INSERT、UPDATE、DELETE、ALTER 和 CREATE 权限。这将保护您免受大多数二阶 SQL 注入的影响，而参数化查询仅对一阶注入有效。
测量它，但在非微基准中，即代表系统中实际操作的东西。即使存储过程会带来微小的性能优势，但与代码所产生的其他成本相比，这也是微不足道的：实际上检索数据、转换数据、显示数据等。更不用说使用存储过程相当于将您的逻辑分散到您的应用程序中 和 您的数据库没有重要的版本控制、单元测试或重构支持。
自己进行基准测试。编写一个测试床类，该类执行采样的存储过程数百次，并运行 NHibernate 代码相同的次数。比较每种方法的平均和中值执行时间。
如果每次查询都相同，速度也一样快。Sql Server 2005 在批处理中的每个语句级别缓存查询计划，而不管 SQL 来自何处。
长期的差异可能是，对于 DBA 来说，存储过程的管理和调优要容易很多很多倍，而必须从探查器跟踪中收集的数百个不同的查询则是一场噩梦。
这种争论我已经争论过很多次了。
几乎总是我最终会找一个非常好的 dba，并在运行探查器的情况下运行一个 proc 和一段代码，然后让 dba 表明结果非常接近，可以忽略不计。
测量一下。
确实，在您对这个主题进行测量之前，任何讨论都可能是徒劳的。
对于他正在考虑的特定用例，他可能是正确的。对于一些可以任意调整的复杂 SQL 集，存储过程可能会执行得更快。然而，您从休眠之类的东西中获得的东西是缓存。对于您的实际应用程序的生命周期来说，这可能会更快。
附加的抽象层将导致它比对存储过程的纯调用慢。事实上，您在托管堆上有额外的分配，以及从调用堆栈中进行额外的压入和弹出，事实是，调用存储过程比使用 ORM 构建查询更有效，无论效果有多好。 ORM 是。
到底有多慢，即使可以测量，也是有争议的。大多数 ORM 都有缓存机制来避免执行查询，这也有助于这一点。
即使存储过程快了 10%（很可能没有），您也可能想问自己这到底有多重要。最终真正重要的是为系统编写和维护代码的容易程度。如果您正在编写 Web 应用程序，并且所有页面都在 0.25 秒内返回，那么使用存储过程节省的额外时间可以忽略不计。然而，使用像 NHibernate 这样的 ORM 可以带来许多额外的优势，仅使用存储过程很难复制这些优势。
