在使用Sharding-JDBC进行数据库分库分表时，如何根据业务需求设计垂直和水平拆分策略，并结合Sharding-JDBC进行配置？请提供配置示例。

在面对大数据量和高并发场景时，合理设计数据库的垂直和水平拆分策略对于提升系统性能至关重要。垂直拆分主要关注于数据库的业务层面，将不同业务的数据表分开存储，以减少单表数据量和业务间的耦合度。而水平拆分则是将一张大表根据规则拆分成多张结构相同的子表，并分散存储于不同的数据库中，以提高数据操作的并发能力和系统的横向扩展性。Sharding-JDBC作为一款轻量级的Java框架，提供了灵活的配置方式来实现这两种拆分策略。

参考资源链接：[Sharding-JDBC分库分表详解：从概念到配置](https://wenku.csdn.net/doc/3z6wyena4w?spm=1055.2569.3001.10343)

以Sharding-JDBC进行垂直拆分为例，我们可以根据业务模块的不同，将相关的数据表进行拆分。比如，用户信息表和订单信息表因为业务关联度较低，可以分别存储在不同的数据库中。而在Sharding-JDBC中，我们可以通过配置文件来定义这种拆分策略，以下是一个简单的配置示例：

shardingRule:
  tables:
    user_info:
      actualDataNodes: ds1.user_info
    order_info:
      actualDataNodes: ds2.order_info
  defaultDataSourceName: ds1

在这个配置中，我们定义了两个逻辑表`user_info`和`order_info`，它们分别映射到不同的物理数据源`ds1`和`ds2`上。这里的`actualDataNodes`指明了实际的数据节点。

对于水平拆分，我们可以通过分片键来决定数据应该存储在哪个子表中。例如，如果我们要根据订单ID来拆分订单表`order`，可以将订单ID对10取余后的结果作为分片键，规则配置如下：

shardingRule:
  tables:
    order:
      actualDataNodes: ds${0..1}.order${0..9}
      tableStrategy:
        inline:
          shardingColumn: order_id
          algorithmExpression: order${order_id % 10}
  defaultDataSourceName: ds0

这里，`algorithmExpression`定义了分片算法，`order_id % 10`决定了数据落在哪个子表中（`order0`到`order9`）。`actualDataNodes`则定义了实际的数据节点列表。

通过上述配置，Sharding-JDBC能够根据业务需求自动将数据分片存储到不同的数据源和表中，实现了垂直和水平拆分。如果需要进一步了解分库分表的高级配置和最佳实践，可以参考《Sharding-JDBC分库分表详解：从概念到配置》。这本书详细介绍了分库分表的概念、策略和配置方法，能够帮助开发者更深入地理解和掌握Sharding-JDBC的使用，从而更好地应对复杂场景下的数据库架构设计需求。

参考资源链接：[Sharding-JDBC分库分表详解：从概念到配置](https://wenku.csdn.net/doc/3z6wyena4w?spm=1055.2569.3001.10343)