设计的服务接口不合理也经常引起这种反模式。服务接口通常要设计的很通用，以支持大量的用例。其好处是各种各样的用例中都可以使用服务。另外，用例要比后台服务实现变化的快得多。这会导致服务接口在某些场景下不适合。开发人员然后不得不使用一些补救方法，这可能导致数据访问逻辑效率低下。这个问题在数据驱动的Web Services上经常出现。

　　为了克服这些问题，开发过程中需要不断地分析数据访问模式。如果是敏捷开发方法，每个用户故事完成后都应该检查数据访问逻辑。除此之外，应该跨应用程序用例分析数据访问模式，以理解数据访问逻辑，这样能够在开发中相应地优化数据访问逻辑。

　　未充分利用资源

　　数据库是应用程序中资源的瓶颈，所以使用越少越好。通常情况下大家对数据库连接的使用关注甚少。像任何共享的资源一样，数据库连接会严重影响整个系统的性能。尤其是web应用和使用对象/关系映射框架并用了延迟初始化的程序，会让数据库保持连接的时间比需要的更长。处理开始时获得连接，直到页面生成完成或者再也没有数据访问了才断开。在使用对象/关系映射的应用程序中，连接经常保持着以避免可恶的延迟初始化的问题。通过重新设计数据访问逻辑，把它从后处理（比如页面生成）中分离出来，应用程序的性能和扩展性能得到极大的提高。

　　下图展示了 。第一个使用了1个数据库连接，第二个使用了2个连接，第三个使用了2个连接，但是有2/3的处理是在释放连接之后执行的。第三个场景数据访问经过更好的设计，仅用了1/10的资源就获得了几乎同样高的性能。

　　一刀切

　　一刀切是一种反模式，开发过程中经常见到，敏捷团队中则更多。这种反模式的特征是开发了主要功能之后，所有的数据访问就同样对待，好像它们没有任何区别。然而，区别对待不同类型的数据和查询可以显著提高应用程序的性能和扩展性。

　　应该对数据进行分析，考虑其生命周期的特性。它是否经常变化，它是可修改的还是只读的呢？数据的访问频率和访问模式，就隐含了一些潜在的代码，比如可以做缓存。访问频率也暗含了一些线索，比如在哪里做优化更有意义。这可以避免过早进行优化以及不必要的优化，保证了性能调优效果最好。

　　对数据的使用模式进行分析也有助于调整数据访问层。理解真正使用了哪些数据有助于优化加载策略。比如，理解用户怎样浏览搜索结果对优化fetch size很有用。知道了用户是否查看订单详细信息可以给订单选择延迟还是立即加载。

　　除数据之外，查询也应该被分析并分类。重要的因素包括查询时间、执行频率、是否用于交互用户的上下文或者批量处理的场景中。事务特性有助于更好地调整查询的隔离级别。

　　比如，在同一个连接中运行用户短暂的交互查询和时间很长的报表查询，很容易导致终端用户的体验很糟糕。报表查询花费的时间很长，会占用大量的数据库连接，让终端用户的查询无法拿到连接。通过给不同的查询类型使用不同的数据库连接池，会使终端用户的性能更可预测。降低数据库查询中不需要的隔离级别，也能引起性能和扩展性的显著提高。

　　糟糕的测试

　　最后，缺少测试或者测试不正确是数据库访问应用程序性能和稳定性问题的一个主要原因。最近我曾就这一主题作了一个演讲，并询问听众是否把数据库访问看作应用程序中一个性能问题。虽然他们都赞成，但没人有这样的测试流程，来测试数据访问的性能。所以虽然这个话题看上去是很重要，大家似乎都没有花时间去做。然而，即使有测试流程，这也不一定说明测试就是正确的。虽然代码完成后能够立刻发现数据访问逻辑中的很多问题，但通常很晚之后才执行测试，比如负载测试的时候。由于在生命周期的晚期才改动，可能需要修改架构，从而引起额外的开发和测试工作，这带来了很高的不必要的代价。

　　而且，必须设计一些测试用例，来测试真实世界的数据访问场景。测试数据访问必须在并发模式下进行，并且使用不同的访问类型。只有结合使用读/写访问才可能识别死锁和并发的问题。除此之外，输入的数据应该多种多样，以避免数据库访问时经常命中缓存，这是不切合实际的。

　　很多时候人们对预期的负载知之甚少，也不知道去测试哪些负载。很不幸的是，根据我的经验这种情况比比皆是。然而，不能把这当作借口，不定义负载和性能标准。要知道，定义一些标准比一点也不定义要好得多。

　　如果你对性能数据真的毫无头绪，最好是使用负载渐增测试法，逐步增加负载，直到达到了应用程序的最大值。这样你就知道了应用程序的负载峰值。如果负载峰值既合理又现实，那就说明你做的不错。否则你得知道在哪方面提高性能。大多数情况下初始的测试表明，应用程序能够处理的负载要比期望的少得多。

　　结论

　　数据库访问是影响现代应用程序性能和可伸缩性的一个关键点。虽然框架支持构建数据访问逻辑，仍然需要对数据访问逻辑投入相当的精力，以避免种种陷阱和问题。问题之关键是要理解应用程序数据访问层的动态和特性的一切细节。