数据库优化

本文介绍了数据库优化中的主从读写分离和分库分表策略。主从复制通过binlog实现数据同步,解决并发读写问题。主从读写分离可减轻主库压力,但面临主从延迟和一致性挑战。分库分表分为垂直拆分和水平拆分,解决数据量大的问题,但引入了分库分表键和跨库JOIN等问题。文章还探讨了如何保证分库分表后的ID全局唯一性,并提到了数据库设计的四范式以及UUID和Snowflake算法等ID生成策略。

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

一、主从读写分离
主库:主要负责数据的写入。
从库:主要负责数据的查询。

引出问题:

  1. 可能会存在主从延迟,导致主从一致性问题。
  2. 查询主库的量级需要控制。
  3. 数据量庞大,索引也占据存储空间,磁盘空间不足,当主库宕机后会影响所有模块的写入,需要进行数据分片,因此引出分库分表的解决策略。

解决方法:

  1. 主从复制
  • binlog:MySQL的主从复制是依赖于binlog的,也就是记录MySQL上的所有变化并以二进制形式保存在磁盘上二进制日志文件。主从复制就是将binlog中的数据从主库传输到从库上,一般这个过程是异步的,即主库上的操作不会等待binlog同步的完成。

  • 主从复制原理:首先从库在连接到主节点时会创建一个IO线程,用以请求主库更新的binlog,并且把接收到的binlog信息写入一个叫做relay log的日志文件中,而主库也会创建一个log dump线程来发送binlog给从库;同时,从库还会创建一个SQL线程读取relay log中的内容,并且在从库中做回放,最终实现主从的一致性。这是一种比较常见的主从复制方式。注意:使用独立的log dump线程是一种异步的方式,可以避免对主库的主体更新流程产生影响,而从库在接收到信息后并不是写入从库的存储中,是写入一个relay log,是避免写入从库实际存储会比较耗时,最终造成从库和主库延迟变长。
    基于主从复制,可以在写入时只写主库,读数据时只读从库,在写请求锁表或锁记录时不会影响到读请求的执行。一主多从的设计可以将读流量分担到多个从库中,能够承担更高的并发读流量。

  1. 主从复制如何访问数据库?
    我们已经使用主从复制的技术将数据复制到了多个节点,也实现了数据库读写的分离,这时,对于数据库的使用方式发生了变化。以前只需要使用一个数据库地址就好了,现在需要使用一个主库地址和多个从库地址,并且需要区分写入操作和查询操作,如果结合“分库分表”,复杂度会提升更多。为了降低实现的复杂度,业界涌现了很多数据库中间件来解决数据库的访问问题,这些中间件可以分为两类。
  • 第一类以淘宝的TDDL( Taobao Distributed Data
    Layer)
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值