由于编程思想和数据库的设计模式不同，因此给出了一些ORM框架。
核心是将关系数据库和数据转换为对象类型。当前的流行方案包括Hibernate和Mybatis。
两者具有自己的优势和缺点。竞争是激烈的，更重要的考虑因素之一是表现。
因此，通过各种实验，作者在同一情况下测量了与性能有关的两个索引以供参考。
友好的提醒：如果您怀疑这篇文章太长了，则可以将文本的结尾拉到以查看结论。
需要确定以下测试：
性能差异的场景；
在同一场景中的性能没有什么不同。
找到每个框架的优势和缺点，各种情况下的性能以及应用场景。
测试整体划分：单个表插入，关联的插入，单表查询，多表格查询。
测试分为两轮。在同一场景中，默认参数进行了一轮。
确保测试中的输入和输出一致性。
样品体积尽可能大，达到100,000个水平，并减少了统计误差。
在特定场景中
插入测试100万记录插入。
查询测试1：100万个数据中表通过ID查询100,000次，没有连接的字段。
查询测试2：100万个数据中表通过ID查询100,000次，并输出关联的对象字段。
查询测试3：100万*500,000相关数据查询100,000次，两者输出相同的字段。
数据库：MySQL 5.6
表设计：
Twitter：Twitter
用户：用户
测试数据准备：
表1：Twitter
没有数据。
表2：用户
500,000个随机用户名。
随机内容Twitter表（材料_twitter）
没有ID，只有随机字符串内容，总计100,000。
用于插入控制表。
生成数据代码，相关100用户：
生成数据代码，相关500,000用户：
物理代码
插入测试1
代码操作：
将随机内容Twitter表的数据加载到内存中，然后将其添加到Twitter表中，总计100,000。
关键代码：
冬眠：
mybatis：
twittermapper.xml，插入代码片段：
查询测试1
从ID到100,000的1到100,000次，查询Twitter内容仅导出微博内容。
关键代码：
冬眠：
mybatis：
查询测试2
像查询测试1一样，添加了微博的创始人的名称字段，需要在此关联。
其中，有100,000个用户可能会重复使用。这里相应的用户数量可能会影响懒洋洋的Hibernate加载的状况。
这是一个方便的休眠场所，您可以直接通过getAdduser（）直接获得与用户相关的字段。
但是，Mybatis需要编写一个新的VO，因此在测试Batis时，将CreateUsername直接添加到Twitter实体中。
这里的Hibernate将测试懒惰和懒惰的装载。
Mybatis将测试默认情况和缓存情况。
其中，Mybatis的缓存机制更难配置，并且不适合真实业务（可能具有肮脏的数据），这仅适用于参考。
在测试期间，与Twitter关联的用户数量造成了两种情况。一个是Twitter共有100个用户，即不同的Twitter，即在100个用户中，此处的相关关系是随机生成的。
另一个是Twitter共有500,000名用户，将发现50个用户的信息。
您可以在上面的“准备”中看到相关的数据生成方法。
关键代码：
冬眠：
无声加载配置更改，twitter.java：
mybatis：
twittermapper.xml配置：
检测结果
测试分析
测试分为插入，单个表查询，相关查询。相关查询中的三种情况分为三种情况。
其中，在相关的字段查询中，在两种情况下，Hibernate具有较大的性能差异。在懒惰加载的情况下，如果有很多用户与Twitter相对应，则性能将比只有100个用户的情况差得多。
换句话说，如果用户数量很少（与之关联的用户总数），也就是说，当将重复查询相同的用户时，则无需在用户表上进行过多查询。
查询文档后，证明在使用懒惰加载时，该对象将使用ID作为缓存的关键，也就是说，在查询100个用户后，随后的用户信息使用缓存来从根本上改善性能。甚至高于mybatis。
如果与500,000用户有关，Hibernate需要查询500,000个用户信息并组装这500,000个用户。在此时间。
其中，Hibernate的非懒惰负载也与Mybatis的其他测试相对较大，平均值小于1ms。
造成这种差异的主要原因是，由Mybatis加载的字段非常干净，并且没有太多直接反射到协会中的字段。相反，Hibernate将整个表将整个表加载到对象，还包括关联的对象用户字段。
在这种情况下，冬眠是好是坏。这取决于特定场景。对于管理平台，信息需要更多信息。当并发要求不高时，Hibernate具有优势。
但是，在一些小型活动中，在Internet网站上，在高组合下，Hibernate的解决方案不合适，Mybatis+VO是首选。
此外，请注意公共帐户Java Technology Stack，在背景中回复：采访，您可以获得MYBATIS系列的面部测试问题和答案，这是非常完整的。
通常，在所有情况下，在所有情况下，尤其是插入和单表可查询，它们都会比冬眠略好。但是，差异并不明显，并且基本上可以忽略差异。
区别在于，为了确保POJO在关联查询期间的数据完整性，Hibernate需要加载相关数据并需要其他数据。Hibernate不提供相应的灵活性。
关联的很大差异是懒惰的加载特性。在它们的情况下，Hibernate可以特别使用POJO完整性来缓存，并且可以在第一和第二级缓存中保存对象。如果对单个对象进行更多查询，将会有明显的性能好处。
将来，当关联单个对象时，可以通过懒惰加载并添加第二级高速缓存来提高性能。
最后，数据查询的性能与ORM框架没有太多关系，因为ORM主要帮助开发人员将关系数据转换为对象型数据模型。根据代码的分析，Hibernate设计为更重量级。它可以被视为数据库的重新开发，以防止数据库过多关注的特征的发展。它是根据冬眠直接开发的。它分为SQL生成，数据包装和其他过程。这里需要很多时间。但是，Mybatis更直接，主要是关联和输出字段之间的映射。在它们中，SQL基本上是编写的，可以直接替换它。您不需要动态生成整个SQL语句，例如Hibernate。
幸运的是，在此阶段已经优化了Hibernate。它的性能没有太大的差异，而在发展效率方面，可伸缩性比Mybatis好得多。
最后，关于Mybatis缓存，缓慢的冬眠查询等，然后进行测试。
与Hibernate和其他封装相比，Mybatis的ORM实施方面，由于Hibernate的数据对象的操作已实现了严格的包装，这可以确保在其角色范围内的高速缓存同步，并且IBATIS提供了半公开的包装实现是的，因此对于半公开的包装实现，因此，出于原因，对于半公开的包装实现，因此对于半透明的包装实现，因此，对于半插入包装实现的原因，因此，出于原因，提供了半公开的包装实现，因此对于半盖的软件包实现，缓存的SOTHE操作很难完成完整的自动化同步。
上述缓存配置测试仅在性能中进行分析。它不会添加可用性，因为Mybatis直接配置了缓存，可能会显示脏数据。
在相关查询数据的情况下，Hiberntae的懒惰负载和次要缓存是一个更好的解决方案（没有脏数据），与Mybatis相比，它也是一个相对明显的优势。在这种情况下，性能与Mybatis相同。
在实际情况下，Mybatis可能不会在此位置配置缓存，并且会发生肮脏的数据，因此在这里，冬眠性能很可能会更好。
作者：Zheng Muxing