水平分表与垂直分表

本文深入探讨了数据库分表的两种主要策略——水平分表和垂直分表,详细讲解了它们的工作原理、优缺点及适用场景。水平分表通过根据查询条件拆分数据,如通过用户ID模运算分配至不同表;垂直分表则依据字段热度和类型进行分割,旨在减少字段数量,提升查询效率。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

水平分表:

      根据主要查询条件需拆分,列入一般我们查询的时候都是去用id去查

       1、 我们先来解决多张表使用唯一的自增id,我 目前看文章看懂的是  可以单独建立一张去记录MaxId  , 也可以用函数去做,但是我没太明白所以就不讲了,

      2、 根据id来判断扔哪张表,  加入有5张,我们来取模   用户id%5  =存在哪张表内,   计算这种的公式也有很多,也可以用Hash的,

     3、 那我们查数据的时候  需要确定那张表 就需要跑公式去找了,但一定要有主查询条件哈~

     4、 缺点就是维护量大- -复杂,推荐能不分就不分 ,例如:升级硬件、升级网络、读写分离、索引优化等等。当数据量达到单表的瓶颈时候,再考虑分库分表。

原因:

     1.根据MySQL索引实现原理及相关优化策略的内容我们知道Innodb主索引叶子节点存储着当前行的所有信息,所以减少字段可使内存加
载更多行数据,有利于查询。

     2.受限于操作系统中的文件大小限制。

 

垂直分表:

    1、根据业务判断你的字段 有哪些热字段 冷字段, 热一组,冷一组 分开,这样可以减少字段数量,然后再把大字段入text类型的那种可以分出去,

   2、不过查询的时候也有弊端, 冷数据并不是不要,需要的时候也要join,

 

原因:

    1.随着数据量的增大,table行数巨大,查询的效率越来越低。表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也

降低了索引的层数,提高查询速度。

    2.同样受限于操作系统中的文件大小限制,数据量不能无限增加,当到达一定容量时,需要水平切分以降低单表(文件)的大小。

### MySQL 数据库中表的水平分表垂直分表方法及其应用场景 #### 水平分表 (Sharding) 水平分表是指将同一张表的数据按照一定的规则拆分成多份,每一份数据存储在一个独立的子表中。这种方式适用于当单个表的数据量非常庞大时。 - **实现方式** - 使用哈希算法或范围分区来决定哪些记录应该存放在哪个子表内。 - 可以通过特定字段(如用户ID)作为键来进行散列计算,从而分配至不同表格。 ```sql CREATE TABLE orders_shard_0 ( order_id INT NOT NULL, user_id INT NOT NULL, product_name VARCHAR(255), PRIMARY KEY(order_id) ); CREATE TABLE orders_shard_1 LIKE orders_shard_0; ``` - **优点** - 减少了单一表内的数据总量,提高了查询效率[^4]。 - 支持更大的并发读写操作,因为各个分片可以分布在不同的机器上运行。 - **缺点** - 跨分片的操作变得复杂,特别是涉及到跨分片连接查询的情况。 - 维护成本增加,包括备份恢复、迁移等方面的工作难度加大。 - **适用场景** - 当某类实体的数量极其巨大,并且存在明显的地域分布或其他可利用特征用于切分时适合采用此策略。 #### 垂直分表 (Vertical Partitioning) 垂直分表则是指对于某些具有大量字段的大宽表而言,将其划分为若干个小窄表的过程。这通常是为了优化频繁使用的少量核心字段其他较少访问的辅助属性之间的关系而设计的一种模式。 - **实现方式** - 将原表中最常被一起检索出来的几个重要字段保留下来形成基础表; - 把其他不太常用或者占用空间较大(例如BLOB类型)的字段单独提取出来创建新的关联表。 ```sql -- 主要信息保存在基本信息表里 CREATE TABLE customer_basic_info( id BIGINT AUTO_INCREMENT, name VARCHAR(64), age TINYINT UNSIGNED, gender ENUM('male', 'female'), PRIMARY KEY(id) ); -- 较少使用的额外资料则放置于扩展表之中 CREATE TABLE customer_extra_details( cust_id BIGINT, address TEXT, profile_pic MEDIUMBLOB, -- 大型二进制对象 FOREIGN KEY(cust_id) REFERENCES customer_basic_info(id) ); ``` - **优点** - 提升了对热点数据项的快速定位能力,减少了不必要的I/O开销[^3]。 - 对于那些包含有大尺寸文本或多媒体内容的应用来说尤其有效果显著。 - **缺点** - 如果处理不当可能会导致过多的小规模JOIN操作影响整体性能表现。 - 设计初期需要充分考虑未来可能的变化趋势以免后期调整困难。 - **适用场景** - 表结构中含有许多低频率使用却占据较多磁盘空间的列时推荐实施该方案。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值