mysql数据库架构
❶ 《Mysql性能调优与架构设计》epub下载在线阅读，求百度网盘云资源
《MySQL性能调优与架构设计》（简朝阳）电子书网盘下载免费在线阅读
资源链接：
链接：https://pan..com/s/1jRNyGypVd4gXmV5-fJgA-g
书名：MySQL性能调优与架构设计
作者：简朝阳
豆瓣评分：8.1
出版年份：2009-6
页数：392
内容简介：《MySQL性能调优与架构设计》以 MySQL 数据库的基础及维护为切入点，重点介绍了 MySQL 数据库应用系统的性能调优，以及高可用可扩展的架构设计。
全书共分3篇，基础篇介绍了MySQL软件的基础知识、架构组成、存储引擎、安全管理及基本的备份恢复知识。性能优化篇从影响 MySQL 数据库应用系统性能的因素开始，针对性地对各个影响因素进行调优分析。如 MySQL Schema 设计的技巧，Query 语句的性能优化方式方法及MySQL Server中SQL层和存储引擎层的优化思路。同时还分析了 MySQL 数据库中主要存储引擎的锁定机制。架构设计篇则主要以设计一个高可用可扩展的分布式企业级数据库集群环境为目标，分析介绍了通过 MySQL 实现这一目标的多种架构方式。主要包括可扩展和高可用两部分内容，可扩展部分包括设计原则、Replication 的利用、数据切分、如何使用 Cache 和 Search，以及 NDB Cluster等内容。高可用则主要包括 Dual Master、DRBD、NDB Cluster，以及系统监控等方面。
本书主要面向有一定的 MySQL 基础或至少有一定SQL语言基础的读者朋友。
❷ 扛得住的MySQL数据库架构
数据库优化是系统工程，性能的提升靠整体。本课程将面面俱到的讲解提升数据库性能的各种因素，让你在最短的时间从小白到资深，将数据库整体架构了然于胸
第1章 实例和故事 试看7 节 | 50分钟
决定电商11大促成败的各个关键因素。
收起列表
视频：1-1 什么决定了电商双11大促的成败 (04:04)试看
视频：1-2 在双11大促中的数据库服务器 (06:03)
视频：1-3 在大促中什么影响了数据库性能 (07:55)
视频：1-4 大表带来的问题 (14:13)
视频：1-5 大事务带来的问题 (17:27)
作业：1-6 【讨论题】在日常工作中如何应对高并发大数据量对数据库性能挑战
作业：1-7 【讨论题】在MySQL中事务的作用是什么？
第2章 什么影响了MySQL性能 试看30 节 | 210分钟
详细介绍影响性能各个因素，包括硬件、操作系统等等。
收起列表
视频：2-1 影响性能的几个方面 (04:08)试看
视频：2-2 CPU资源和可用内存大小 (10:54)
视频：2-3 磁盘的配置和选择 (04:44)
视频：2-4 使用RAID增加传统机器硬盘的性能 (11:30)
视频：2-5 使用固态存储SSD或PCIe卡 (08:35)
视频：2-6 使用网络存储SAN和NAS (07:16)
视频：2-7 总结：服务器硬件对性能的影响 (03:27)
视频：2-8 操作系统对性能的影响-MySQL适合的操作系统 (03:50)
视频：2-9 CentOS系统参数优化 (11:43)
视频：2-10 文件系统对性能的影响 (03:29)
视频：2-11 MySQL体系结构 (05:29)
视频：2-12 MySQL常用存储引擎之MyISAM (13:23)
视频：2-13 MySQL常用存储引擎之Innodb (10:44)
视频：2-14 Innodb存储引擎的特性(1) (15:24)
视频：2-15 Innodb存储引擎的特性(2) (08:44)
视频：2-16 MySQL常用存储引擎之CSV (09:19)
视频：2-17 MySQL常用存储引擎之Archive (06:08)
视频：2-18 MySQL常用存储引擎之Memory (10:40)
视频：2-19 MySQL常用存储引擎之Federated (11:21)
视频：2-20 如何选择存储引擎 (04:33)
视频：2-21 MySQL服务器参数介绍 (08:04)
视频：2-22 内存配置相关参数 (09:24)
视频：2-23 IO相关配置参数 (10:01)
视频：2-24 安全相关配置参数 (06:13)
视频：2-25 其它常用配置参数 (03:41)
视频：2-26 数据库设计对性能的影响 (04:36)
视频：2-27 总结 (01:32)
作业：2-28 【讨论题】你会如何配置公司的数据库服务器硬件？
作业：2-29 【讨论题】你认为对数据库性能影响最大的因素是什么
作业：2-30 【讨论题】做为电商的DBA，建议开发选哪种MySQL存储引擎
第3章 MySQL基准测试8 节 | 65分钟
了解基准测试,MySQL基准测试工具介绍及实例演示。
收起列表
视频：3-1 什么是基准测试 (02:20)
视频：3-2 如何进行基准测试 (09:00)
视频：3-3 基准测试演示实例 (11:18)
视频：3-4 Mysql基准测试工具之mysqlslap (13:30)
视频：3-5 Mysql基准测试工具之sysbench (11:07)
视频：3-6 sysbench基准测试演示实例 (17:11)
作业：3-7 【讨论题】MySQL基准测试是否可以体现出业务系统的真实性能
作业：3-8 【实操题】参数不同取值对性能的影响
第4章 MySQL数据库结构优化14 节 | 85分钟
详细介绍数据库结构设计、范式和反范式设计、物理设计等等。
收起列表
视频：4-1 数据库结构优化介绍 (06:52)
视频：4-2 数据库结构设计 (14:49)
视频：4-3 需求分析及逻辑设计 (11:00)
视频：4-4 需求分析及逻辑设计-反范式化设计 (06:44)
视频：4-5 范式化设计和反范式化设计优缺点 (04:06)
视频：4-6 物理设计介绍 (05:17)
视频：4-7 物理设计-数据类型的选择 (18:59)
视频：4-8 物理设计-如何存储日期类型 (13:37)
视频：4-9 物理设计-总结 (02:37)
图文：4-10 说明MyISAM和Innodb存储引擎的5点不同
作业：4-11 【讨论题】判断表结构是否符合第三范式要求?如不满足要如何修改
作业：4-12 【实操题】请设计一个电商订单系统的数据库结构
作业：4-13 【讨论题】以下那个字段适合作为Innodb表的主建使用
作业：4-14 【讨论题】请为下表中的字段选择合适的数据类型
第5章 MySQL高可用架构设计 试看24 节 | 249分钟
详细介绍二进制日志及其对复制的影响、GTID的复制、MMM、MHA等等。
收起列表
视频：5-1 mysql复制功能介绍 (04:58)
视频：5-2 mysql二进制日志 (22:05)
视频：5-3 mysql二进制日志格式对复制的影响 (09:37)
视频：5-4 mysql复制工作方式 (03:08)
视频：5-5 基于日志点的复制 (20:06)
视频：5-6 基于GTID的复制 (22:32)
视频：5-7 MySQL复制拓扑 (13:58)
视频：5-8 MySQL复制性能优化 (09:23)
视频：5-9 MySQL复制常见问题处理 (08:31)
视频：5-10 什么是高可用架构 (14:09)
视频：5-11 MMM架构介绍 (08:09)
视频：5-12 MMM架构实例演示（上） (09:16)试看
视频：5-13 MMM架构实例演示（下） (18:55)
视频：5-14 MMM架构的优缺点 (08:01)
视频：5-15 MHA架构介绍 (10:02)
视频：5-16 MHA架构实例演示(1) (13:11)
视频：5-17 MHA架构实例演示(2) (16:54)
视频：5-18 MHA架构优缺点 (05:14)
视频：5-19 读写分离和负载均衡介绍 (11:42)
视频：5-20 MaxScale实例演示 (18:25)
作业：5-21 【讨论题】MySQL主从复制为什么会有延迟，延迟又是如何产生
作业：5-22 【实操题】请为某互联网项目设计99.99%MySQL架构
作业：5-23 【讨论题】如何给一个已经存在的主从复制集群新增一个从节点
作业：5-24 【讨论题】给你三台数据库服务器，你如何设计它的高可用架构
第6章 数据库索引优化8 节 | 65分钟
介绍BTree索引和Hash索引，详细介绍索引的优化策略等等。
收起列表
视频：6-1 Btree索引和Hash索引 (20:09)
视频：6-2 安装演示数据库 (01:19)
视频：6-3 索引优化策略（上） (17:33)
视频：6-4 索引优化策略（中） (13:02)
视频：6-5 索引优化策略（下） (12:30)
作业：6-6 【讨论题】一列上建立了索引，查询时就一定会用到这个索引吗
作业：6-7 【讨论题】在定义联合索引时为什么需要注意联合索引中的顺序
作业：6-8 【实操题】SQL建立索引，你会考虑那些因素
第7章 SQL查询优化9 节 | 62分钟
详细介绍慢查询日志及示例演示,MySQL查询优化器介绍及特定SQL的查询优化等。
收起列表
视频：7-1 获取有性能问题SQL的三种方法 (05:14)
视频：7-2 慢查询日志介绍 (08:57)
视频：7-3 慢查询日志实例 (08:27)
视频：7-4 实时获取性能问题SQL (02:21)
视频：7-5 SQL的解析预处理及生成执行计划 (16:02)
视频：7-6 如何确定查询处理各个阶段所消耗的时间 (09:35)
视频：7-7 特定SQL的查询优化 (10:34)
作业：7-8 【讨论题】如何跟据需要对一个大表中的数据进行删除或更新
作业：7-9 【讨论题】如何获取需要优化的SQL查询
第8章 数据库的分库分表5 节 | 48分钟
详细介绍数据库分库分表的实现原理及演示案例等。
收起列表
视频：8-1 数据库分库分表的几种方式 (04:34)
视频：8-2 数据库分片前的准备 (13:53)
视频：8-3 数据库分片演示(上) (11:40)
视频：8-4 数据库分片演示(下) (17:02)
作业：8-5 【讨论题】对于大表来说我们一定要进行分库分表吗
第9章 数据库监控7 节 | 29分钟
介绍数据库可用性监控、性能监控、MySQL主从复制监控等
收起列表
视频：9-1 数据库监控介绍 (04:46)
视频：9-2 数据库可用性监控 (07:20)
视频：9-3 数据库性能监控 (09:39)
视频：9-4 MySQL主从复制监控 (06:16)
作业：9-5 【讨论题】QPS是否可以真实的反映出数据库的负载情况
作业：9-6 【讨论题】如何正确评估数据库的当前负载状况
作业：9-7 【实操题】开发一个简单监控脚本，监控mySQL数据库阻塞情况
❸ 五大常见的MySQL高可用方案(最全)
1. 概述
我们在考虑MySQL数据库的高可用的架构时，主要要考虑如下几方面：
如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。
用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。
当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。
关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。
2. 高可用方案
2.1. 主从或主主半同步复制
使用双节点数据库，搭建单向或者双向的半同步复制。在5.7以后的版本中，由于lossless replication、logical多线程复制等一些列新特性的引入，使得MySQL原生半同步复制更加可靠。
常见架构如下：
通常会和proxy、keepalived等第三方软件同时使用，即可以用来监控数据库的 健康 ，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。
优点：
架构比较简单，使用原生半同步复制作为数据同步的依据；
双节点，没有主机宕机后的选主问题，直接切换即可；
双节点，需求资源少，部署简单；
缺点：
完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证；
需要额外考虑haproxy、keepalived的高可用机制。
2.2. 半同步复制优化
半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。
该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。
可参考的优化方案如下：
2.2.1. 双通道复制
半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。
2.2.2. binlog文件服务器
搭建两条半同步复制通道，其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。
优点：
双节点，需求资源少，部署简单；
架构简单，没有选主的问题，直接切换即可;
相比于原生复制，优化后的半同步复制更能保证数据的一致性。
缺点：
需要修改内核源码或者使用mysql通信协议。需要对源码有一定的了解，并能做一定程度的二次开发。
依旧依赖于半同步复制，没有从根本上解决数据一致性问题。
2.3. 高可用架构优化
将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。
由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。
但是由于数据库数量较多，所以需要数据库管理软件来保证数据库的可维护性。可以选择MMM、MHA或者各个版本的proxy等等。常见方案如下：
2.3.1. MHA+多节点集群
MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。
MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。
MHA也可以扩展到如下的多节点集群：
优点：
可以进行故障的自动检测和转移;
可扩展性较好，可以根据需要扩展MySQL的节点数量和结构;
相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低
缺点：
至少需要三节点，相对于双节点需要更多的资源;
逻辑较为复杂，发生故障后排查问题，定位问题更加困难;
数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险;
可能因为网络分区发生脑裂现象;
2.3.2. zookeeper+proxy
Zookeeper使用分布式算法保证集群数据的一致性，使用zookeeper可以有效的保证proxy的高可用性，可以较好的避免网络分区现象的产生。
优点：
较好的保证了整个系统的高可用性，包括proxy、MySQL;
扩展性较好，可以扩展为大规模集群;
缺点：
数据一致性仍然依赖于原生的mysql半同步复制;
引入zk，整个系统的逻辑变得更加复杂;
2.4. 共享存储
共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。
2.4.1. SAN共享储存
SAN的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与LAN相比）连接，通过这种连接实现数据的集中式存储。常用架构如下：
使用共享存储时，MySQL服务器能够正常挂载文件系统并操作，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。
优点：
两节点即可，部署简单，切换逻辑简单；
很好的保证数据的强一致性；
不会因为MySQL的逻辑错误发生数据不一致的情况；
缺点：
需要考虑共享存储的高可用；
价格昂贵；
2.4.2. DRBD磁盘复制
DRBD是一种基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像，当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据就可以保证实时同步。常用架构如下：
当本地主机出现问题，远程主机上还保留着一份相同的数据，可以继续使用，保证了数据的安全。
DRBD是linux内核模块实现的快级别的同步复制技术，可以与SAN达到相同的共享存储效果。
优点：
两节点即可，部署简单，切换逻辑简单；
相比于SAN储存网络，价格低廉；
保证数据的强一致性；
缺点：
对io性能影响较大；
从库不提供读操作；
2.5. 分布式协议
分布式协议可以很好解决数据一致性问题。比较常见的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。
优点：
全部使用官方组件，不依赖于第三方软件；
可以实现数据的强一致性；
缺点：
国内使用的较少；
配置较复杂，需要使用NDB储存引擎，与MySQL常规引擎存在一定差异；
至少三节点；
2.5.2. Galera
基于Galera的MySQL高可用集群， 是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。常见架构如下：
优点：
多主写入，无延迟复制，能保证数据强一致性；
有成熟的社区，有互联网公司在大规模的使用；
自动故障转移，自动添加、剔除节点；
缺点：
需要为原生MySQL节点打wsrep补丁
只支持innodb储存引擎
至少三节点；
2.5.3. POAXS
Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。常见架构如下：
优点：
多主写入，无延迟复制，能保证数据强一致性；
有成熟理论基础；
自动故障转移，自动添加、剔除节点；
缺点：
只支持innodb储存引擎
至少三节点；
3. 总结
随着人们对数据一致性的要求不断的提高，越来越多的方法被尝试用来解决分布式数据一致性的问题，如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等。
而使用分布式算法用来解决MySQL数据库数据一致性的问题的方法，也越来越被人们所接受，一系列成熟的产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越来越多的被大规模使用。
随着官方MySQL Group Replication的GA，使用分布式协议来解决数据一致性问题已经成为了主流的方向。期望越来越多优秀的解决方案被提出，MySQL高可用问题可以被更好的解决。
❹ mysql数据库管理系统基本系统架构拥有哪4大模块
客户端、连接层、服务层、引擎层
❺ mysql有哪些架构
了解MySql必须牢牢记住其体系结构图，Mysql是由SQL接口，解析器，优化器，缓存，存储引擎组成的
1 Connectors指的是不同语言中与SQL的交互
2 Management Serveices & Utilities： 系统管理和控制工具
3 Connection Pool: 连接池。
管理缓冲用户连接，线程处理等需要缓存的需求
4 SQL Interface: SQL接口。
接受用户的SQL命令，并且返回用户需要查询的结果。比如select from就是调用SQL Interface
5 Parser: 解析器。
SQL命令传递到解析器的时候会被解析器验证和解析。解析器是由Lex和YACC实现的，是一个很长的脚本。
主要功能：
a . 将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的
b. 如果在分解构成中遇到错误，那么就说明这个sql语句是不合理的
6 Optimizer: 查询优化器。
SQL语句在查询之前会使用查询优化器对查询进行优化。他使用的是“选取-投影-联接”策略进行查询。
用一个例子就可以理解： select uid,name from user where gender = 1;
这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后再进行gender过滤
这个select查询先根据uid和name进行属性投影，而不是将属性全部取出以后再进行过滤
将这两个查询条件联接起来生成最终查询结果
7 Cache和Buffer： 查询缓存。
如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。
这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等
8 Engine ：存储引擎。
存储引擎是MySql中具体的与文件打交道的子系统。也是Mysql最具有特色的一个地方。
Mysql的存储引擎是插件式的。它根据MySql AB公司提供的文件访问层的一个抽象接口来定制一种文件访问机制（这种访问机制就叫存储引擎）
现在有很多种存储引擎，各个存储引擎的优势各不一样，最常用的MyISAM,InnoDB,BDB
默认下MySql是使用MyISAM引擎，它查询速度快，有较好的索引优化和数据压缩技术。但是它不支持事务。
InnoDB支持事务，并且提供行级的锁定，应用也相当广泛。Mysql也支持自己定制存储引擎，甚至一个库中不同的表使用不同的存储引擎，这些都是允许的。
❻ MySQL数据库的介绍
视频讲解了mysql数据库的概念，同时也讲到了数据库系统、数据库管理系统、表、记录等术语以及了解了一下mysql的体系架构。本视频是学习数据库的零基础视频，是学习以后大数据的基础。
❼ 写入mysql数据库的数据量很大，数据库架构该怎么去设计
1.设置读写分离
2.进行分库分表，用中间件路由，分摊流量
3.可以先写入mq，然后慢慢写入
4.可以使用tidb，tps很高
❽ mysql数据库
MySQL数据库一般指MySQL，MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发。
mysql是目前网站以及APP应用上用得较多的一个开源的关系型数据库系统，可以对数据进行保存，分段化的数据保存，也可以对其数据进行检索，查询等功能的数据库。
默认的mysql数据库中存有一个库这个就是mysql的系统数据库，可以对其保存系统的数据包括mysql数据库的信息，数据库root账号，普通账号，以及数据库的名称，还有数据库的一些表还有一些数字型的数据类型结构都会有所保存。
mysql数据库的优点
（1）MySQL数据库是用C和C++语言编写的，并且使用了多种编辑器进行测试，以保证源码的可移植性。
（2）支持多个操作系统例如：Windows、Linux、Mac OS等等。
（3）支持多线程，可以充分的利用CPU资源。
（4）为多种编程语言提供API，包括C语言、Java、PHP、Python语言等。
（5）MySQL优化了SQL算法，有效的提高了查询速度。
（6）MySQL内提供了用于管理，检查以及优化数据库操作的管理工具。
（7）它能够作为一个单独的应用程序应用在客户端服务器网络环境中，也可以作为一个库嵌入到其他的软件中并提供多种语言支持。
❾ 数据库架构选型与落地，看这篇就够了
随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。
因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。
以下，我从数据库架构、选型与落地来让大家入门。
数据库会面临什么样的挑战呢？
业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。
为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。
将数据库的写操作和读操作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。
这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读操作的场景。
因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；
优点：
缺点：
在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。
优点：
缺点：
在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。
这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。
但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈（单个服务器的IO有上限）。
所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。
优点：
缺点：
四、分库分表
在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。
所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。
分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。
优点：
缺点：
注：分库还是分表核心关键是有没有IO瓶颈 。
分片方式都有什么呢？
RANGE（范围分片）
将业务表中的某个 关键字段排序 后，按照顺序从0到10000一个表，10001到20000一个表。最常见的就是 按照时间切分 （月表、年表）。
比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。
优点：
缺点：
HASH（哈希分片）
将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。
优点：
缺点：
讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。
那么，我们应该如何选择数据库架构呢？
虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。
混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。
1、对事务支持
分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。
2、多库结果集合并 （group by，order by）
由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等操作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。
3、数据延迟
主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。
4、跨库join
分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。
5、分片扩容
水平分片之后，一旦需要做扩容时。需要将对应的数据做一次迁移，成本代价都极高的。
6、ID生成
分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。
一、应用层依赖类（JDBC）
这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。
此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等操作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。
中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。
优点
缺点
二、中间层代理类（Proxy）
这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。
所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。
在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是Http协议请求。
比较有代表性的产品有开创性质的Amoeba、阿里开源的Cobar、社区发展比较好的 Mycat （基于Cobar开发）等。
优点
缺点
JDBC方案 ：无中心化架构，兼容市面上大多数关系型数据库，适用于开发高性能的轻量级 OLTP 应用（面向前台）。
Proxy方案 ：提供静态入口以及异构语言的支持，适用于 OLAP 应用（面向后台）以及对分片数据库进行管理和运维的场景。
混合方案 ：在大型复杂系统中存在面向C端用户的前台应用，也有面向企业分析的后台应用，这个时候就可以采用混合模式。
JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。
ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （计划中）这3款相互独立的产品组成，他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
ShardingSphere提供的核心功能：
Sharding-Proxy
定位为透明化的 数据库代理端 ，提供封装了 数据库二进制协议的服务端版本 ，用于完成对 异构语言的支持 。
目前已提供MySQL版本，它可以使用 任何兼容MySQL协议的访问客户端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作数据，对DBA更加友好。
向 应用程序完全透明 ，可直接当做MySQL使用。
适用于任何兼容MySQL协议的客户端。
Sharding-JDBC
定位为 轻量级Java框架 ，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为 增强版的JDBC驱动，完全兼容JDBC和各种ORM框架 。
以电商SaaS系统为例，前台应用采用Sharding-JDBC，根据业务场景的差异主要分为三种方案。
分库（用户）
问题解析：头部企业日活高并发高，单独分库避免干扰其他企业用户，用户数据的增长缓慢可以不分表。
拆分维度：企业ID分库
拆分策略：头部企业单独库、非头部企业一个库
分库分表（订单）
问题解析：订单数据增长速度较快，在分库之余需要分表。
拆分维度：企业ID分库、用户ID分表
拆分策略：头部企业单独库、非头部企业一个库，分库之后用户ID取模拆分表
单库分表（附件）
问题解析：附件数据特点是并发量不大，只需要解决数据增长问题，所以单库IO足以支撑的情况下分表即可。
拆分维度：用户ID分表
拆分策略：用户ID取模分表
问题一：分布式事务
分布式事务过于复杂也是分布式系统最难处理的问题，由于篇幅有限，后续会开篇专讲这一块内容。
问题二：分布式ID
问题三：跨片查询
举个例子，以用户id分片之后，需要根据企业id查询企业所有用户信息。
sharding针对跨片查询也是能够支持的，本质上sharding的跨片查询是采用同时查询多个分片的数据，然后聚合结果返回，这个方式对资源耗费比较大，特别是对数据库连接资源的消耗。
假设分4个数据库，8个表，则sharding会同时发出32个SQL去查询。一下子消耗掉了32个连接；
特别是针对单库分表的情况要注意，假设单库分64个表，则要消耗64个连接。如果我们部署了2个节点，这个时候两个节点同时查询的话，就会遇到数据库连接数上限问题（mysql默认100连接数）
问题四：分片扩容
随着数据增长，每个片区的数据也会达到瓶颈，这个时候需要将原有的分片数量进行增加。由于增加了片区，原先的hash规则也跟着变化，造成了需要将旧数据做迁移。
假设原先1个亿的数据，hash分64个表，现在增长到50亿的数据，需要扩容到128个表，一旦扩容就需要将这50亿的数据做一次迁移，迁移成本是无法想象的。
问题五：一致性哈希
首先，求出每个 服务器的hash值 ，将其配置到一个 0~2^n 的圆环上 （n通常取32）
其次，用同样的方法求出待 存储对象的主键 hash值 ，也将其配置到这个圆环上。
然后，从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。
一致性hash的优点在于加入和删除节点时只会影响到在哈希环中相邻的节点，而对其他节点没有影响。
所以使用一致性哈希在集群扩容过程中可以减少数据的迁移。
好了，这次分享到这里，我们日常的实践可能只会用到其中一种方案，但它不是数据库架构的全貌，打开技术视野，才能更好地把存储工具利用起来。
老规矩，一键三连，日入两千，点赞在看，年薪百万！
本文作者：Jensen
7年Java老兵，小米主题设计师，手机输入法设计师，ProcessOn特邀讲师。
曾涉猎航空、电信、IoT、垂直电商产品研发，现就职于某知名电商企业。
技术公众号 【架构师修行录】 号主，专注于分享日常架构、技术、职场干货，Java Goals：架构师。
交个朋友，一起成长！
❿ 《深入浅出MySQL数据库开发优化与管理维护第3版》pdf下载在线阅读全文，求百度网盘云资源
《深入浅出MySQL数据库开发优化与管理维护第3版》网络网盘pdf最新全集下载:
链接：https://pan..com/s/1AxoktD-VngFdL1vsIBS_mw
简介：《深入浅出MySQL：数据库开发、优化与管理维护（第3版）》源自网易公司多位资深数据库专家数年的经验总结和MySQL数据库的使用心得，在之前版本的基础之上，基于MySQL 5.7版本进行了内容升级，同时也对MySQL 8.0的重要功能进行了介绍。除了对原有内容的更新之外，本书还新增了作者在高可用架构、数据库自动化运维，以及数据库中间件方面的实践和积累。
《深入浅出MySQL：数据库开发、优化与管理维护（第3版）》分为“基础篇”“开发篇”“优化篇”“管理维护篇”和“架构篇”5个部分，共32章。基础篇面向MySQL的初学者，介绍了MySQL的安装与配置、SQL基础、MySQL支持的数据类型、MySQL中的运算符、常用函数等内容。开发篇面向的是MySQL设计和开发人员，内容涵盖了表类型（存储引擎）的选择、选择合适的数据类型、字符集、索引的设计和使用、开发常用数据库对象、事务控制和锁定语句、SQL中的安全问题、SQL Mode及相关问题、MySQL分区等。优化篇针对的是开发人员和数据库管理人员，内容包括SQL优化、锁问题、优化MySQL Server、磁盘I/O问题、应用优化、PS/SYS数据库、故障诊断等内容。管理维护篇适合数据库管理员阅读，介绍了MySQL高级安装和升级、MySQL中的常用工具、MySQL日志、备份与恢复、MySQL权限与安全、MySQL监控、MySQL常见问题和应用技巧、自动化运维系统的开发等内容。架构篇主要面向高级数据库管理人员和数据库架构设计师，内容包括MySQL复制、高可用架构、MySQL中间件等内容。