qq_39921135的博客

如果列名跟实体类的名不一致，就需要通过起别名的方式来处理一下。创建dao包，可以在dao包中装接口和实现类。创建BaseDao对象并复制如下代码。

在MyCat的逻辑结构主要负责逻辑库、逻辑表、分片规则、分片节点等逻辑结构的处理，而具体的数据 存储还是在物理结构，也就是数据库服务器中存储的。在MyCat的整体结构中，分为两个部分：上面的逻辑结构、下面的物理结构。在后面讲解MyCat入门以及MyCat分片时，还会讲到上面所提到的概念。

bin : 存放可执行文件，用于启动停止mycatconf：存放mycat的配置文件lib：存放mycat的项目依赖包（jar）logs：存放mycat的日志文件。

分库分表的形式，主要是两种：垂直拆分和水平拆分。

分库分表的中心思想都是将数据分散存储，使得单一数据库/表的数据量变小来缓解单一数据库的性能 问题，从而达到提升数据库性能的目的。为了解决上述问题，我们需要对数据库进行分库分表处理。

如果我们要将之前的数据也需要同步到从库，那么这个时候我们可以先把主库的数据导出到一个SQL脚本中，然后在从库中把SQL脚本执行，这样先保证主库和从库的初始数据是一致的，然后再从当前位置往后再进行同步。在这里面就可以看到主从复制的状态，当前关联的主库的ip地址、主库的端口号、主库的用户名是什么、当前从主库的哪个日志文件、哪个位置开始读取，以及在当前这个里面所涉及到的中继日志是哪个。IO线程是用来读取二进制日志以及写入中继日志的，SQL线程是用来读取中继日志，并且把数据反应到自身变化的。

从库涉及到两组线程，一组线程叫IOThread，IO线程就会发起一个请求来连接master数据库，然后来读取master数据库中的Binlog ，写入到从库的中继日志 Relay Log。另一组线程叫做SQLthread，它主要负责读取中继日志中的数据，然后把中继日志中所记录的数据变化再反映到自身数据库的数据变化，从而就保证了主从数据是一致的。Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。slave重做中继日志中的事件，将改变反映它自己的数据。

之前我们提到过，在进行数据备份的时候需要加上一个全局锁，避免数据不一致的情况发生，那么一旦加了全局锁，当前数据库就会处于只读状态，其他的客户端是不能够执行增删改操作的；而从库，由于你加了全局锁，查是没有问题，所以从库依然可以查询，只不过在加了全局锁在执行备份期间，数据同步可能会存在一定的延迟。之前如果我们没有主从复制的结构，只是一个单机版的数据库，那么所有的增删改查的请求都是由主库来承担。而现在如果有了主从复制结构，读写分离之后，指的是增删改的请求操作主库，查询的请求操作从库，这样就降低了主库的访问压力。

默认情况下，不会记录管理语句，也不会记录不使用索引进行查找的查询。上述所有的参数配置完成之后，都需要重新启动MySQL服务器才可以生效。如果需要开启慢查询日志，需要在MySQL的配置文件。默认为 10 秒，最小为 0， 精度可以到微秒。的所有的SQL语句的日志，默认未开启。慢查询日志记录了所有执行时间超过参数。设置值并且扫描记录数不小于。慢查询日志的文件默认为。

开启了查询日志之后，在MySQL的数据存放目录，也就是 /var/lib/mysql/ 目录下就会出现 mysql_query.log 文件。之后所有的客户端的增删改查操作都会记录在该日志文件之中，长时间运行后，该日志文件将会非常大，因此如果这份日志文件我们用不上，可以把这份日志关掉就行了。查询日志中记录了客户端的所有操作语句，而二进制日志不包含查询数据的SQL语句。由于查询日志中的日志信息比较多，因此默认情况下，查询日志是未开启的。如果需要开启查询日志，可以修改MySQL的配置文件。

二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。作用：①. 灾难时的数据恢复；②. MySQL的主从复制。log_bin：ON表示二进制日志默认是开着的。

错误日志是 MySQL 中最重要的日志之一，它记录了当 mysqld 启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。当数据库出现任何故障导致无法正常使用时，建议首先查看此日 志。该日志是默认开启的，默认存放目录 /var/log/，默认的日志文件名为 mysqld.log。

该mysql不是指mysql服务，而是指mysql的客户端工具。-e选项可以在Mysql客户端执行SQL语句，而不用连接到MySQL数据库再执行，对于一些批处理脚本， 这种方式尤其方便。示例：mysqladmin 是一个执行管理操作的客户端程序。可以用它来检查服务器的配置和当前状态、创建并删除数据库等。如下图是对应的用法和选项下图就是对应的指令示例：由于服务器生成的二进制日志文件以二进制格式保存，所以如果想要检查这些文本的文本格式，就会使用到 mysqlbinlog 日志管理工具。示例：A.

Mysql数据库安装完成后，自带了一下四个数据库，具体作用如下：

ReadView（读视图）是快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务 （未提交的）id。因为我们知道，快照读在读取的时候并不是读取最新的记录，它读取的有可能是历史版本；刚才我们已经介绍了undo log日志所形成的版本链，在版本链中所产生的这些记录都是历史记录，我们快照读在执行的时候，那么到底读取哪一个历史记录呢？就是有ReadView来决定的，因为在ReadView中它会记录并维护系统当前活跃的事务id，这种获取的事务id指的是未提交的事务id。

回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志。当我们事务一旦提交或者回滚，那么这份undo log日志是可以被删除的，但是并不会立即被删除。那什么情况下可以立即被删除，什么情况下又不会立即删除呢？当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除。

当我们创建了上面的这张表，我们在查看表结构的时候，就可以显式的看到这三个字段。隐藏字段含义DB_TRX_ID最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID。回滚指针，指向这条记录的上一个版本，用于配合 undo log，指向上一个版本。DB_ROW_ID隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段，作为隐藏主键。而上述的前两个字段是肯定会添加的， 是否添加最后一个字段DB_ROW_ID，得看当前表有没有主键， 如果有主键，则不会添加该隐藏字段。

原因就是因为普通的select是快照读，而在当前默认的RR隔离级别下，开启事务后第一个select语句才是快照读的地方，后面执行相同 的select语句都是从快照中获取数据，可能不是当前的最新数据，这样也就保证了可重复读。在测试中我们可以看到，即使是在默认的RR隔离级别下，事务A中依然可以读取到事务B最新提交的容，因为在查询语句后面加上了 lock in share mode 共享锁，此时是当前读操作，可以读取到最新的数据。当然，当我们加排他锁的时候，也是当前读操作。，加上锁之后就变成了当前读。

undo log和redo log记录物理日志不一样，它是逻辑日志，物理日志主要记录的是：这个数据里面的内容是什么样子的，而undo log记录的是每一步执行的是什么样的操作。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的 update记录。undo log是用来解决事务的原子性的，事务的原子性的实现就要依赖于undo log日志。之前讲解段的时候，提到了有一个段叫回滚段，undo log就存放在回滚段中。

当我们在一个事务中，执行多个增删改的操作时，InnoDB引擎会先操作缓冲池中的数据，如果缓冲区没有对应的数据，会通过后台线程将磁盘中的数据加载出来，存放在缓冲区中，然后将缓冲池中的数据修改，此时缓冲区中的数据发生了变更，但是磁盘中的数据并没有发生变更，修改后的数据页我们称为脏页。而缓冲区的脏页数据并不是实时刷新的，而是一段时间之后将缓冲区的数据刷新到磁盘中，假如刷新到磁盘的过程出错了，而提示给用户事务提交成功，但是最终在脏页刷新的时候失败了，而数据却没有持久化下来，这就出现问题了，没有保证事务的持久性。

InnoDB引擎很重要的一个特性就是支持事务，那么它底层事务是怎么去实现的呢？

对InnoDB引擎的整个体系结构就是：当我们业务在操作的时候，会直接去操作这一块的缓冲区，如果缓冲区中没有数据，会想磁盘中的数据加载回来，然后再存储在缓冲区中，我们在增删改查的时候都会去操作这一块的缓冲区。当然这里我说的永久化保留，主要指的是我们表中的数据、索引等相关信息，对于ando log 和 redo log，这个并不是说把所有的东西都保留下来，这个是需要去回收以释放对应的磁盘空间。然后缓冲区中的数据会以一定的频率 / 一定的时机，通过这组后台线程刷新到磁盘中，然后在磁盘中进行永久化的保留下来。

后台线程的作用就是：将InnoDB存储引擎的缓冲池中的数据在合适的时机刷新到磁盘文件中。在InnoDB的后台线程中，分为4类，分别是：Master Thread 、IO Thread、Purge Thread、 Page Cleaner Thread。

双写缓冲区，innoDB引擎将数据页从我们刚才将的内存结构的Buffer Pool刷新到磁盘前，但是刷新到磁盘前，为了保证数据的安全性，先会将数据页写入双写缓冲区文件中，便于系统异常时恢复数据，保证数据的安全性。以下文件，每一个文件都是一个表空间文件，在这个表空间文件中，它所存放的就是这张表的表结构，以及表中的数据、索引。如果InnoDB引擎中，每一张表的独立表空间关闭着的话，那么所有的表的数据以及索引也是在系统表空间存储。指定表空间的名字，datafile：指定表空间关联的表空间文件，并且指定存储引擎。

MySQL5.5 版本开始，默认使用InnoDB存储引擎，它擅长事务处理，具有崩溃恢复特性，在日常开发中InnoDB存储引擎使用非常广泛。下面是InnoDB架构图，左侧为内存结构，右侧为磁盘结构。

段，分为数据段（Leaf node segment）、索引段（Non-leaf node segment）、回滚段 （Rollback segment），InnoDB是索引组织表，数据段就是B+树的叶子节点， 索引段即为B+树的非叶子节点。表空间是InnoDB存储引擎逻辑结构的最高层， 如果用户启用了参数 innodb_file_per_table(在 8.0版本中默认开启) ，则每张表都会有一个表空间（xxx.ibd），一个mysql实例可以对应多个表空间，用于存储记录、索引等数据。一页中又包含多个行。

默认情况下，InnoDB在 REPEATABLE READ事务隔离级别 运行，InnoDB使用 next-key 锁进行搜索和索引扫描，以防止幻读。注意：间隙锁唯一目的是防止其他事务插入间隙，造成幻读现象。间隙锁可以共存，一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用间隙锁。对于间隙锁和临键锁大家不用去记，主要针对于某一条SQL，你能够分析出它为什么要加这个锁就行了。

InnoDB实现了以下两种类型的行锁：共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。简单说：共享锁和共享锁之间是兼容的，但是共享锁和排他锁之间是互斥的。排他锁（X）：允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。也就是说，如果这个事务它获取到了这一行数据的排他锁，那么此时它就可以更新语句，并且其他的事物就不能再获取这一行数据的共享锁及排他锁。由这两点实际上也引出了在InnoDB存储引擎中，两种类型的行锁它们之间的兼容情况。

理解：索引的结构是B+树结构，索引的分类中我们提到，InnoDB存储引擎中索引的分类分为聚集索引和二级索引，聚集索引的叶子结点下面挂的是这一行的行数据，二级索引叶子结点挂的是对应的主键值。所以我们的行数据是基于聚集索引存储的，所以叫做InnoDB的数据是基于索引组织的，索引的叶子结点下面挂的就是这一行的数据，并且在InnoDB引擎中，这个B+树的叶子结点它是一个有序的，才形成了一条双向链表。InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。

为了避免DML在执行时，加的行锁与表锁的冲突，在InnoDB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查。有一个客户端，它要去操作这张表，先开启事务，然后执行update语句，在更新的时候，就要更新这张表中id为3的这条记录，那么此时在默认的MySQL的隔离级别之下，你执行这条update语句，并且还是根据主键进行更新，它会自动的对这一行加上行锁。

元数据锁，简写MDL。MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上。元数据可以简单理解为表结构，MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。简单说：如果某张表存在未提交的事物，那么我们是不能去修改这张表的表结构。作用：为了避免DML与 DDL冲突，保证读写的正确性。这里的元数据，大家可以简单理解为就是一张表的表结构。也就是说，某一张表涉及到未提交的事务时，是不能够修改这张表的表结构的。

表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM、 InnoDB、BDB等存储引擎中，我们接下来所讲解的表级锁主要演示的是InnoDB引擎下的表级锁。表锁：锁的就是整张表元数据锁（meta data lock，MDL）意向锁。

加上这个参数，实际上MySQL的InnoDB引擎的底层实际上是通过快照读来实现的。在InnoDB引擎中，我们可以在备份时加上参数。参数来完成不加锁的一致性数据备份。

全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞。其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。数据备份：将数据库中的数据备份成一个SQL文件，备份到磁盘中。为什么全库逻辑备份，就需要加全就锁呢？

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（CPU、 RAM、I/O）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

测试完毕之后，检查日志表中的数据是否可以正常插入，以及插入数据的正确性。

测试完毕之后，检查日志表中的数据是否可以正常插入，以及插入数据的正确性。

通过触发器记录 tb_user 表的数据变更日志，将变更日志插入到日志表user_logs中，包含增加, 修改 , 删除;测试完毕之后，检查日志表中的数据是否可以正常插入，以及插入数据的正确性。

触发器是与表有关的数据库对象，指在之前(BEFORE)或之后(AFTER)，触发并执行触发器中定义的SQL语句集合。触发器的这种特性可以协助应用在数据库端确保数据的完整性, 日志记录，数据校验等操作。使用别名OLD和NEW来引用触发器中发生变化的记录内容，这与其他的数据库是相似的。现在触发器还只支持行级触发，不支持语句级触发。OLD是用来引用原来的记录内容，NEW引用的是新的记录内容。行级触发：当我们执行一条update语句，它影响了五行，那么这个时候触发器会被触发五次。

存储函数是有返回值的存储过程，存储函数的参数只能是IN类型的。也就是说对于存储函数来说，我们要去定义一个存储函数，必须要指定返回值，而且它的参数列表中所有的参数必须是输入类型in类型的，不能是out类型，当然，不写也是in类型。CREATE FUNCTION 存储函数名称 ([ 参数列表 ])RETURNS type [characteristic ...] -- characteristic：可选参数，指代的是当前存储参数它的特性BEGIN-- SQL语句RETURN ...;END;