体系结构的概念
任何一套系统当中，每个部件都能起到一定的作用！
MySQL的体系结构
体系结构详解
客户端连接
支持接口：支持的客户端连接，例如C、Java、PHP等语言来连接MySQL数据库
第一层：网络连接层
连接池：管理、缓冲用户的连接，线程处理等需要缓存的需求。
例如：当客户端发送一个请求连接，会从连接池中获取一个连接进行使用。
第二层：核心服务层
管理服务和工具：系统的管理和控制工具，例如备份恢复、复制、集群等。
SQL接口：接受SQL命令，并且返回查询结果。
查询解析器：验证和解析SQL命令，例如过滤条件、语法结构等。
查询优化器：在执行查询之前，使用默认的一套优化机制进行优化sql语句
缓存：如果缓存当中有想查询的数据，则直接将缓存中的数据返回。没有的话再重新查询！
第三层：存储引擎层
插件式存储引擎：管理和操作数据的一种机制，包括(存储数据、如何更新、查询数据等)
第四层：系统文件层
文件系统：配置文件、数据文件、日志文件、错误文件、二进制文件等等的保存
引擎的概念
生活中，引擎就是整个机器运行的核心，不同的引擎具备不同的功能。
MySQL存储引擎的概念
MySQL数据库使用不同的机制存取表文件 , 机制的差别在于不同的存储方式、索引技巧、锁定水平以及广泛的不同的功能和能力，在MySQL中 , 将这些不同的技术及配套的功能称为存储引擎
在关系型数据库中数据的存储是以表的形式存进行储的，所以存储引擎也可以称为表类型（即存储和操作此表的类型）。
Oracle , SqlServer等数据库只有一种存储引擎 , 而MySQL针对不同的需求, 配置MySQL的不同的存储引擎 , 就会让数据库采取了不同的处理数据的方式和扩展功能。
通过选择不同的引擎 ,能够获取最佳的方案 , 也能够获得额外的速度或者功能，提高程序的整体效果。所以了解引擎的特性 , 才能贴合我们的需求 , 更好的发挥数据库的性能。
MySQL支持的存储引擎
MySQL5.7支持的引擎包括：InnoDB、MyISAM、MEMORY、Archive、Federate、CSV、BLACKHOLE等
其中较为常用的有三种：InnoDB、MyISAM、MEMORY
常用的存储引擎
MyISAM存储引擎
访问快,不支持事务和外键。表结构保存在.frm文件中，表数据保存在.MYD文件中，索引保存在.MYI文件中。
InnoDB存储引擎(MySQL5.5版本后默认的存储引擎)
支持事务 ,占用磁盘空间大 ,支持并发控制。表结构保存在.frm文件中，如果是共享表空间，数据和索引保存在 innodb_data_home_dir 和 innodb_data_file_path定义的表空间中，可以是多个文件。如果是多表空间存储，每个表的数据和索引单独保存在 .ibd 中。
MEMORY存储引擎
内存存储 , 速度快 ,不安全 ,适合小量快速访问的数据。表结构保存在.frm中。
特性对比
特性
MyISAM
InnoDB
MEMORY
存储限制
有(平台对文件系统大小的限制)
64TB
有(平台的内存限制)
事务安全
不支持
支持
锁机制
表锁
表锁/行锁
B+Tree索引
哈希索引
全文索引
集群索引
数据索引
数据缓存
N/A
索引缓存
数据可压缩
空间使用
低
高
内存使用
中等
批量插入速度
外键
查询数据库支持的引擎
查询某个数据库中所有数据表的引擎
查询某个数据库中某个数据表的引擎
创建数据表，指定存储引擎
修改表的存储引擎
MyISAM ：由于MyISAM不支持事务、不支持外键、支持全文检索和表级锁定，读写相互阻塞，读取速度快，节约资源，所以如果应用是以查询操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的。
InnoDB : 是MySQL的默认存储引擎， 由于InnoDB支持事务、支持外键、行级锁定 ，支持所有辅助索引(5.5.5后不支持全文检索)，高缓存，所以用于对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，读写频繁的操作，那么InnoDB存储引擎是比较合适的选择，比如BBS、计费系统、充值转账等
MEMORY：将所有数据保存在RAM中，在需要快速定位记录和其他类似数据环境下，可以提供更快的访问。MEMORY的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，其次是要确保表的数据可以恢复，数据库异常终止后表中的数据是可以恢复的。MEMORY表通常用于更新不太频繁的小表，用以快速得到访问结果。
总结：针对不同的需求场景，来选择最适合的存储引擎即可！如果不确定、则使用数据库默认的存储引擎！
我们之前学习过集合，其中的ArrayList集合的特点之一就是有索引。那么有索引会带来哪些好处呢？
没错，查询数据快！我们可以通过索引来快速查找到想要的数据。那么对于我们的MySQL数据库中的索引功能也是类似的！
MySQL数据库中的索引：是帮助MySQL高效获取数据的一种数据结构！所以，索引的本质就是数据结构。
在表数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式指向数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。
一张数据表，用于保存数据。 一个索引配置文件，用于保存索引，每个索引都去指向了某一个数据(表格演示)
举例，无索引和有索引的查找原理
功能分类
普通索引： 最基本的索引，它没有任何限制。
唯一索引：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值组合必须唯一。
主键索引：一种特殊的唯一索引，不允许有空值。一般在建表时同时创建主键索引。
组合索引：顾名思义，就是将单列索引进行组合。
外键索引：只有InnoDB引擎支持外键索引，用来保证数据的一致性、完整性和实现级联操作。
全文索引：快速匹配全部文档的方式。InnoDB引擎5.6版本后才支持全文索引。MEMORY引擎不支持。
结构分类
B+Tree索引 ：MySQL使用最频繁的一个索引数据结构，是InnoDB和MyISAM存储引擎默认的索引类型。
Hash索引 : MySQL中Memory存储引擎默认支持的索引类型。
数据准备
创建索引
注意：如果一个表中有一列是主键，那么就会默认为其创建主键索引！(主键列不需要单独创建索引)
查看索引
alter语句添加索引
删除索引
索引是在MySQL的存储引擎中实现的，所以每种存储引擎的索引不一定完全相同，也不是所有的引擎支持所有的索引类型。这里我们主要介绍InnoDB引擎的实现的B+Tree索引。
B+Tree是一种树型数据结构，是B-Tree的变种。通常使用在数据库和操作系统中的文件系统，特点是能够保持数据稳定有序。我们逐步的来了解一下。
系统从磁盘读取数据到内存时是以磁盘块（block）为基本单位的
位于同一个磁盘块中的数据会被一次性读取出来，而不是需要什么取什么。
InnoDB存储引擎中有页（Page）的概念，页是其磁盘管理的最小单位。InnoDB存储引擎中默认每个页的大小为16KB。
InnoDB引擎将若干个地址连接磁盘块，以此来达到页的大小16KB，在查询数据时如果一个页中的每条数据都能有助于定位数据记录的位置，这将会减少磁盘I/O次数，提高查询效率。
BTree结构的数据可以让系统高效的找到数据所在的磁盘块。为了描述BTree，首先定义一条记录为一个二元组[key, data] ，key为记录的键值，对应表中的主键值，data为一行记录中除主键外的数据。对于不同的记录，key值互不相同。BTree中的每个节点根据实际情况可以包含大量的关键字信息和分支，如下图所示为一个3阶的BTree：
根据图中结构显示，每个节点占用一个盘块的磁盘空间，一个节点上有两个升序排序的关键字和三个指向子树根节点的指针，指针存储的是子节点所在磁盘块的地址。两个关键词划分成的三个范围域对应三个指针指向的子树的数据的范围域。以根节点为例，关键字为17和35，P1指针指向的子树的数据范围为小于17，P2指针指向的子树的数据范围为17~35，P3指针指向的子树的数据范围为大于35。
查找顺序：
B+Tree是在BTree基础上的一种优化，使其更适合实现外存储索引结构，InnoDB存储引擎就是用B+Tree实现其索引结构。
从上一节中的BTree结构图中可以看到每个节点中不仅包含数据的key值，还有data值。而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。
B+Tree相对于BTree区别：
非叶子节点只存储键值信息。
所有叶子节点之间都有一个连接指针。
数据记录都存放在叶子节点中。
将上一节中的BTree优化，由于B+Tree的非叶子节点只存储键值信息，假设每个磁盘块能存储4个键值及指针信息，则变成B+Tree后其结构如下图所示：
通常在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。因此可以对B+Tree进行两种查找运算：
【有范围】对于主键的范围查找和分页查找
【有顺序】从根节点开始，进行随机查找
实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree的高度一般都在24层。MySQL的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要13次磁盘I/O操作。
索引的设计可以遵循一些已有的原则，创建索引的时候请尽量考虑符合这些原则，便于提升索引的使用效率，更高效的使用索引。
创建索引时的原则
对查询频次较高，且数据量比较大的表建立索引。
使用唯一索引，区分度越高，使用索引的效率越高。
索引字段的选择，最佳候选列应当从where子句的条件中提取，如果where子句中的组合比较多，那么应当挑选最常用、过滤效果最好的列的组合。
使用短索引，索引创建之后也是使用硬盘来存储的，因此提升索引访问的I/O效率，也可以提升总体的访问效率。假如构成索引的字段总长度比较短，那么在给定大小的存储块内可以存储更多的索引值，相应的可以有效的提升MySQL访问索引的I/O效率。
索引可以有效的提升查询数据的效率，但索引数量不是多多益善，索引越多，维护索引的代价自然也就水涨船高。对于插入、更新、删除等DML操作比较频繁的表来说，索引过多，会引入相当高的维护代价，降低DML操作的效率，增加相应操作的时间消耗。另外索引过多的话，MySQL也会犯选择困难病，虽然最终仍然会找到一个可用的索引，但无疑提高了选择的代价。
联合索引的特点
在mysql建立联合索引时会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配，
对列name列、address和列phone列建一个联合索引
联合索引index_three实际建立了(name)、(name,address)、(name,address,phone)三个索引。所以下面的三个SQL语句都可以命中索引。
上面三个查询语句执行时会依照最左前缀匹配原则，检索时分别会使用索引
进行数据匹配。
索引的字段可以是任意顺序的，如：
Mysql的优化器会帮助我们调整where条件中的顺序，以匹配我们建立的索引。
联合索引中最左边的列不包含在条件查询中，所以根据上面的原则，下面的SQL语句就不会命中索引。
之前我们学习过多线程，多线程当中如果想保证数据的准确性是如何实现的呢？没错，通过同步实现。同步就相当于是加锁。加了锁以后有什么好处呢？当一个线程真正在操作数据的时候，其他线程只能等待。当一个线程执行完毕后，释放锁。其他线程才能进行操作！
那么我们的MySQL数据库中的锁的功能也是类似的。在我们学习事务的时候，讲解过事务的隔离性，可能会出现脏读、不可重复读、幻读的问题，当时我们的解决方式是通过修改事务的隔离级别来控制，但是数据库的隔离级别呢我们并不推荐修改。所以，锁的作用也可以解决掉之前的问题！
锁机制 : 数据库为了保证数据的一致性，而使用各种共享的资源在被并发访问时变得有序所设计的一种规则。
举例，在电商网站购买商品时，商品表中只存有1个商品，而此时又有两个人同时购买，那么谁能买到就是一个关键的问题。
这里会用到事务进行一系列的操作：
先从商品表中取出物品的数据
然后插入订单
付款后，再插入付款表信息
更新商品表中商品的数量
以上过程中，使用锁可以对商品数量数据信息进行保护，实现隔离，即只允许第一位用户完成整套购买流程，而其他用户只能等待，这样就解决了并发中的矛盾问题。
在数据库中，数据是一种供许多用户共享访问的资源，如何保证数据并发访问的一致性、有效性，是所有数据库必须解决的一个问题，MySQL由于自身架构的特点，在不同的存储引擎中，都设计了面对特定场景的锁定机制，所以引擎的差别，导致锁机制也是有很大差别的。
按操作分类：
共享锁：也叫读锁。针对同一份数据，多个事务读取操作可以同时加锁而不互相影响 ，但是不能修改数据记录。
排他锁：也叫写锁。当前的操作没有完成前,会阻断其他操作的读取和写入
按粒度分类：
表级锁：操作时，会锁定整个表。开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低。偏向于MyISAM存储引擎！
行级锁：操作时，会锁定当前操作行。开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高。偏向于InnoDB存储引擎！
页级锁：锁的粒度、发生冲突的概率和加锁的开销介于表锁和行锁之间，会出现死锁，并发性能一般。
按使用方式分类：
悲观锁：每次查询数据时都认为别人会修改，很悲观，所以查询时加锁。
乐观锁：每次查询数据时都认为别人不会修改，很乐观，但是更新时会判断一下在此期间别人有没有去更新这个数据
不同存储引擎支持的锁
存储引擎
表级锁
行级锁
页级锁
BDB
共享锁
排他锁
注意：锁的兼容性
共享锁和共享锁 兼容
共享锁和排他锁 冲突
排他锁和排他锁 冲突
排他锁和共享锁 冲突
读锁
写锁
悲观锁的概念
就是很悲观，它对于数据被外界修改的操作持保守态度，认为数据随时会修改。
整个数据处理中需要将数据加锁。悲观锁一般都是依靠关系型数据库提供的锁机制。
我们之前所学的行锁，表锁不论是读写锁都是悲观锁。
乐观锁的概念
就是很乐观，每次自己操作数据的时候认为没有人会来修改它，所以不去加锁。
但是在更新的时候会去判断在此期间数据有没有被修改。
需要用户自己去实现，不会发生并发抢占资源，只有在提交操作的时候检查是否违反数据完整性。
悲观锁和乐观锁使用前提
对于读的操作远多于写的操作的时候，这时候一个更新操作加锁会阻塞所有的读取操作，降低了吞吐量。最后还要释放锁，锁是需要一些开销的，这时候可以选择乐观锁。
如果是读写比例差距不是非常大或者系统没有响应不及时，吞吐量瓶颈的问题，那就不要去使用乐观锁，它增加了复杂度，也带来了业务额外的风险。这时候可以选择悲观锁。
乐观锁的实现方式
版本号
给数据表中添加一个version列，每次更新后都将这个列的值加1。
读取数据时，将版本号读取出来，在执行更新的时候，比较版本号。
如果相同则执行更新，如果不相同，说明此条数据已经发生了变化。
用户自行根据这个通知来决定怎么处理，比如重新开始一遍，或者放弃本次更新。
时间戳
和版本号方式基本一样，给数据表中添加一个列，名称无所谓，数据类型需要是timestamp
每次更新后都将最新时间插入到此列。
读取数据时，将时间读取出来，在执行更新的时候，比较时间。
表锁和行锁
行锁：锁的粒度更细，加行锁的性能损耗较大。并发处理能力较高。InnoDB引擎默认支持！
表锁：锁的粒度较粗，加表锁的性能损耗较小。并发处理能力较低。InnoDB、MyISAM引擎支持！
InnoDB锁优化建议
尽量通过带索引的列来完成数据查询，从而避免InnoDB无法加行锁而升级为表锁。
合理设计索引，索引要尽可能准确，尽可能的缩小锁定范围，避免造成不必要的锁定。
尽可能减少基于范围的数据检索过滤条件。
尽量控制事务的大小，减少锁定的资源量和锁定时间长度。
在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率。
对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁的产生。
如今随着互联网的发展，数据的量级也是成指数的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系型数据库已经无法满足快速查询与插入数据的需求。一台数据库服务器已经无法满足海量数据的存储需求，所以由多台数据库构成的数据库集群成了必然的方式。不过，为了保证数据的一致性，查询效率等，同时又要解决多台服务器间的通信、负载均衡等问题。
MyCat是一款数据库集群软件，是阿里曾经开源的知名产品——Cobar，简单的说，MyCAT就是：一个新颖的数据库中间件产品支持MySQL集群，提供高可用性数据分片集群。你可以像使用mysql一样使用mycat。对于开发人员来说根本感觉不到mycat的存在。MyCat不单单是支持MySQL，像常用的关系型数据库Oracle、SqlServer都支持。
我们来说个例子，大海捞针和一个水瓶里捞针，毋庸置疑水瓶里一定能更快找到针，因为它需要检索的范围更小。数据库集群也是如此原理，我们可以将一个数据量为300G的数据库数据平均拆分成3部分，每个数据库中只存储100G数据，此时用户搜索，先经过我们中间代理层，中间代理层同时发出3个请求执行查询，比如第1台返回100条数据，耗时3秒，第2台返回200条数据，耗时3秒，第3台返回500条数据，耗时3秒，此时中间件只需要在800条记录中进行筛选，即可检索出用户要的结果，此时耗时其实一共只有3秒，因为每台机器做运算的时候，都是同时执行。如果我们此时直接在300G的数据库查询，耗时10秒，那使用中间件进行集群的效率就非常明显
MyCat的实现流程和这个流程大致相似。MyCat自身不存储数据，但用户每次链接数据库的时候，直接连接MyCat即可.所以我们MyCat自身其实就是个逻辑数据库，它自身还有表结构，表结构叫逻辑表。
官网：<code>http://www.mycat.io/</code>
下载地址 : <code>http://dl.mycat.io/</code>
选择1.6.7.1的版本，下载到D盘，安装包入下图：
上传：使用SecureCRT的SFTP命令，将文件发送到Linux虚拟机root目录下：
解压：解压mycat.tar.gz并查看
授权：设置mycat权限
环境变量：配置环境变量
启动mycat
查看：检测端口监听状况，Mycat的端口号是8066
连接：使用SQLYog连接Mycat
连接后显示：
配置模型
克隆虚拟机
修改配置网卡
在第二个虚拟机中，生成全新mac地址
重启网络
修改mysql配置文件,更改uuid
在第二个服务器上，修改mysql的uuid
启动MySQL并查看
主从复制的概念
为了使用Mycat进行读写分离，我们先要配置MySQL数据库的主从复制。
从服务器自动同步主服务器的数据，从而达到数据一致。
进而，我们可以写操作时，只操作主服务器，而读操作，就可以操作从服务器了。
原理：主服务器在处理数据时，生成binlog日志，通过对日志的备份，实现从服务器的数据同步。
主服务器的配置
在第一个服务器上，编辑mysql配置文件
登录mysql，创建用户并授权
重启mysql服务，登录mysql服务
查看主服务器的配置
从服务器的配置
在第二个服务器上，编辑mysql配置文件
登录mysql
重启mysql，重新登录，配置从节点
重启mysql，重新登录，开启从节点
测试
sqlyog连接主服务器
sqlyog连接从服务器
启动失败的解决方案
读写分离的概念
写操作只写入主服务器，读操作读取从服务器。
在主服务器上修改server.xml
user标签主要用于定义登录mycat的用户和权限。如上面定义用户名mycat和密码123456，该用户可以访问的schema的HEIMADB逻辑库。
在主服务器上修改schema.xml
配置详解
schema标签逻辑库的概念和mysql数据库中Datebase的概念相同，我们在查询这两个逻辑库中的表的时候，需要切换到该逻辑库下才可以查到所需要的表。
dataNode属性：该属性用于绑定逻辑库到某个具体的database上。
dataNode标签： dataNode标签定义了mycat中的数据节点，也就是数据分片。一个dataNode标签就是一个独立的数据分片。
name属性：定义数据节点的名字，这个名字需要是唯一的，我们需要在table标签上应用这个名字，来建立表与分片对应的关系。
dataHost属性：该属性用于定义该分片属于那个数据库实例，属性值是引用datahost标签定义的name属性。
database属性：该属性用于定义该分片属于那个具体数据库实例上的具体库，因为这里使用两个纬度来定义分片，就是：实例+具体的库。因为每个库上建立的表和表结构是一样的。所以这样做就可以轻松的对表进行水平拆分。
dataHost标签：该标签在mycat逻辑库中也是作为最底层的标签存在，直接定义了具体的数据库实例、读写分离配置和心跳语句。
balance属性： 负载均衡类型
balance=0: 不开启读写分离，所有读操作都发送到当前可用的writeHost上。
balance=1: 全部的readHost与Stand by writeHost都参与select语句的负载均衡
balance=2: 所有的读操作都随机在writeHost，readHost上分发。
balance=3: 所有的读请求都随机分配到writeHost对应的readHost上执行，writeHost不负担读压力。
switchType属性：
-1：表示不自动切换。
1 ：默认值，表示自动切换
2：表示基于MySQL主从同步状态决定是否切换，心跳语句： show slave status.
3:表示基于mysql galary cluster的切换机制，适合mycat1.4之上的版本，心跳语句show status like "%esrep%";
writeHost标签，readHost标签：这两个标签指定后端数据库的相关配置给mycat，用于实例化后端连接池。唯一不同的是，writeHost指定写实例、readHost指定读实例，组合这些读写实例来满足系统的要求。
host属性：用于标识不同的实例，对于writehost，一般使用M1；对于readhost一般使用S1.
url属性：后端实例连接地址，如果使用native的dbDriver，则一般为address:port这种形式，用JDBC或其他的dbDriver，则需要特殊指定。当使用JDBC时则可以这么写：jdbc:mysql://localhost:3306/。
user属性：后端存储实例的用户名。
password属性：后端存储实例的密码
重启主服务器的mycat
sqlyog连接mycat
分库分表的概念
将庞大的数据进行拆分
水平拆分：根据表的数据逻辑关系，将同一表中的数据按照某种条件，拆分到多台数据库服务器上，也叫做横向拆分。例如：一张1000万的大表，按照一模一样的结构，拆分成4个250万的小表，分别保存到4个数据库中。
垂直拆分：根据业务的维度，将不同的表切分到不同的数据库之上，也叫做纵向拆分。例如：所有的订单都保存到订单库中，所有的用户都保存到用户库中，同类型的表保存在同一库，不同的表分散在不同的库中。
Mycat水平拆分
修改主服务器的server.xml
0：本地文件方式
在mycat/conf/sequence_conf.properties文件中：
GLOBAL.MINDI=10000最小值
GLOBAL.MAXID=20000最大值，建议修改到9999999999
1：数据库方式
分库分表中保证全局主键自增唯一，但是需要执行mycat函数，配置sequence_db_conf.properties
2：时间戳方式
mycat实现的时间戳，建议varchar类型，要注意id的长度
修改主服务器的sequence_conf.properties
修改主服务器的schema.xml
table标签定义了逻辑表，所有需要拆分的表都需要在这个标签中定义。
rule属性：拆分规则。mod-long是拆分规则之一，主键根据服务器数量取模，在rule.xml中指定。如果是3个数据库，那么数据取模后，平均分配到三个库中。
name属性：定义逻辑表的表名，这个名字就如同在数据库中执行create table命令指定的名字一样，同一个schema标签中定义的表名必须是唯一的。
dataNode属性： 定义这个逻辑表所属的dataNode，该属性的值需要和dataNode标签中name属性的值相互对应。
修改主服务器的rule.xml
mycat操作
主服务器操作
从服务器操作
Mycat垂直拆分
修改主服务器的schema