8 个性化分片参数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.2 资源最大限度利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.3 高可用 . . . . . . . . . 表示广州。合理使用个性化 参数可以让代码更可读，如果配置为 0= 北京,1= 上海,2= 广州，那么代码中直接使用北京，上海，广州的 枚举值即可完成分片项和业务逻辑的对应关系。 5.2.2 资源最大限度利用 ElasticJob 提供最灵活的方式，最大限度的提高执行作业的吞吐量。当新增加作业服务器时，ElasticJob 会通过注册中心的临时节点的变化感知到新服务器的存在，并在下次任务调度的时候重新分片，新的服 器倍数的数量，作业将会合理的利用分布式资源，动 态的分配分片项。 例如：3 台服务器，分成 10 片，则分片项分配结果为服务器 A = 0,1,2,9；服务器 B = 3,4,5；服务器 C = 6,7,8。如果服务器 C 崩溃，则分片项分配结果为服务器 A = 0,1,2,3,4; 服务器 B = 5,6,7,8,9。在不丢失分片 项的情况下，最大限度的利用现有资源提高吞吐量。 5.2

篇幅。不过为了让你能够了解个大概，这里会给出几个例子。 在上面提到的两个例子中，一个语句应该是通过 XML 定义，而另外一个则是通过注解定义。先看 XML 定义这个，事实上 MyBatis 提 供的全部特性可以利用基于 XML 的映射语言来实现，这使得 MyBatis 在过去的数年间得以流行。如果你以前用过 MyBatis，这个概 念应该会比较熟悉。不过 XML 映射文件已经有了很多的改进，随着文档的进行会愈发清晰。这里给出一个基于 mapper.selectBlog(101); 第二种方法有很多优势，首先它不是基于字符串常量的，就会更安全；其次，如果你的 IDE 有代码补全功能，那么你可以在有了已映射 SQL 语句的基础之上利用这个功能。 PDFmyURL - the best online web to pdf conversion service 提示 提示 提示 提示 命名空间的一点注释 命名空间的一点注释 命名空间（ case）映射，即从 经典数据库列名 A_COLUMN 到经典 Java 属性名 aColumn 的类似映 射。 true | false False localCacheScope MyBatis 利用本地 缓存机制（Local Cache）防止循环 引用（circular references）和加 速重复嵌套查询。 默认值为 SESSION，这种情 况下会缓存一个会 话中执行的所有查 询。 若设置值为

源异构数据库增强平台，进而围绕其上层 构建生态。 Apache ShardingSphere 设计哲学为 Database Plus，旨在构建异构数据库上层的标准和生态。它关注如 何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。它站在数据库的上层视角， 关注它们之间的协作多于数据库自身。 ShardingSphere-JDBC ShardingSphere‐JDBC ngSphere 基于无状态服务，提供高可用 计算服务访问；同时可感知并利用底层数据库自身高可用实现整体的高可用能力。 数 据 迁移 数据迁移，是打通数据生态的关键能力。SharingSphere 提供基于数据全场景的迁移能力，可 应对业务数据量激增的场景。 联 邦 查询 联邦查询，是面对复杂数据环境下利用数据的有效手段之一。ShardingSphere 提供跨数据源 的复杂数据查询分析能力，简化并提升数据使用体验。 3.3.4 应用场景 复杂的主从数据库架构 许多系统通过采用主从数据库架构的配置来提高整个系统的吞吐量，但是主从的配置也给业务的使用带 来了一定的复杂性。接入 ShardingSphere，可以利用读写分离功能管理主从数据库，实现透明化的读写 分离功能，让用户像使用一个数据库一样使用主从架构的数据库。 3.3.5 相关参考 Java API YAML 配置 Spring Boot Starter

数据水平 扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用 场景。 Apache ShardingSphere 旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并 非实现一个全新的关系型数据库。关系型数据库当今依然占有巨大市场份额，是企业核心系统的基石，未 来也难于撼动，我们更加注重在原有基础上提供增量，而非颠覆。 Apache t_order_17 ├── t_order_18 ├── t_order_19 └── t_order_20 可以使用分开配置的方式，先配置包含前缀的数据节点，再配置不含前缀的数据节点，再利用行表达式 笛卡尔积的特性，自动组合即可。上面的示例，用行表达式可以简化为： 3.1. 数据分片 17 Apache ShardingSphere document, v5.0.0-beta db${0 将产生落在同库不同表的大量真实 SQL ，如 果每条真实 SQL 都占用一个独立的连接，那么一次查询无疑将会占用过多的资源。 从执行效率的角度看，为每个分片查询维持一个独立的数据库连接，可以更加有效的利用多线程来提升 执行效率。为每个数据库连接开启独立的线程，可以将 I/O 所产生的消耗并行处理。为每个分片维持一个 独立的数据库连接，还能够避免过早的将查询结果数据加载至内存。独立的数据库连接，能够持有查询

1 概览 星评增长时间线 贡献者增长时间线 Apache ShardingSphere 产品定位为 Database Plus，旨在构建异构数据库上层的标准和生态。它关 注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。ShardingSphere 站在 数据库的上层视角，关注他们之间的协作多于数据库自身。 连接、增量和 可插拔是 Apache ShardingSphere t_order_17 ├── t_order_18 ├── t_order_19 └── t_order_20 可以使用分开配置的方式，先配置包含前缀的数据节点，再配置不含前缀的数据节点，再利用行表达式 笛卡尔积的特性，自动组合即可。上面的示例，用行表达式可以简化为： db${0..1}.t_order_0${0..9}, db${0..1}.t_order_${10..20} 或者： 查询偏移量过大的分页会导致数据库获取数据性能低下，以 MySQL 为例： SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10 这句 SQL 会使得 MySQL 在无法利用索引的情况下跳过 1,000,000 条记录后，再获取 10 条记录，其性能 可想而知。而在分库分表的情况下（假设分为 2 个库），为了保证数据的正确性，SQL 会改写为： SELECT * FROM

1 概览 星评增长时间线 贡献者增长时间线 Apache ShardingSphere 产品定位为 Database Plus，旨在构建异构数据库上层的标准和生态。它关 注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。ShardingSphere 站在 数据库的上层视角，关注他们之间的协作多于数据库自身。 连接、增量和可插拔是 Apache ShardingSphere t_order_17 ├── t_order_18 ├── t_order_19 └── t_order_20 可以使用分开配置的方式，先配置包含前缀的数据节点，再配置不含前缀的数据节点，再利用行表达式 笛卡尔积的特性，自动组合即可。上面的示例，用行表达式可以简化为： db${0..1}.t_order_0${0..9}, db${0..1}.t_order_${10..20} 或者 查询偏移量过大的分页会导致数据库获取数据性能低下，以 MySQL 为例： SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10 这句 SQL 会使得 MySQL 在无法利用索引的情况下跳过 1,000,000 条记录后，再获取 10 条记录，其性能 可想而知。而在分库分表的情况下（假设分为 2 个库），为了保证数据的正确性，SQL 会改写为： SELECT * FROM

1 概览 星评增长时间线 贡献者增长时间线 Apache ShardingSphere 产品定位为 Database Plus，旨在构建异构数据库上层的标准和生态。它关 注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。ShardingSphere 站在 数据库的上层视角，关注他们之间的协作多于数据库自身。 连接、增量和 可插拔是 Apache ShardingSphere t_order_17 ├── t_order_18 ├── t_order_19 └── t_order_20 可以使用分开配置的方式，先配置包含前缀的数据节点，再配置不含前缀的数据节点，再利用行表达式 笛卡尔积的特性，自动组合即可。上面的示例，用行表达式可以简化为： db${0..1}.t_order_0${0..9}, db${0..1}.t_order_${10..20} 或者： 查询偏移量过大的分页会导致数据库获取数据性能低下，以 MySQL 为例： SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10 这句 SQL 会使得 MySQL 在无法利用索引的情况下跳过 1,000,000 条记录后，再获取 10 条记录，其性能 可想而知。而在分库分表的情况下（假设分为 2 个库），为了保证数据的正确性，SQL 会改写为： SELECT * FROM

1 概览 星评增长时间线 贡献者增长时间线 Apache ShardingSphere 产品定位为 Database Plus，旨在构建多模数据库上层的标准和生态。它关 注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。ShardingSphere 站在 数据库的上层视角，关注他们之间的协作多于数据库自身。 连接、增量和可插拔是 Apache ShardingSphere t_order_17 ├── t_order_18 ├── t_order_19 └── t_order_20 可以使用分开配置的方式，先配置包含前缀的数据节点，再配置不含前缀的数据节点，再利用行表达式 笛卡尔积的特性，自动组合即可。上面的示例，用行表达式可以简化为： db${0..1}.t_order_0${0..9}, db${0..1}.t_order_${10..20} 或者 查询偏移量过大的分页会导致数据库获取数据性能低下，以 MySQL 为例： SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10 这句 SQL 会使得 MySQL 在无法利用索引的情况下跳过 1,000,000 条记录后，再获取 10 条记录，其性能 可想而知。而在分库分表的情况下（假设分为 2 个库），为了保证数据的正确性，SQL 会改写为： 4.2. 数据分片 35

通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。 Apache ShardingSphere 设计哲学为 Database Plus，旨在构建异构数据库上层的标准和生态。它关注如 何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。它站在数据库的上层视角， 关注它们之间的协作多于数据库自身。 1.1.1 ShardingSphere-JDBC ShardingSphere‐JDBC 8.3.4 应用场景 复杂的主从数据库架构 许多系统通过采用主从数据库架构的配置来提高整个系统的吞吐量，但是主从的配置也给业务的使用带 来了一定的复杂性。接入 ShardingSphere，可以利用读写分离功能管理主从数据库，实现透明化的读写 分离功能，让用户像使用一个数据库一样使用主从架构的数据库。 8.3. 读写分离 36 Apache ShardingSphere document 119.9977/0.01 # 每个线程平 均耗时 119.9977 秒，标准差为 0.01 压测过程中值得关注的点 1. ShardingSphere‐Proxy 所在服务器 CPU 利用率，充分利用 CPU 为佳； 2. DB 所在服务器磁盘 IO，物理读越低越好； 3. 压测中涉及服务器的网络 IO。 11.5.2 BenchmarkSQL ShardingSphere Proxy

通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。 Apache ShardingSphere 设计哲学为 Database Plus，旨在构建异构数据库上层的标准和生态。它关注如 何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。它站在数据库的上层视角， 关注它们之间的协作多于数据库自身。 1.1.1 ShardingSphere-JDBC ShardingSphere‐JDBC 8.3.4 应用场景 复杂的主从数据库架构 许多系统通过采用主从数据库架构的配置来提高整个系统的吞吐量，但是主从的配置也给业务的使用带 来了一定的复杂性。接入 ShardingSphere，可以利用读写分离功能管理主从数据库，实现透明化的读写 分离功能，让用户像使用一个数据库一样使用主从架构的数据库。 8.3. 读写分离 36 Apache ShardingSphere document 119.9977/0.01 # 每个线程平 均耗时 119.9977 秒，标准差为 0.01 压测过程中值得关注的点 1. ShardingSphere‐Proxy 所在服务器 CPU 利用率，充分利用 CPU 为佳； 2. DB 所在服务器磁盘 IO，物理读越低越好； 3. 压测中涉及服务器的网络 IO。 11.5. 性能测试 414 Apache ShardingSphere document