not

所插入的数据必须和数据类型匹配并且范围不能超过指定的长度。

非空约束

not

null非空约束用于确保当前列的值不为空值非空约束只能出现在表对象的列上。

如果有非空约束那么在插入插入数据时必须插入一条数据非空约束一般用于收集并存储的字段数据。

default创建列时可以指定默认值当插入数据时如果未主动设置数据则自动添加该默认值。

主键约束

primary

非空约束的组合是用于唯一识别一个实体的字段不允许有空值当创建主键的约束时系统默认会在所在的列和列组合上建立对应的唯一索引。

如果主键使用单个列则它的值必须唯一如果是多列则其组合必须唯一。

唯一约束

unique保证每一行的数据是唯一的没有重复的数据保证数据的唯一性。

唯一约束不仅可以在一个表内创建而且可以同时多表创建组合唯一约束。

外键约束

foreign

key用于表与表之间的关联一张表中的外键一般都是另一张表中的主键

并且加上外键约束之后插入的数据就必须是该主键存在的值。

自增长约束如果为某列设置自增列插入数据时无需设置此列默认将自增一个表只能有一个自增列。

自定义约束自定义约束是使用存储过程或者触发器来进行约束。

三大范式

确保每列保持原子性不可拆分性确保一列只存放一个数据即数据库表的每一列都是不可分割的原子数据项而不能是集合数组记录等非原子数据项。

如果实体中的某个属性有多个值时必须拆分为不同的属性。

确保每一行的唯一性满足第一范式的基础上确保每一行数据的唯一能够唯一区分一个实体实现的方式可以是主键。

确保每列都和主键列直接相关而不是间接相关第三范式需要确保数据表除外键外其他非主键属性不得重复出现在第二张表上。

MySQL

在SQL的标准实现上要比MySQL完善而且功能实现比较严谨存储过程的功能支持要比MySQL好具备本地缓存执行计划的能力对表连接支持较完整优化器的功能较完整支持的索引类型很多复杂查询能力较强PG主表采用堆表存放MySQL采用索引组织表能够支持比MySQL更大的数据量。

PG的主备复制属于物理复制相对于MySQL基于binlog的逻辑复制数据的一致性更加可靠复制性能更高对主机性能的影响也更小。

MySQL的存储引擎插件化机制存在锁机制复杂影响并发的问题而PG不存在。

innodb的基于回滚段实现的MVCC机制相对PG新老数据一起存放的基于XID的MVCC机制是占优的。

新老数据一起存放需要定时触

发VACUUM会带来多余的IO和数据库对象加锁开销引起数据库整体的并发能力下降。

而且VACUUM清理不及时还可能会引发数据膨胀MySQL采用索引组织表这种存储方式非常适合基于主键匹配的查询、删改操作但是对表结构设计存在约束MySQL的优化器较简单系统表、运算符、数据类型的实现都很精简非常适合简单的查询操作MySQL分区表的实现要优于PG的基于继承表的分区实现主要体现在分区个数达到上千上万后的处理性能差异较大。

MySQL的存储引擎插件化机制使得它的应用场景更加广泛比如除了innodb适合事务处理场景外myisam适合静态数据的查询场景。

获取当前

主键也是候选键按照惯例候选键可以被指定为主键并且可以用于任何外键引用。

设置为

允许没有任何索引和主键的表存在索引都是保存行的地址。

InnoDB

字节的主键(用户不可见)数据是主索引的一部分附加索引保存的是主索引的值。

可移植性、备份及恢复MyISAM

数据是以文件的形式存储所以在跨平台的数据转移中会很方便。

在备份和恢复时可单独针对某个表进行操作。

InnoDB

binlog或者用

混合日期和时间值时间戳。

每当行被更改时时间戳字段将获取当前时间戳。

NOW()

NUMERIC和DECIMAL类型被Mysql实现为同样的类型这在SQL92标准允许。

他们被用于保存值该值的准确精度是极其重要的值例如与金钱有关的数据。

当声明一个类是这些类型之一时精度和规模的能被(并且通常是)指定。

例如salaryDECIMAL(9,2)

代表将被用于存储小数点后的位数。

因此在这种情况下能被存储在salary列中的值的范围是从

-9999999.99

DECIMAL(p,0)这里实现被允许决定值p。

Mysql当前不支持

DECIMAL/NUMERIC

这一般说来不是一个严重的问题因为这些类型的主要益处得自于明显地控制精度和规模的能力。

DECIMAL

NUMERIC

值作为字符串存储而不是作为二进制浮点数以便保存那些值的小数精度。

一个字符用于值的每一位、小数点(如果

scale0)和

size(nameENUM(Smail,Medium,Large);

MySQL

索引是一种用于快速查询和检索数据的数据结构。

常见的索引结构有:

B树和

索引的作用就相当于目录的作用。

其本身是一种特殊的文件它们包含着对数据表里所有记录的引用指针会占据一定的物理空间。

创建索引和维护索引需要耗费许多时间。

当对表中的数据进行增删改的时候如果数据有索引那么索引也需要动态的修改会降低

SQL

把创建了索引的列的内容进行排序对排序结果生成倒排表在倒排表内容上拼上数据地址链在查询的时候先拿到倒排表的内容再取出数据地址链从而拿到具体数据

索引类型

建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性而不是为了查询效率。

主键索引

数据表的主键列使用的就是主键索引。

是一种特殊的唯一索引一张数据表有只能有一个主键并且主键不能为

前缀索引

前缀索引也叫局部索引前缀索引只适用于字符串类型的数据。

前缀索引是对文本的前几个字符创建索引相比普通索引建立的数据更小

因为只取前几个字符。

前缀的标识度高。

比如密码就适合建立前缀索引因为密码几乎各不相同

全文索引

全文索引主要是为了检索大文本数据中的关键字的信息通过建立倒排索引可以极大提升索引效率解决判断字段是否包含问题是目前搜索引擎使用的关键技术。

组合索引多列值组成一个索引专门用于组合搜索。

change

有效减少了对磁盘的访问次数而唯一索引需要校验唯一性此时普通索引性能要高于唯一索引。

聚集索引与非聚集索引

聚集索引聚集索引即索引结构和数据一起存放并按一定的顺序进行排序的索引找到了索引就找到了数据。

主键索引属于聚集索引。

B树本身就是一颗多叉平衡树叶子节点也都是有序的定位到索引的节点就相当于定位到了数据。

缺点

B树是多路平衡树如果索引的数据不是有序的那么就需要在插入时排序如果数据是整型还好否则类似于字符串或

UUID

非聚集索引非聚集索引即索引结构和数据分开存放的索引。

非聚集索引的叶子节点并不存放数据存储的数据行地址根据数据行地址再回表查数据。

更新代价比聚集索引要小

。

非聚集索引的更新代价就没有聚集索引那么大了非聚集索引的叶子节点是不存放数据的缺点

跟聚集索引一样非聚集索引也依赖于有序的数据可能会二次查询(回表)

当查到索引对应的指针或主键后可能还需要根据指针或主键再到数据文件或表中查询。

MyISAM采用非聚集索引

索引文件的数据域存储指向数据文件的指针。

辅索引与主索引基本一致

InnoDB主键索引采用聚集索引

最左前缀匹配原则最左优先在创建多列索引时要根据业务需求where

mysql

会一直从左向右匹配直到遇到范围查询(、、between、like)就停止匹配比如

and

如果建立(a,b,c,d)顺序的索引d是用不到索引的如果建立(a,b,d,c)的索引则都可以用到a,b,d的顺序可以任意调整。

and

都会自动分配一个唯一的标识符select_typeSELECT

查询的类型table查询的是哪个表partitions匹配的分区typejoin

类型possible_keys此次查询中可能选用的索引key此次查询中确切使用到的索引ref哪个字段或常数与

key

一起被使用rows显示此查询一共扫描了多少行这个是一个估计值filtered表示此查询条件所过滤的数据的百分比extra额外的信息

1like

左右查询字段只有一个是索引该索引失效只有当or左右查询字段均为索引时才会生效。

varchar

不等于操作符是永远不会用到索引的因此对它的处理只会产生全表扫描。

优化方法

会使用全表扫描此时索引失效。

左连接查询或者右连接查询查询关联的字段编码格式不一样。

使用

NOT

ACID原子性(Atomicity)、一致性(Correspondence)、隔离性(Isolation)、持久性(Durability)。

原子性整个事务中的所有操作要么全部成功要么全部失败不可能停滞在中间某个环节。

事务在执行过程中发生错误会被回滚Rollback到事务开始前的状态就像这个事务从来没有执行过一样。

一致性在事务开始之前和事务结束以后数据库的完整性约束没有被破坏。

隔离性隔离状态执行事务使它们好像是系统在给定时间内执行的唯一操作。

如果有两个事务运行在相同的时间内执行

相同的功能事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。

这种属性有时称为串行化为了防止事务操作间的混淆必须串行化或序列化请求使得在同一时间仅有一个请求用于同一数据。

持久性在事务完成以后该事务所对数据库所作的更改便持久的保存在数据库之中并不会被回滚。

事务可以分为很多中类型一般分为扁平事务、带有保存点的扁平事务、链事务、嵌套事务、分布式事务。

1扁平事务

扁平事务是最简单的一种在实际开发中也是使用的最多的一种事务。

在这种事务中所有操作都处于同一层次最常见的方式如下

BEGIN

扁平事务的主要缺点是不能提交或回滚事务的某一部分或者分几个独立的步骤去提交。

这种事务除了支持扁平事务支持的操作外这种事务跟扁平事务最大的区别就是允许在事务执行过程中回滚到同一事务中较早的一个状态这是因为可能某些事务在执行过程中出现的错误并不会对所有的操作都无效放弃整个事务不合乎要求开销也太大。

保存点用来通知系统应该记住事务当前的状态以便以后发生错误时事务能回到该状态。

begin

链事务在提交一个事务时释放不需要的数据对象将必要的处理上下文隐式的传给下一个要开始的事务。

需要注意提交事务操作和下一个事务操作将合并为一个原子操作就是下一个事务可以看到上一个事务的结果。

链事务就是指回滚时只能恢复到最近一个保存点而带有保存点的扁平事务则可以回滚到任意正确的保存点。

begin

还是这个例子但是对于链事务来说是不能直接rollback到保存点t1的最能恢复到最近的一个保存点t2另外我们需要注意链事务在执行

commit

后就会释放当前事务所持有的所有锁而带有保存点的扁平事务不会影响所持有的锁。

3嵌套事务

在事务中再嵌套事务这种结构有点像一颗横着的树的结构位于根节点的事务称为顶层事务。

事务的前驱称为父事务其它事务称为子事务。

事务的前驱称为父事务事务的下一层称为子事务。

子事务既可以提交也可以回滚但是它的提交操作并不马上生效除非由其父事务提交。

因此就可以确定任何子事务都在顶层事务提交后才真正的被提交了。

同理任意一个事务的回滚都会引起它的所有子事务一同回滚。

BEGIN

分布式事务通常是指在一个分布式环境下运行的扁平事务因此需要根据数据所在位置访问网络中的不同节点。

事务隔离级别

脏读发生在一个事务A读取了被另一个事务B修改但是还未提交的数据。

假如B回退则事务A读取的是无效的数据。

这跟不可重复读类似但是第二个事务不需要执行提交。

select

在多版本并行控制机制中当一个遇到提交冲突的事务需要回退但却被释放时会发生不可重复读问题。

在上面这个例子中事务2提交成功它所做的修改已经可见。

然而事务1已经读取了一个其它的值。

在序列化和可重复读的隔离级别中数据库管理系统会返回旧值即在被事务2修改之前的值。

在提交读和未提交读隔离级别下可能会返回被更新的值这就是“不可重复读”。

推迟事务2的执行直至事务1提交或者回退。

这种策略在使用锁时应用。

而在多版本并行控制中事务2可以被先提交。

而事务1继续执行在旧版本的数据上。

当事务1尝试提交时数据库会检验它的结果是否和事务1、事务2顺序执行时一样。

如果是则事务1提交成功。

如果不是事务1会被回退。

3幻读

幻读发生在当两个完全相同的查询执行时第二次查询所返回的结果集跟第一个查询不相同。

原子性、一致性和持久性实现原理

日志记录数据修改后的值可以避免数据在事务提交之前必须写入到磁盘的需求减少

MySQL

称为闩锁轻量级的锁因为其要求锁定的时间必须非常短若持续的时间长则应用的性能会非常差。

在InnoDB引擎中Latch

mutex互斥量和

rwlock读写锁。

其目的是用来保证并发线程操作临界资源的正确性并且通常没有死锁检测的机制。

show

当一个事务对数据加上读锁之后其他事务只能对该数据加读锁而不能加写锁直到所有的读锁释放之后其他事务才能对该数据加写锁。

共享锁主要是为了支持并发读取数据读取数据的时候不支持修改避免出现重复读的问题。

排他锁

当一个事务对数据加上写锁之后其他事务将不能对该数据加任何锁直到该锁释放。

排他锁的目的是在对数据修改时不允许其他事务同时修改和读取避免出现脏读和幻读的问题。

意向共享锁

特点开销大加锁慢会出现死锁锁定粒度最小发生锁冲突的概率最低并发度也最高。

使用行级锁InnoDB

特点开销和加锁时间界于表锁和行锁之间会出现死锁锁定粒度界于表锁和行锁之间并发度一般。

BerkeleyDB

特点粒度大、加锁解锁简单、不会出现死锁容易发生锁冲突、并发性能低。

MyISAMMEMORYCSV

间隙锁属于行锁的一种间隙锁锁住的是一个区间而不仅仅是这个区间中的每一条数据。

间隙锁

InnoDB

临键锁是记录锁和间隙锁的组合它指的是加在某条记录以及这条记录前面间隙上的锁。

每个数据行上的非唯一索引列上都会存在一把临键锁当某个事务持有该数据行的临键锁时会锁住一段左开右闭区间的数据。

临键锁只与非唯一索引列有关在唯一索引列包括主键列上不存在临键锁。

基于加锁机制

语句不会对查询的数据进行加锁其他事务仍可以对查询的数据执行更新和删除操作。

因此InnoDB

SELECT

MODE对读取的行添加S锁其他事物可以对这些行添加S锁若添加X锁则会被阻塞。

SELECT

...

UPDATE会对查询的行及相关联的索引记录加X锁其他事务请求的S锁或X锁都会被阻塞。

当事务提交或回滚后通过这两个语句添加的锁都会被释放。

注意只有在自动提交被禁用时SELECT

FOR

一致性锁定读必须在一个事物中当事务提交了锁就释放了因此使用这两种方式加锁的语句必须加上begin、start

transaction或者set

存储引擎通过多版本控制(MVVC)读取当前数据库中行数据的方式。

如果读取的行正在执行

DELETE

操作这时读取操作不会因此去等待行上锁的释放。

相反地InnoDB

会去读取行的一个快照。

所以非锁定读机制大大提高了数据库的并发性。

InnoDB

默认的读取方式即读取不会占用和等待行上的锁。

在事务隔离级别READ

COMMITTED和REPEATABLE

COMMITTED事务隔离级别下一致性非锁定读总是读取被锁定行的最新一份快照数据。

而在REPEATABLE

InnoDB

记录锁行锁单条索引记录上加锁锁住的永远是索引而非记录本身。

行锁的实现依赖于索引一旦某个加锁操作没有使用到索引那么该锁就会退化为表锁。

记录锁存在于包括主键索引在内的唯一索引中锁定单条索引记录。

Gap

Lock

间隙锁在索引记录之间的间隙中加锁锁定一个范围并不包括该索引记录本身。

间隙锁存在于非唯一索引中锁定开区间范围内的一段间隔它是基于临键锁实现的。

Next-Key

Lock

的结合既除了锁住记录本身也锁住索引之间的间隙一个范围。

临键锁存在于非唯一索引中该类型的每条记录的索引上都存在这种锁它是一种特殊的间隙锁锁定一段左开右闭的索引区间。

Next-Key

Lock正好相反锁定的区间是区间范围和前一个值左闭右开。

同样上述的值使用

Previous-Key

的这里有一种特殊的情况在查询的列是唯一索引包含主键索引的情况下Next-key

Lock

COMMITED。

将参数innodb_locks_unsafe_for_binlog设置为1。

Gap

的作用是为了阻止多个事务将记录插入到同一个范围内设计它的目的是用来解决

Phontom

Problem幻读问题。

在MySQL默认的隔离级别Repeatable

Read下InnoDB

分区将数据在物理上分隔开不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。

拆分又分垂直拆分和水平拆分首先应考虑在

where

涉及的列上建立索引。

尽量不在包含大量重复值的字段上建立索引如性别

sex。

索引不是越多越好一般考虑在6个左右。

应在查询较多的字段上建立索引而不是在频繁更新的字段上建立索引。

字段的值只有数值型时应设计为数字型字段。

因为引擎在处理查询和连接时会逐个比较字符串中每一个字符而对于数字型而言只需要比较一次就够了。

尽可能的使用

varchar/nvarchar

因为首先变长字段存储空间小可以节省存储空间其次对于查询来说在一个相对较小的字段内搜索效率显然要高些。

尽量使用表变量来代替临时表。

如果表变量包含大量数据请注意索引非常有限只有主键索引。

避免频繁创建和删除临时表以减少系统表资源的消耗。

临时表并不是不可使用适当地使用它们可以使某些例程更有效例如当需要重复引用大型表或常用表中的某个数据集时。

但是对于一次性事件最好使用导出表。

在新建临时表时如果一次性插入数据量很大那么可以使用

select

table然后insert。

如果使用到了临时表在存储过程的最后务必将所有的临时表显式删除先

truncate

子句中使用!或操作符否则将引擎放弃使用索引而进行全表扫描。

尽量避免在

where

子句中对字段进行表达式操作这将导致引擎放弃使用索引而进行全表扫描。

尽量避免在

where

子句中对字段进行函数操作这将导致引擎放弃使用索引而进行全表扫描。

慎用

not

只会在检索出所有记录之后才对结果集进行过滤。

避免使用隐式转换如

varchar

会自动进行数据类型转换再执行函数作用于表字段时索引就会失效。

使用

like

。

复合索引高选择性的字段排在前面。

根据联合索引的第二个及以后的字段单独查询用不到索引。

字符串比较长的可以考虑索引一部份减少索引文件大小提高写入效率。

如果在

where

子句中使用参数也会导致全表扫描。

因为SQL只有在运行时才会解析局部变量但优化程序不能将访问计划的选择推迟到运行时它必须在编译时进行选择。

然而如果在编译时建立访问计划变量的值还是未知的因而无法作为索引选择的输入项。

如下面语句将进行全表扫描

select

numnum。

尽量避免使用游标因为游标的效率较差如果游标操作的数据超过1万行那么就应该考虑改写。

尽量避免向客户端返回大数据量若数据量过大应该考虑相应需求是否合理。

尽量避免大事务操作提高系统并发能力。

Java

尽可能的少造对象。

合理摆正系统设计的位置。

大量数据操作和少量数据操作一定是分开的。

大量的数据操作肯定不是ORM框架搞定的。

使用jDBC链接数据库操作数据控制好内存让数据流起来而不是全部读到内存再处理而是边读取边处理合理利用内存有的数据要缓存

MySQL

也存放数据(data)叶子节点各自独立。

B树是B树的一种变体内部节点都是键(key)没有值叶子节点同时存放键(key)和值(value)。

而且所有的叶子结点中增加了指向下一个叶子节点的指针

InnoDB

B树可以在内部节点同时存储键和值因此把频繁访问的数据放在靠近根节点的地方将会大大提高热点数据的查询效率。

这种特性使得B树在特定数据重复多次查询的场景中更加高效。

由于B树的内部节点只存放键不存放值因此一次读取可以在内存页中获取更多的键有利于更快地缩小查找范围。

B树的叶节点由一条链相连因此当需要进行一次全数据遍历的时候B树只需要使用O(logN)时间找到最小的一个节点然后通过链进行O(N)的顺序遍历即可检索效率很稳定。

而B树则需要对树的每一层进行遍历(当于对范围内的每个节点的关键字做二分查找)这会需要更多的内存置换次数因此也就需要花费更多的时间

数据库为什么使用

B树只适合随机检索而B树同时支持随机检索和顺序检索B树空间利用率更高可减少I/O次数磁盘读写代价更低。

B树的内部结点并没有指向关键字具体信息的指针只是作为索引使用其内部结点比B树小盘块能容纳的结点中关键字数量更多一次性读入内存中可以查找的关键字也就越多相对的IO读写次数也就降低了。

B树的查询效率更加稳定B树搜索有可能会在非叶子结点结束越靠近根节点的记录查找时间越短只要找到关键字即可确定记录的存在其性能等价于在关键字全集内做一次二分查找。

而在B树中顺序检索比较明显随机检索时任何关键字的查找都必须走一条从根节点到叶节点的路所有关键字的查找路径长度相同导致每一个关键字的查询效率相当。

B-树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。

B树的叶子节点使用指针顺序连接在一起只要遍历叶子节点就可以实现整棵树的遍历。

而且在数据库中基于范围的查询是非常频繁的而B树不支持这样的操作。

增删文件节点时效率更高。

因为B树的叶子节点包含所有关键字并以有序的链表结构存储这样可很好提高增删效率。

MySQL

域的值为地址读取相应的数据记录。

这被称为“非聚簇索引。

InnoDB

BTree

表数据文件本身就是主索引。

这被称为“聚簇索引或聚集索引而其余的索引都作为辅助索引辅助索引的

data

所在的节点即可取出数据在根据辅助索引查找时则需要先取出主键的值在走一遍主索引。

因此在设计表的时候不建议使用过长的字段作为主键也不建议使用非单调的字段作为主键这样会造成主索引频繁分裂。

Hash

在大多数情况下直接选择B树索引可以获得稳定且较好的查询速度而不需要使用hash索引。

hash

函数就可以获取到相应的键值之后进行回表查询获得实际数据。

B树底层实现是多路平衡查找树对于每一次的查询都是从根节点出发查找到叶子节点方可以获得所查键值然后根据查询判断是否需要回表查询数据。

hash

索引进行等值查询更快(一般情况下)但是却无法进行范围查询。

因为在

hash

函数建立索引之后索引的顺序与原顺序无法保持一致不能支持范围查询。

而B树的的所有节点皆遵循(左节点小于父节点右节点大于父节点多叉树也类似)支持范围查询。

hash

索引任何时候都避免不了回表查询数据而B树在符合某些条件(聚簇索引覆盖索引等)的时候可以只通过索引完成查询。

hash

索引虽然在等值查询上较快但是不稳定。

性能不可预测当某个键值存在大量重复的时候发生

hash

碰撞此时效率可能极差。

而B树的查询效率比较稳定对于所有的查询都是从根节点到叶子节点且树的高度较低。

MySQL

指定索引缓冲区的大小它决定索引处理的速度尤其是索引读的速度。

通过检查状态值Keyreadrequests

keybuffersize

使用操作系统的缓存来缓存数据所以我们得为系统留够足够的内存在很多情况下数据要比索引大得多。

如果机器性能优越可以设置多个keybuffer,分别让不同的

keybuffer

来缓存专门的索引innodbbufferpool_size表示缓冲池字节大小InnoDB

体系结构有关在

和操作系统实用的最大大小低于设置的最大值。

如果设定的缓冲池的大小大于

1G设置

当数据提交或满足检查点条件后才一次性将内存数据刷新到磁盘中。

然而内存还有操作系统或数据库其他进程使用,

一般设置

的失效率非常高。

表变更不仅仅指表中的数据发生变化还包括结构或者索引的任何变化对于不同

sql

值会不同相关参数设置不合理会造成大量内存碎片相关的参数设置会稍后介绍。

readbuffersize是

MySQL

读入缓冲区大小。

对表进行顺序扫描的请求将分配一个读入缓冲区MySQL

变量控制这一缓冲区的大小。

如果对表的顺序扫描请求非常频繁并且你认为频繁扫描进行得太慢可以通过增加该变量值以及内存缓冲区大小提高其性能。

Mysql

ACL访问控制列表是与对象关联的权限列表这个列表是Mysql服务器安全模型的基础它有助于排除用户无法连接的问题。

Mysql将ACL也称为授权表缓存在内存中当用户尝试认证或运行命令时Mysql会按照预定的顺序检查ACL的认证信息和权限。

Unix

#[mysqldir]/bin/mysql-hhostname-uUserName-ppassword

Unix

BLOB或TEXT字段是不允许的只能使用比较运算符HEAP表不支持AUTO_INCREMENT索引不可为NULL

如何控制

用来记录数据库表结构变更以及表数据修改的的二进制日志它只会记录表的变更操作但不会记录

select

传给从库从库接收到之后读取内容写入从库实现主库和从库数据一致性。

审计可以通过二进制日志中的信息进行审计判断是否对数据库进行注入攻击。

binlog

索引文件文件名后缀为.index用于记录哪些日志文件正在被使用日志文件文件名后缀为.00000*记录数据库所有的DDL和DML(除了数据查询语句)语句事件。

binlog

ROW记录的是每一行被修改的数据STATEMENT记录的是执行的SQL语句MIXEDstatement

row

MySQL的binlog文件中记录的是对数据库的各种修改操作用来记录修改操作的数据结构是Log

event有Query

Event保存在一个binlog_cache_mngr数据结构中在该结构中有两个缓冲区一个是stmt_cache用于存放不支持事务的信息另一个是trx_cache用于存放支持事务的信息。

event写入到外部binlog文件中。

不同事务以串行方式将log

event信息在binlog文件中是连续的中间不会插入其他事务的log

一张表有ID自增主键当

表会把自增主键的最大ID记录到数据文件里重启MySQL自增主键的最大ID也不会丢失如果表的类型是

表只是把自增主键的最大ID记录到内存中所以重启数据库或者是对表进行OPTIMIZE操作都会导致最大ID丢失。