# 10 **问答** ### 10.1 分库分表为什么不支持多库多表的查询和分页 答：首先这个问题的实现并不难，当然比较复杂的应该是多个库表查询后分页问题！sqltoy之所以不做这个实现不是做不了，而是没有必要！出现这个问题是设计问题。 举例: 1、 阿里互联网模式：分库会按照用户(商户)ID进行分库，单商户和用户的数据会归集到一个数据库中，从C端而言单商户单用户的数据不存在跨库行为；从阿里自身统计分析而言可以通过数据归集利用大数据模式进行统计分析。 2、 一般企业:数据规模小，通过消息队列方式实现数据归集到hadoop hdfs或elasticSearch或mongo上。ElasticSearch几十亿的数据查询也是毫秒级的。很多项目反映查询慢数据库慢，而数据规模不过日均十万左右，这个根本问题是系统设计问题和甚至是sql问题。 ### 10.2 Sqltoy-orm性能如何？ Sqltoy出发点一个核心问题就是解决性能问题，如： - 主键策略：支持非中心式的程序自动产生模式，有22位、26位有序纳秒模式，雪花算法等。很久之前用过数据库锁模式，教训惨烈！ - Update操作：改变hibernate之前先load再update模式，变成一步数据库交互。 - 所有sql查询都是基于preparedstatement模式，减少数据库对sql的预编译过程。 - 批量级联加载都是基于批量查询的，用程序模式后台组织数据，避免多次数据库交互。 参见loadAllCascade底层实现。 - 分页查询处理快速分页、分页优化外，对count查询的优化达到了极致，不是简单粗暴的一个select count(1) from (你的sql) as t。 等等有很多诸如此类！ 一个系统的核心瓶颈大多数在IO上，尤其是数据库IO上，sqltoy在数据库交互上进行了大量的优化，所有特性都是在项目实践中总结而来，这些问题都是我们所经历过的，当前我经历的单表数据是日均1200万级别的，因此有分库分表策略的应用以及ElasticSearch的应用。 sqltoy自身对sql语句组织处理其实对性能的消耗是极为微小的，应该在1毫秒以内。 ### 10.3 数据库保留字如何处理 见 数据库保留字处理 [链接](https://www.kancloud.cn/hugoxue/sql_toy/2390852) ### 10.4 多数据源怎么弄？ 见 多数据源 [链接](https://www.kancloud.cn/hugoxue/sql_toy/2390847) ### 10.5 可以跟其他ORM一起组合使用吗？ 可以的，你可以独立使用sqltoy也可以结合jpa+sqltoy的查询，你可以根据你的情况做出灵活的组合