ShardingSphere水平分表——开发经验（2）

1. 什么场景下分表？

数据量过大或者数据库表对应的磁盘文件过大。
Q：多少数据分表？

A：网上有人说1kw，2kw？不准确。
1、一般看字段的数量，有没有包含text类型的字段。我们的主表里面是不允许有text的大字段的。
2、一般看业务增长量，如果业务还在每天很高的数量增长就需要进行分表。

[!abstract] Note

1. 一般如果数据中有text类型字段的时候就适合，采用垂直分表的方式
2. 如果数据量过大的时候，单个数据库承受不住压力可以采用水平分表

2. 什么情况下分库？

连接不够用。

MySQL Server 假设支持 4000 个数据库连接。一个服务连接池最大 10 个，假设有 40 个节点。已经占用了 400 个数据库连接。
类似于这种服务，有10个，那你这个 MySQL Server 连接就不够了。

[!abstract] Note
连接不够可以进行读写分离，不涉及业务的拆分，只需要进行主从同步，配置多数据源就可以。大多数是读写分离就够了。

3. 又分库又分表？

高并发写入或查询场景。
数据量巨大场景。

3、数据库分库分表框架 ShardingSphere

Sharding-JDBC。

4、分片键

用于将数据库（表）水平拆分的数据库字段。

分库分表中的分片键（Sharding Key）是一个关键决策，它直接影响了分库分表的性能和可扩展性。以下是一些选择分片键的关键因素：

1. 访问频率：选择分片键应考虑数据的访问频率。将经常访问的数据放在同一个分片上，可以提高查询性能和降低跨分片查询的开销。
2. 数据均匀性：分片键应该保证数据的均匀分布在各个分片上，避免出现热点数据集中在某个分片上的情况。
3. 数据不可变：一旦选择了分片键，它应该是不可变的，不能随着业务的变化而频繁修改。
   用户名和用户ID选哪个作为分片键？

• 用户名。用户名可以登录。

分表之后如果查询不带分片建，就会向所有的表中查询

5、引入 ShardingSphere-JDBC到项目

1. 引入依赖

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc-core</artifactId>