分库分表会带来什么问题

wxypython

已于 2023-11-30 15:18:29 修改

阅读量68

点赞数

分类专栏： Mysql 文章标签： python mysql

于 2023-11-30 15:12:53 首次发布

本文链接：https://blog.csdn.net/wxypython/article/details/134712550

版权

Mysql 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

从分库的角度来看

事务的问题

使用关系型数据库，可以保证事务完整性

分库之后事务用不上了，必须使用分布式事务

跨库join问题

跨库无法使用join

解决方案：1.业务代码关联，先查第一张表，再查第二张表

2.冗余字段，把关联的内容常用的添加冗余字段（但原表修改后要修改冗余字段）

3.数据异构，通过binlog同步等方式，把需要跨库join的数据同步到es的大宽表里去，通过es直接查询

从分表的角度来看

跨节点的 count 、order by 、group by 以及聚合函数

业务代码进行解决

数据迁移、容量规划、扩容

数据的迁移、容量如何规划、未来是否需要再次扩容

MySQL 数据库扩容通常指的是在数据库存储容量、性能或吞吐量方面的增长。根据不同的需要，MySQL 数据库扩容可以通过以下几种方式进行：

垂直扩容 (Vertical Scaling)：

升级现有服务器的硬件，如增加 CPU、内存或更快的存储设备。
升级可以提高单个数据库服务器的处理能力，但这种方式的缺点是成本高，且存在物理极限。

水平扩容 (Horizontal Scaling)：

也称为分布式扩容或扩展，涉及到数据库分片（Sharding）或复制（Replication）。
分片是将数据分布到多个数据库或表中，每个数据库或表只存储全部数据的一部分。
复制涉及将数据复制到多个服务器，可以是主从复制（Master-Slave）或主主复制（Master-Master）。

读写分离：

将读操作和写操作分离，通常使用主从复制。写操作发生在主服务器上，而读操作可以分散到多个从服务器上。
读写分离可以显著提升读取性能和系统的并发处理能力。

使用代理或者中间件：

使用数据库代理或中间件如ProxySQL, MySQL Router, MyCAT等，可以实现负载均衡、查询路由、读写分离等功能。
代理或中间件可以在不更改应用代码的情况下实现数据库的扩容。

应用层分库分表：

在应用层实现数据的水平分片，可以根据业务逻辑将数据分散到不同的数据库实例或物理服务器上。
这要求应用具有一定的数据路由逻辑来决定数据应该存储和查询的位置。

使用云数据库服务：

许多云服务提供商（如Amazon RDS, Google Cloud SQL, Azure Database for MySQL）提供了易于扩容的托管MySQL服务。
云数据库服务通常提供了自动扩展的功能，使得扩容更为便捷。

在考虑扩容方案时，需要评估当前系统的瓶颈、业务需求、成本效益和未来的扩展性。例如，如果读操作是性能瓶颈，读写分离或增加从服务器可能是有效的解决方案。如果数据量的增长是问题，可能需要考虑使用分片或云数据库服务。进行任何扩容操作之前，都应该进行充分的测试，以确保新架构能够满足要求，同时不会引入新的问题。

ID问题

1.多张表设置自增步长

2.uuid，不连续的主键插入会导致严重的页分裂，性能较差

UUID（Universally Unique Identifier）是一种基于特定算法生成的128位长的唯一标识符，常用作数据库的主键。由于UUID是随机生成的，它是不连续的，导致插入操作时的主键顺序是无序的。

在许多数据库管理系统中，如MySQL的InnoDB存储引擎，数据是按照主键顺序存储在B-tree结构中的。由于UUID是不连续且无序的，使用UUID作为主键将会产生以下影响：

页分裂（Page Split）：当新数据（例如使用UUID作为主键的记录）插入到B-tree时，由于主键是随机的，这条记录可能需要插入到B-tree中任意位置的页（page）中。如果该页没有足够的空间来存储新数据，数据库就需要执行页分裂操作：它将当前页的一部分数据移动到一个新页中，为新数据腾出空间。这种操作非常耗费资源，因为它涉及到额外的磁盘I/O、数据复制和索引更新。

索引碎片化：频繁的页分裂会导致索引碎片化。这意味着数据在物理存储上的排列顺序和逻辑顺序不匹配，导致查询性能下降，因为数据库可能需要加载更多的页来找到所需的数据。

缓存利用不佳：使用UUID作为主键，由于插入位置的随机性，可能会导致数据库缓存层面的不连续性，降低缓存的命中率，因为不太可能有连续的数据页被频繁访问和缓存。

增大存储需求： UUID作为128位的标识符，比传统的整数主键要占用更多的存储空间。此外，由于页分裂，会产生更多半满的页，这会进一步增加存储空间的浪费。

由于这些原因，UUID虽然提供了唯一性和易于分布式系统使用的优势，但在作为数据库主键时，它可能会导致性能问题。为了缓解这些问题，一些策略可能包括：

使用COMB（Combined Time-GUID）类型的UUID，它在UUID的一部分中嵌入时间戳，以使生成的UUID在一定程度上有序。
在不需要全局唯一性的情况下，考虑使用其他类型的唯一标识符，如自增主键。
定期对数据库索引进行碎片整理以减少索引碎片化的影响。
在适当的时候增加页大小，以减少页分裂的频率。

3.分布式id，twitter sonwflake 雪花算法

Twitter Snowflake（雪花算法）是Twitter设计的一种分布式系统中生成唯一ID的算法。其目的是解决在分布式系统中，不同机器上生成唯一的ID（例如在Twitter的情况下，每条推文的ID）的需求。在分布式环境下，由于不同机器的时钟无法保证完全同步，且网络延迟等因素的存在，使用传统的递增序列作为唯一标识符会遇到诸多问题。

Snowflake算法生成的是一个64位的长整型数字（Long），按照位从高到低的顺序，分为以下几个部分：

0 - 占用1位：最高位是符号位，生成的ID一般用正数，所以这个位固定为0。

时间戳 - 占用41位：接下来的41位用来记录时间戳，单位为毫秒。41位可以表示$2^{41}-1$个数字，如果只用来表示时间戳的话，可以保证69年内不会重复。

数据中心ID - 占用一定位数：接下来的几位（例如5位）用于记录数据中心ID，这可以有$2^{5}-1=31$个数据中心。

机器ID - 占用一定位数：紧接着的几位（例如5位）用于记录机器ID，同样可以有31台机器。

序列号 - 占用一定位数：最后的几位（例如12位）用于在同一毫秒内生成多个ID。12位可以表示$2^{12}-1=4095$个不同的ID。

因此，Snowflake算法可以确保：

同一时间（同一毫秒）内生成的ID是唯一的，通过序列号实现。
不同时间生成的ID是唯一的，通过时间戳实现。
多台机器生成的ID是唯一的，通过数据中心ID和机器ID实现。

此算法的优点是生成ID的速度快，且ID是趋势递增的（因时间戳部分在高位），在分布式系统中应用广泛，不仅Twitter，很多其他系统也采用了这种或类似的算法来生成全局唯一ID。雪花算法在互联网公司中应用非常广泛，适用于任何需要生成唯一ID的场景。