表信息

假设我们有一张如下的表：

create table user
(
    id int unsigned auto_increment comment '自增主键' primary key,
    user_id varchar(32) not null comment '用户标识',
    user_name varchar(32) not null comment '用户名称',
    remark varchar(64) not null comment '用户描述',
    create_time timestamp default CURRENT_TIMESTAMP not null comment '创建时间戳',
    update_time timestamp default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '更新时间戳'
) comment '用户表' ENGINE=Innodb default charset=UTF8 auto_increment=1;
create unique index uk_user_id on user (user_id) comment '标识索引';

二进制日志( binary log) 记录了对MySQL数据库执行更改的所有操作， 但是不包括SELECT和SHOW这类操作， 因为这类操作对数据本身并没有修改。

然而， 若操作本身并没有导致数据库发生变化，那么该操作可能也会写入二进制日志。

例子

例如：

mysql> insert into user (user_id, user_name, remark) values ('01', '01', ' ');
Query OK, 1 row affected (0.00 sec)

mysql> show master status \G
Empty set (0.00 sec)

在InnoDB存储引擎中， 表都是根据主键顺序组织存放的， 这种存储方式的表称为索引组织表(index organized table) 。

在InnoDB存储引擎表中， 每张表都有个主键(PrimaryKey) ， 如果在创建表时没有显式地定义主键， 则InnoDB存储引擎会按如下方式选择或创建主键：

（1）首先判断表中是否有非空的唯一索引(Unique NOT NULL) ， 如果有， 则该列即为主键。

（2）如果不符合上述条件， InnoDB存储引擎自动创建一个6字节大小的指针。

当表中有多个非空唯一索引时， InnoDB存储引擎将选择建表时第一个定义的非空唯一索引为主键。

大家背八股文的时候，都知道 MySQL 里 InnoDB 存储引擎是采用 B+ 树来组织数据的。

这点没错，但是大家知道 B+ 树里的节点里存放的是什么呢？查询数据的过程又是怎样的？

这次，我们从数据页的角度看 B+ 树，看看每个节点长啥样。

当你想查阅书中某个知识的内容，你会选择一页一页的找呢？

还是在书的目录去找呢？

傻瓜都知道时间是宝贵的，当然是选择在书的目录去找，找到后再翻到对应的页。

书中的目录，就是充当索引的角色，方便我们快速查找书中的内容，所以索引是以空间换时间的设计思想。

那换到数据库中，索引的定义就是帮助存储引擎快速获取数据的一种数据结构，形象的说就是索引是数据的目录。

所谓的存储引擎，说白了就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。

MySQL 存储引擎有 MyISAM 、InnoDB、Memory，其中 InnoDB 是在 MySQL 5.5 之后成为默认的存储引擎。

在工作中，如果我们想提高一条语句查询速度，通常都会想对字段建立索引。

但是索引并不是万能的。建立了索引，并不意味着任何查询语句都能走索引扫描。

稍不注意，可能你写的查询语句是会导致索引失效，从而走了全表扫描，虽然查询的结果没问题，但是查询的性能大大降低。

今天就来跟大家盘一盘，常见的 6 种会发生索引失效的场景。

不仅会用实验案例给大家说明，也会清楚每个索引失效的原因。

索引是应用程序设计和开发的一个重要方面。

若索引太多，应用程序的性能可能会受到影响。而索引太少，对查询性能又会产生影响。

要找到一个合适的平衡点，这对应用程序的性能至关重要。

一些开发人员总是在事后才想起添加索引——我一直认为，这源于一种错误的开发模式。

如果知道数据的使用，从一开始就应该在需要处添加索引。

开发人员往往对于数据库的使用停留在应用的层面， 比如编写SQL语句、存储过程之类， 他们甚至可能不知道索引的存在， 或者认为事后让相关DBA加上即可。

DBA往往不够了解业务的数据流，而添加索引需要通过监控大量的SQL语句进而从中找到问题， 这个步骤所需的时间肯定是远大于初始添加索引所需要的时间，并且可能会遗漏一部分的索引。

开发多用户、数据库驱动的应用时，最大的一个难点是：一方面要最大程度地利用数据库的并发访问，另外一方面还要确保每个用户能以一致的方式读取和修改数据。

为此就有了锁(locking ) 的机制， 同时这也是数据库系统区别于文件系统的一个关键特性。

InnoDB 存储引擎较之MySQL数据库的其他存储引擎在这方面技高一筹， 其实现方式非常类似于Oracle数据库

。而只有正确了解这些锁的内部机制才能充分发挥InnoDB存储引擎在锁方面的优势。

这一章将详细介绍InnoDB存储引擎对表中数据的锁定， 同时分析InnoDB存储引擎会以怎样的粒度锁定数据。

是数据库区别于文件系统的重要特性之一。

在文件系统中， 如果正在写文件，但是操作系统突然崩溃了，这个文件就很有可能被破坏。

当然，有一些机制可以把文件恢复到某个时间点。不过，如果需要保证两个文件同步，这些文件系统可能就显得无能为力了。

例如，在需要更新两个文件时，更新完一个文件后，在更新完第二个文件之前系统重启了，就会有两个不同步的文件。

这正是数据库系统引人事务的主要目的：事务会把数据库从一种一致状态转换为另一种一致状态。

在数据库提交工作时，可以确保要么所有修改都已经保存了，要么所有修改都不保存
I
InnoDB存储引擎中的事务完全符合ACID的特性。

在MySQL命令行的默认设置下， 事务都是自动提交(autocommit) 的， 即执行SQL语句后就会马上执行COMMIT操作。

因此要显式地开启一个事务需使用命令BEGIN、START TRANSACTION， 或者执行命令SET AUTOCOMMIT=0， 禁用当前会话的自动提交。

每个数据库厂商自动提交的设置都不相同， 每个DBA或开发人员需要非常明白这一点， 这对之后的SQL编程会有非凡的意义， 因此用户不能以之前的经验来判断MySQL数据库的运行方式。

在具体介绍其含义之前， 先来看看用户可以使用哪些事务控制语句。

• START TRANSACTION|BEGIN：显式地开启一个事务。

• COMMIT：要想使用这个语句的最简形式， 只需发出COMMIT。也可以更详细一些， 写为COMMITWORK，不过这二者几乎是等价的。COMMIT会提交事务，并使得已对数据库做的所有修改成为永久性的。

• ROLLBACK：要想使用这个语句的最简形式， 只需发出ROLLBACK。同样地，也可以写为ROLLBACKWORK， 但是二者几乎是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改。

• SAVEPOINT identifier：SAVEPOINT允许在事务中创建一个保存点，一个事务中可以有多个SAVEPOINT。

• RELEASE SAVEPOINT identifier：删除一个事务的保存点， 当没有一个保存点执行这句语句时，会抛出一个异常。

• ROLLBACK TO[SAVEPOINT] identifier：这个语句与SAVEPOINT命令一起使用。可以把事务回滚到标记点，而不回滚在此标记点之前的任何工作。例如可以发出两条UPDATE语句， 后面跟一个SAVEPOINT， 然后又是两条DELETE语句。如果执行DELETE语句期间出现了某种异常情况， 并且捕获到这个异常，同时发出了ROLLBACK TO SAVEPOINT命令， 事务就会回滚到指定的SAVEPOINT ， 撤销DELETE完成的所有工作， 而UPDATE语句完成的工作不受影响。

• SET TRANSACTION：这个语句用来设置事务的隔离级别。InnoDB存储引擎提供的事务隔离级别有：READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE。