我们经常提到数据库优化，经常为提高应用程序性能对数据库一阵折腾，但这真的有效吗？我们是否真的看清哪些问题出在数据库方面，哪些问题出在应用程序方面？

　　几乎所有现代应用程序都要通过数据库实现数据持久化。数据库访问层经常要对严重的性能问题负责。一旦遇到数据库的问题，大多数人开始研究数据库本身。正确的索引和数据库结构对提高性能非常关键。然而，很多时候糟糕的性能或可伸缩性问题的罪魁祸首却是应用程序层，而不是数据库。

　　应用程序层控制并驱动数据库的访问。这一层的问题不能从数据库上得到补偿。所以要想得到高性能和扩展性，数据访问逻辑的设计非常关键。虽然数据库驱动的应用程序中使用情况各不相同，但所有问题能够归结到几个反模式上。分析你的应用程序中是否使用了下列的反模式，并且解决他们，能够以最小的代价简单让你的软件更快、 更稳定。

　　对象/关系映射的误用

　　对象/关系映射已经成为现代数据库应用程序的中心部分。对象/关系映射让人从面向对象软件中翻译和访问关系型数据的重担中解脱出来。它们向应用程序人员隐藏了数据访问大部分的复杂逻辑。由于开发人员更专注于实际的业务逻辑，而不是基础架构细节，会使得生产效率更高。对象关系层不需要看到细节就可以轻松操作复杂的对象图。这经常让人产生错误的印象，认为这些框架让人从设计数据访问逻辑的重担中解脱了出来。

　　开发人员经常认为数据访问框架很容易就把一切搞定了；然而，不理解内部工作机制就使用对象/关系映射框架，很多时候会导致程序性能低下。主要有两个误解引起了这些问题──加载的行为和加载的时间。

　　对象/关系映射基于每个对象加载数据。这意味着只有当一个对象被请求或者访问时，需要的SQL语句才会被创建并执行。这个原则非常普遍，乍一看多数情况下没问题。但同时它也常常是性能和扩展性问题的原因所在。

　　让我们看一个简单的例子。在一个存储地址信息的数据库中，我们有一张表存储人和一张表存储地址。如果我们想得到每个人的名字及其居住的城市，我们不得不遍历人那张表，然后访问地址信息。下图显示了使用直接（out-of-the box）查询机制的结果。可以看出，这个简单的例子就导致了大量的数据库查询。

　　这直接引起了对象/关系映射中第二个重要的细节──加载时间。对象/关系映射-如果没有事先告知-会尽量晚地加载数据。这一行为就是延迟加载。延迟加载保证了数据尽可能晚地加载，目的是执行尽量少的数据库查询，同时避免创建不必要的对象。虽然这个方法通常情况下是可行的，但当它访问那些没有加载的数据，而数据连接已经不存在时，就可能导致严重的性能问题，以及所谓的LazyLoadingExceptions。

　　在如上所述的情况下，使用专门的数据查询能够显著提高性能。

　　因此，虽然对象/关系映射在数据访问的开发方面作用很大，设计合适的数据访问逻辑的重担仍然需要我们挑起。像dynaTrace这样带有工具的动态架构验证，能够帮助有效地识别程序中性能的弱点，并能主动解决。

　　加载了太多数据，实际不需要这么多

　　数据库访问中经常出现的另外一个反模式是加载了太多的数据，而实际上不需要这么多。导致这样的原因很多。快速应用程序开发工具提供了简单的方式，能把数据结构和用户接口控制连接起来。由于数据层由领域对象构成，通常它们包含的数据要比实际显示的多得多。再次使用地址薄作为例子。这一次需要显示人的名字及其居住城市。两个对象──地址和人──都被加载了，而不是只加载这3个字段。这导致了数据库、网络和应用程序层的大量开销。使用专门的查询能够大大减少查询的数据量。然而这种性能的提升需要额外的工作去维护。表中新增一列可能需要对数据访问层修改多处。