有没有人有任何经验表明通过选择使用 ORM（在 Django、RoR、SQLAlechemy 等中）而不是 SQL 和手工设计的数据库，开发人员可以获得什么样的性能？我想有一些复杂的问题，包括在 ORM 的约束下指定数据库是否会增加或减少创建有效数据库结构的机会（基于开发人员的经验水平），以及开发人员构建的问题基于 SQL 或 ORM 的查询（同样基于他/她的经验）。关于这些或内在性能问题的任何信息对我来说都是非常有趣的。
【问题讨论】：
标签： sql database performance orm frameworks
性能 - 它总是有利有弊。如果您深入了解 ORM 架构（请参阅我的文章：avoid ORM bad habits），那么您会直观地找到使其更快的方法。这是我的另一篇关于如何使 EF6x 更快（至少在阅读情况下）的文章：EF6.x 5x faster
无论如何，为了获得良好的性能，即使使用 ORM，您也需要创建数据库视图、索引，以检查 ORM 生成和执行的查询并对其进行微调。急切加载是 ORM 的必备条件。
【讨论】：
在大多数 DAL 层开发/架构中，性能一直是事后考虑的因素。我认为是时候开始质疑这些 ORM 工具的性能了，因为它们承诺的所谓的易于开发：
ORM 中最大的两个性能问题是：
无法编写最佳 SQL。您必须使用由框架解释为 SQL 的对象查询语言。大多数情况下它是好的 SQL，但通常它不是最有效的 SQL。
反射。大多数 ORM 框架使用反射来使用数据库中的数据填充对象。反射操作成本高，而且随着负载和数据量的增加，性能下降变得明显。
出现的其他性能问题是由于实体对象与表的紧密耦合导致的数据库设计或实体模型设计效率低下。
【讨论】：
这还取决于您使用什么作为 ORM。以我的经验，Hibernate 在速度、资源使用和启动时间方面都是一头猪。另一方面，LINQ to SQL 是一个非常轻量级的 SQL 包装器，您可能几乎不会（如果有的话）注意到它的影响。
【讨论】：
我的建议是在您需要之前不要担心这一点 - 不要过早优化。 ORM 可以为开发速度、代码可读性提供许多好处，并且可以消除大量代码重复。如果它可以使您的应用程序更容易开发，我会推荐使用它。
随着开发的进行，使用基准和分析来确定代码中的瓶颈，如果需要，您可以绕过 ORM 并在需要时使用手动查询。通常，您将能够使用缓存和数据库索引（除其他外）来提高 ORM 的速度，然后您可以决定在哪里需要手动查询。在大多数情况下，ORM 的性能可能是可以接受的，使用它的好处将远远超过性能成本。
【讨论】：