数据库分库分表策略？建议收藏

▌ 技术引导 数据库分库分表不是神谕，是硬仗。在百万级数据量下，不做分库分表你可能就已经踩坑了。我见过很多项目因为没及时调整架构，导致查询变慢、写入卡顿，甚至整个服务崩溃。分库分表的决策点很明确：数据量、QPS、业务拆分。如果你的数据量超过50亿条，或者单表超过2000万行，一定要动手。别指望靠数据库的自适应能力扛住，那玩意儿扛不住。我建议优先采用水平分表，先按业务逻辑拆分表，再按时间或ID做分片。工具方面，用ShardingSphere或者MyCat，别闲着，这两个我亲测过。别和我谈垂直分库，除非你有非常清晰的业务模块，否则容易变成表的搬迁。配置参数要盯着，像分片键的选择、分片策略、读写分离权重这些，别乱设。别忘了，分库分表不是一劳永逸的事，要定期评估，甚至在某些场景下，需要反向合并数据。 分库分表的核心是分片算法，这玩意儿真的能救命。我之前用的是雪花算法生成ID，但后来发现按时间分片更稳定，尤其是日志类和订单类业务。别浪费时间在复杂分片策略上，简单粗暴的哈希分片，配合时间分片，性价比最高。记得在分片策略中，要优先考虑查询的频率和数据的热点，把热点数据集中到少数分片，避免单分片负载过高。配置文件里，分片键的设置是最关键的，选错分片键就等于把所有问题都扔到一个分片里。我见过有人用UUID作为分片键，结果每条数据都在不同分片，查询效率直接掉到地狱。别怕麻烦，分片策略要根据业务动态调整。 数据迁移是分库分表的死亡地带。明知道要分库分表，但迁移时总有人偷懒，导致数据不一致或者丢失。我做过一次迁移，用了Flink的CDC功能，实测比传统ETL快3倍以上。别光想着用工具，要懂底层逻辑。数据迁移前，先做全量校验，再做增量同步，同步时要限定时间窗口，不能一上来就吞吐几十万条。分库分表后，查询要写分片语句，别指望数据库能自动识别。记得在查询时，把分片键作为条件，这样才可以命中正确的分片。别忘了，分片后数据量减少，但查询复杂度增加，要合理设计SQL，避免跨分片查询。 分库分表后，索引、事务和连接池的设计必须重新考虑。别幻想数据库还能像以前那样自由。我用的是MyCat，配置了分布式事务，但发现它对性能影响很大，特别是在高并发下。索引要按分片键来，比如按时间分片的表，时间字段必须加索引，否则查询像在大海捞针。连接池不能用原来的配置，要改成分布式连接池，像HikariCP配合分库分表中间件才能流畅。别忽略分库分表后的监控，比如连接数、分片负载、查询延迟，这些数据决定了你是否需要调整策略。 在分库分表实践中，有一件事一定要做，那就是分片策略的热切换。别等到数据库挂了才想起来调整。我之前用的是哈希分片，后来业务增长到3倍，发现某些分片扛不住，就改成时间分片。热切换时，数据迁移要双写，不能停服。别指望用工具就能搞定，要写自己的迁移脚本，加上校验逻辑。分库分表后的SQL优化也别丢，比如用JOIN的时候，要考虑是否跨分片，如果跨分片就改用聚合查询或者分片关联。别用复杂查询，能用简单查询就简单处理。 ▌ 技术参考 一 分库分表不是万能药，但它是中大型数据库系统的救命稻草。2024年之后，很多互联网项目已经不再依赖单一数据库，而是通过分库分表实现数据的高可用和可扩展。分库分表的核心目标是降低单点压力，提升读写性能。按照分片方式，可以分为水平分库、水平分表、垂直分库、垂直分表四种，其中水平分表是最常见的。在实际操作中，需要根据业务特点选择合适的分片策略，比如按时间、地域、用户ID分片。分库分表后，数据库的结构、查询方式、备份策略都会发生本质变化，必须重新设计。 二 我们通常使用分片键来控制数据的分布，分片键的选择直接影响性能。常见的分片键包括用户ID、时间戳、订单号等。在ShardingSphere中，可以通过`shardingColumn`配置分片键，比如`shardingColumn=id`，这样数据就会按照id进行分片。需要注意的是，分片键必须是主键或索引字段，这样数据库才能快速定位分片。如果分片键不是索引，查询效率会直线下降。分片算法可以选择哈希、范围、一致性哈希等，其中哈希分片适合数据分布均匀的场景，而范围分片适合按时间排序的数据。在配置时，可以使用`shardingStrategy`参数指定算法类型。 三 分库分表的数据迁移是关键环节，必须谨慎处理。在迁移过程中，可以使用Flink CDC实现实时同步，或者用MyCat的ETL工具进行批量迁移。比如，使用Flink的SQL API，可以配置如下： ```sql CREATE TABLE source_table (id INT, name STRING) WITH ( 'connector' = 'mysql-cdc', 'hostname' = '127.0.0.1', 'port' = '3306', 'username' = 'root', 'password' = '123456', 'database-name' = 'test', 'table-name' = 'data' ); CREATE TABLE target_table (id INT, name STRING) WITH ( 'connector' = 'jdbc', 'url' = 'jdbc:mysql://127.0.0.1:3306/test', 'table-name' = 'data' ); INSERT INTO target_table SELECT FROM source_table; ``` 这段SQL在迁移时会自动将数据分片发送到目标库。但要注意，迁移前要确保源库和目标库的分片策略一致，否则数据会错乱。 四 分库分表后的查询必须通过分片键来定位数据，否则无法命中正确的分片。比如，在MyCat中，查询语句必须包含分片键，否则会启动全表扫描。例如，`SELECT FROM orders WHERE user_id = ?`的查询可以命中对应的分片，但如果写成`SELECT FROM orders`，就会变成广播查询，性能崩溃。为了避免这种情况，可以在配置文件中设置`auto-commit`为`false`，并启用逻辑主键，让MyCat自动判断分片。此外，还可以通过`sharding-core`模块实现动态路由，避免硬编码分片逻辑。 五 分库分表容易遇到的问题包括数据倾斜、分片键冲突、查询性能下降等。比如，数据倾斜是指某些分片的数据量远大于其他分片，导致负载不均。我之前用哈希分片，发现某个分片数据量是其他分片的5倍，查询时明显变慢。解决方法是调整分片策略，比如使用一致性哈希或范围分片，或者手动平衡数据。分片键冲突是指不同业务的数据被分到同一分片，影响查询效率。例如，订单和用户数据如果都用user_id作为分片键，就容易冲突。解决办法是设计独立的分片策略，或者使用多个分片键。 六 分库分表对性能的影响取决于分片策略和数据访问模式。在水平分表中，查询性能通常会提升，因为数据量减少，索引更小，但写入性能可能会下降，因为需要处理多个分片的写入。例如，使用ShardingSphere的分片策略，可以配置`sharding-algorithm`为`standard`，这样写入时会自动分配到正确的分片。实测结果显示，在QPS超过5000的情况下，分库分表可以提升查询速度30%以上，但写入可能会翻倍。如果是读多写少的场景，分库分表是首选；如果是高并发写，可能需要采用其他方案，比如分库不分表，或者使用缓存层。 七 分库分表适用于数据量大、写入压力高、查询复杂度高的场景。比如，电商系统中的订单表，如果单表数据超过2000万行，就需要分表。分库分表后的数据量减少，查询效率提升，但也会带来额外的复杂性。比如，需要考虑分片键的选择、数据迁移、事务一致性、读写分离等问题。此外，分库分表后，备份和恢复也会变得更加复杂，需要使用分布式备份工具，比如MyCat的`backup`功能，或者使用Kafka做数据备份。 八 分库分表的替代方案包括使用分布式数据库、读写分离、引入缓存层等。比如，TiDB是一个很好的替代选择，它本身就是为分库分表设计的，支持水平分片和分布式事务。如果你不想自己折腾分库分表，可以考虑使用TiDB，它会自动处理分片、路由、负载均衡等问题。另外，读写分离也是常见的优化手段，比如使用MySQL Proxy或者ShardingSphere的读写分离功能，将读操作分发到从库，写操作集中到主库。这种方法适合读多写少的场景，但无法解决写入压力过大的问题。 九 分库分表的进阶技巧包括使用动态分片、多分片键、联合分片等。动态分片可以根据业务需求实时调整分片策略，比如使用Redis存储动态分片规则，然后通过应用层来路由查询。多分片键是指同时使用多个字段作为分片依据，比如user_id和order_id联合分片，可以避免数据倾斜。联合分片在配置时需要指定多个分片键，比如在ShardingSphere中，可以配置`sharding-key`为`user_id,order_id`，这样数据会按照这两个字段进行分片。这些技巧能进一步优化性能，但需要一定的架构设计能力。 十 分库分表的性能优化离不开索引和查询语句的调整。在每个分片中，必须为常用查询字段添加索引，比如user_id、create_time等。如果查询条件包含多个字段，比如`WHERE user_id = ? AND create_time > ?`，可以考虑使用组合索引，或者优化查询逻辑，避免跨分片查询。此外，可以使用缓存来减少数据库压力，比如Redis缓存高频查询结果，避免每次都查询数据库。在ShardingSphere中，可以配置`cacheable`为`true`，让查询结果缓存，减少重复查询。 十一 分库分表后的事务处理需要特别谨慎，因为事务可能跨多个分片，导致性能下降或数据不一致。在ShardingSphere中，可以配置`sharding-core`模块来实现分布式事务，但事务的性能会明显下降。例如，使用JTA事务时，可能会导致事务提交时间变长，甚至超时。更好的做法是使用本地事务，将事务控制在单个分片内，或者采用最终一致性方案。比如，使用消息队列异步处理业务逻辑，避免高并发下的锁争用。 十二 在分库分表的配置中，分片策略和路由算法是两个核心参数。比如，在ShardingSphere中，可以配置`sharding-strategy`为`standard`，并设置分片键为`user_id`。 ```yaml shardingRule: tables: orders: actual-data-nodes: orders_${0..1}.t_orders database-strategy: standard: shardingColumn: user_id shardingAlgorithmName: user_mod table-strategy: standard: shardingColumn: order_id shardingAlgorithmName: order_mod ``` 这段配置将orders表分到两个数据库中，每个数据库下有一个分片。分片算法使用取模运算，将数据均匀分布。如果分片数不够，可以动态增加分片，但必须重新配置。 十三 分库分表后的监控是不可或缺的，必须实时跟踪各分片的负载情况。可以使用Prometheus+Grafana监控MyCat的连接数、查询延迟、分片负载等指标。比如，配置MyCat的`manager`模块，开启监控接口： ```bash # mycat/conf/server.xml true10100 ``` 这些参数控制了查询处理、连接池大小和并发数，可以调整以提升性能。监控数据可以帮助你及时发现数据倾斜或分片异常，及时调整策略。 十四 分库分表后，数据备份和恢复的流程也需要调整。例如，使用MySQL的`mysqldump`工具进行全量备份时，需要指定分片策略，避免备份所有数据。在MyCat中，可以配置`backup`功能，将数据自动备份到指定的从库。 ```bash # 备份命令示例 mysqldump -h 127.0.0.1 -u root -p123456 test orders > orders_backup.sql ``` 恢复时需要确保分片策略一致，否则数据会错乱。对于增量备份，可以使用Flink CDC实时同步，确保数据的一致性。分库分表后的数据一致性管理是关键，不能掉以轻心。 十五 在实际部署中，分库分表的配置会遇到很多问题，比如分片键冲突、数据迁移失败、连接池配置错误等。例如，使用MyCat时，如果配置的`auto-commit`为`true`，在事务中可能会出现分片不一致的问题。解决方法是设置`auto-commit`为`false`，并在事务提交后手动提交。另外，连接池配置需要根据实际负载调整，比如设置`minIdle`和`maxIdle`为合适的数值。如果分片数太多，查询性能反而会下降，需要根据业务需求动态调整分片数。