JAVA知识点（二）：数据库

Mysql优化

如何优化数据库？

作为一名数据库专家，我将为您详细阐述MySQL优化的各个方面：

MySQL优化确实是一项综合性技术，涉及数据库设计、配置、硬件以及日常维护等多个层面。下面我将逐一解释您提到的各个优化点：

a: 表的设计合理化 (符合3NF)

• 核心思想: 数据库表结构设计是性能优化的基石。遵循数据库设计范式，尤其是第三范式（3NF），能有效减少数据冗余和更新异常。
• 详解:
  • 第一范式 (1NF): 确保字段的原子性，即每个字段都是不可再分的最小数据单元。
  • 第二范式 (2NF): 在1NF基础上，消除非主键字段对主键的部分函数依赖。通常要求表有单一主键（或主键组合），且所有非主键字段都完全依赖于整个主键。
  • 第三范式 (3NF): 在2NF基础上，消除非主键字段之间的传递函数依赖。即非主键字段不应依赖于其他非主键字段。
• 意义: 合理的设计能减少存储空间，保证数据一致性，并为后续的索引优化打下良好基础。但有时为了特定查询性能，可能会适度反范式化（如增加冗余字段），需要权衡。

b: 添加适当索引 (Index)

• 核心思想: 索引是数据库中用于加速数据检索的关键技术，类似于书籍的目录。
• 四种主要索引类型:
  • 普通索引 (Normal Index): 最基本的索引类型，没有任何限制，允许在定义索引的列中插入重复值和空值。
  • 主键索引 (Primary Key Index): 一种特殊的唯一索引，不允许有空值。一个表只能有一个主键索引，它唯一标识表中的每一行记录。
  • 唯一索引 (Unique Index): 索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。
  • 全文索引 (Full-Text Index): 主要用于在文本数据（如 VARCHAR, TEXT 类型）中进行关键词搜索，而不是简单的 = 或 LIKE 操作。在MyISAM和InnoDB（MySQL 5.6+）存储引擎中支持。
• 优化要点: 选择合适的列创建索引至关重要。通常在 WHERE, ORDER BY, GROUP BY, JOIN 子句中频繁出现的列上建立索引效果显著。但索引也会占用存储空间，并在数据增删改时带来额外开销，因此需要平衡。

c: 分表技术 (水平分割、垂直分割)

• 核心思想: 当单表数据量过大时，查询和维护效率会显著下降。分表是将一个大表拆分成多个小表的技术。
• 详解:
  • 垂直分割 (Vertical Partitioning): 按照列（字段）将表拆分。例如，将不常用的字段或大字段（如 TEXT, BLOB）拆分到另一张表中。这能减少单行数据的大小，提高I/O效率。
  • 水平分割 (Horizontal Partitioning): 按照行（记录）将表拆分。常见策略有按时间范围、按ID范围、按哈希值等。例如，将订单表按月份拆分成多张表。这能显著减少单表的数据量，提升查询速度。
• 意义: 分表能有效解决单表数据量过大带来的性能瓶颈，但会增加应用层的复杂度（需要知道数据在哪张子表中）。

d: 读写分离 (Read/Write Separation)

• 核心思想: 将数据库的读操作和写操作分发到不同的数据库实例上，以分散负载，提高并发处理能力。
• 实现方式: 通常基于主从复制（Master-Slave Replication）架构。主库（Master）负责处理写操作（INSERT, UPDATE, DELETE），并将数据变更同步到一个或多个从库（Slave）。从库负责处理读操作（SELECT）。
• 意义: 写操作通常涉及锁和日志，压力较大；读操作相对轻量。通过分离，可以将读请求分散到多个从库，显著提升系统的读取能力和整体并发量。

e: 存储过程 (Stored Procedures)

• 核心思想: 将一组预编译的SQL语句集合作为存储过程保存在数据库服务器端。
• 优势:
  • 模块化编程: 可以封装复杂的业务逻辑，提高代码复用性和可维护性。
  • 性能提升: 存储过程在创建时即被编译，后续调用无需再次编译，减少了网络传输和SQL解析的开销。
  • 安全性: 可以控制用户对数据的访问权限，只允许通过特定的存储过程操作数据。
• 注意: 过度使用存储过程可能使业务逻辑与数据库耦合过紧，不利于系统扩展和移植。

f: 对MySQL配置优化

• 核心思想: 通过调整MySQL服务器的配置参数，使其更好地适应硬件环境和业务负载。
• 关键配置项:
  • 最大连接数 (max_connections): 设置MySQL服务器允许的最大并发连接数。根据应用的并发访问量调整，避免因连接数过多导致服务器资源耗尽。
    • 查看: SHOW VARIABLES LIKE 'max_connections';
    • 修改 (my.cnf/my.ini): [mysqld] max_connections = 1000
  • 缓冲池大小 (innodb_buffer_pool_size): InnoDB存储引擎最重要的缓存，用于缓存索引和数据页。通常设置为物理内存的70%-80%。
    • 查看: SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
    • 修改: [mysqld] innodb_buffer_pool_size = 4G
  • 查询缓存 (query_cache_size): (注意：MySQL 8.0已移除) 缓存SELECT查询的结果。对于重复查询较多的场景有一定帮助，但需注意其锁竞争问题。
  • 临时表大小 (tmp_table_size, max_heap_table_size): 控制内存中临时表的最大大小。如果查询需要的临时表超过此值，会转为基于磁盘的临时表，影响性能。
  • 日志文件大小 (innodb_log_file_size): 影响事务提交和崩溃恢复的性能。
• 意义: 合理的配置能最大化利用服务器资源，显著提升MySQL性能。

g: MySQL服务器硬件升级

• 核心思想: 硬件是性能的基础。当软件优化达到瓶颈时，升级硬件是最直接有效的手段。
• 关键硬件:
  • CPU: 更多核心和更高主频能提升查询处理速度。
  • 内存 (RAM): 增加内存可以扩大缓冲池（Buffer Pool）和操作系统缓存，减少磁盘I/O。
  • 存储 (硬盘): 使用SSD固态硬盘替代传统机械硬盘能大幅提升随机读写性能，对数据库I/O密集型操作（如索引查找、排序）效果显著。
  • 网络: 在分布式或主从架构中，高速网络能减少数据同步延迟。
• 意义: 硬件升级通常能带来立竿见影的性能提升，但成本也相对较高。

h: 定时清理不需要的数据，定时进行碎片整理 (MyISAM)

• 核心思想: 维护数据库的“整洁”，避免无效数据和存储碎片影响性能。
• 详解:
  • 定时清理数据: 定期删除过期或不再需要的历史数据。可以使用 DELETE 语句结合 WHERE 条件，或对于大批量删除，考虑使用分区表（Partitioning）然后 DROP PARTITION。
  • 碎片整理:
    • MyISAM: MyISAM存储引擎的表在频繁的增删改操作后容易产生碎片，导致存储空间浪费和查询效率下降。可以使用 OPTIMIZE TABLE table_name; 命令进行碎片整理。该命令会重建表和索引，回收未使用的空间。
    • InnoDB: InnoDB存储引擎的表结构是聚集索引组织的，碎片问题相对复杂一些。OPTIMIZE TABLE 对InnoDB来说本质上是重建表（ALTER TABLE ... ENGINE=InnoDB）。InnoDB会自动管理一部分空间回收，但定期执行 OPTIMIZE TABLE 或在线DDL操作也有助于整理碎片。
• 意义: 保持数据的有效性和存储的紧凑性，有助于维持数据库的高性能和存储效率。

优化是一个多层次、持续性的过程。从良好的数据库设计开始，结合索引、分表、读写分离等架构优化，再辅以存储过程、配置调优、硬件升级和日常维护，才能构建一个高性能、高可用的MySQL数据库系统。在实际应用中，需要根据具体的业务场景、数据特征和性能瓶颈，选择合适的优化策略组合。

Sql如何优化？

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0

3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20

5.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3

6.下面的查询也将导致全表扫描：
select id from t where name like ‘%abc%’

7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2

8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)=‘abc’–name以abc开头的id
应改为:
select id from t where name like ‘abc%’

9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，
否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

11.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(…)

12.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)

13.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，
如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。

14.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，
因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。
一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

15.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。
这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

16.尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间，
其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

17.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。

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

19.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

20.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，
以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

21.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。

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

23.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。

24.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。
在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
25.尽量避免大事务操作，提高系统并发能力。26.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

Mysql如何做高可用?

第一种：主从复制+读写分离
客户端通过Master对数据库进行写操作，slave端进行读操作，并可进行备份。Master出现问题后，可以手动将应用切换到slave端。

对于数据实时性要求不是特别严格的应用，只需要通过廉价的pc server来扩展Slave的数量，将读压力分散到多台Slave的机器上面，即可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库应用系统中的读压力要比写压力大的多。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似的方案解决数据库瓶颈问题。

第二种：Mysql Cluster

MySQL Cluster 由一组计算机构成，每台计算机上均运行着多种进程，包括 MySQL 服务器，NDB Cluster的数据节点，管理服务器，以及（可能）专门的数据访问程序。
由于MySQL Cluster架构复杂，部署费时（通常需要DBA几个小时的时间才能完成搭建），而依靠 MySQL Cluster Manager 只需一个命令即可完成，但 MySQL Cluster Manager 是收费的。并且业内资深人士认为NDB 不适合大多数业务场景，而且有安全问题。因此，使用的人数较少。

第三种：Heartbeat+双主从复制

heartbeat 是 Linux-HA 工程的一个组件,heartbeat 最核心的包括两个部分：心跳监测和资源接管。在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务

第四种：HeartBeat+DRBD+Mysql

DRBD 是通过网络来实现块设备的数据镜像同步的一款开源 Cluster 软件，它自动完成网络中两个不同服务
器上的磁盘同步，相对于 binlog 日志同步，它是更底层的磁盘同步，理论上 DRDB 适合很多文件型系统的高可
用。

第五种：Lvs+keepalived+双主复制

Lvs 是一个虚拟的服务器集群系统，可以实现 LINUX 平台下的简单负载均衡。keepalived 是一个类似于
layer3, 4 & 5 交换机制的软件，主要用于主机与备机的故障转移，这是一种适用面很广的负载均衡和高可用方
案，最常用于 Web 系统。

参考：
https://blog.csdn.net/wzy0623/article/details/81015707

第六种:MariaDB Galera

MariaDB Galera Cluster 是一套在mysql innodb存储引擎上面实现multi-master及数据实时同步的系统架构，业务层面无需做读写分离工作，数据库读写压力都能按照既定的规则分发到 各个节点上去。在数据方面完全兼容 MariaDB 和 MySQL。

该架构主要有以下几种特性：
(1).同步复制 Synchronous replication
(2).Active-active multi-master 拓扑逻辑
(3).可对集群中任一节点进行数据读写
(4).自动成员控制，故障节点自动从集群中移除
(5).自动节点加入
(6).真正并行的复制，基于行级
(7).直接客户端连接，原生的 MySQL 接口
(8).每个节点都包含完整的数据副本
(9).多台数据库中数据同步由 wsrep 接口实现

其局限性体现在以下几点：
(1).目前的复制仅仅支持InnoDB存储引擎,任何写入其他引擎的表，包括mysql.*表将不会复制,但是DDL语句会被复制的,因此创建用户将会被复制,但是insert into mysql.user…将不会被复制的.
(2).DELETE操作不支持没有主键的表,没有主键的表在不同的节点顺序将不同,如果执行SELECT…LIMIT… 将出现不同的结果集.
(3).在多主环境下LOCK/UNLOCK TABLES不支持,以及锁函数GET_LOCK(), RELEASE_LOCK()…
(4).查询日志不能保存在表中。如果开启查询日志，只能保存到文件中。
(5).允许最大的事务大小由wsrep_max_ws_rows和wsrep_max_ws_size定义。任何大型操作将被拒绝。如大型的LOAD DATA操作。
(6).由于集群是乐观的并发控制，事务commit可能在该阶段中止。如果有两个事务向在集群中不同的节点向同一行写入并提交，失败的节点将中止。对 于集群级别的中止，集群返回死锁错误代码(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
(7).XA事务不支持，由于在提交上可能回滚。
(8).整个集群的写入吞吐量是由最弱的节点限制，如果有一个节点变得缓慢，那么整个集群将是缓慢的。为了稳定的高性能要求，所有的节点应使用统一的硬件。
(9).集群节点建议最少3个。
(10).如果DDL语句有问题将破坏集群。

Mysql存储原理？

MySQL 的常用引擎
1. InnoDB
InnoDB 的存储文件有两个，后缀名分别是 .frm 和 .idb，其中 .frm 是表的定义文件，而 idb 是数据文件。

InnoDB 中存在表锁和行锁，不过行锁是在命中索引的情况下才会起作用。

InnoDB 支持事务，且支持四种隔离级别（读未提交、读已提交、可重复读、串行化），默认的为可重复读；而在 Oracle 数据库中，只支持串行化级别和读已提交这两种级别，其中默认的为读已提交级别。

2. Myisam
Myisam 的存储文件有三个，后缀名分别是 .frm、.MYD、MYI，其中 .frm 是表的定义文件，.MYD 是数据文件，.MYI 是索引文件。

Myisam 只支持表锁，且不支持事务。Myisam 由于有单独的索引文件，在读取数据方面的性能很高 。

3. 存储结构
InnoDB 和 Myisam 都是用 B+Tree 来存储数据的。

MySQL 的数据、索引存储结构
1. 数据存储的原理（硬盘）
信息存储在硬盘里，硬盘是由很多的盘片组成，通过盘片表面的磁性物质来存储数据。

把盘片放在显微镜下放大，可以看到盘片表面是凹凸不平的，凸起的地方被磁化，代表数字 1，凹的地方没有被磁化，代表数字 0，因此硬盘可以通过二进制的形式来存储表示文字、图片等的信息。

硬盘有很多种，但是都是由盘片、磁头、盘片主轴、控制电机、磁头控制器、数据转换器、接口、缓存等几个部分组成。

所有的盘片都固定在一个旋转轴上，这个轴即盘片主轴。

所有的盘片之间是绝对平行的，在每个盘片的盘面上都有一个磁头，磁头与盘片之间的距离比头发丝的直径还小。

所有的磁头连在一个磁头控制器上，由磁头控制器负责各个磁头的运动，磁头可沿盘片的半径方向移动，实际上是斜切运动，每个磁头同一时刻必须是同轴的，即从正上方往下看，所有磁头任何时候都是重叠的。

由于技术的发展，目前已经有多磁头独立技术了，在此不考虑此种情况。

盘片以每分钟数千转到上万转的速度在高速运转，这样磁头就能对盘片上的指定位置进行数据的读写操作。

由于硬盘是高精密设备，尘埃是其大敌，所以必须完全密封。

2. 数据读写的原理
硬盘在逻辑上被划分为磁道、柱面以及扇区。

磁头靠近主轴接触的表面，即线速度最小的地方，是一个特殊的区域，它不存放任何数据，称为启停区或者着陆区，启停区外就是数据区。

在最外圈，离主轴最远的地方是 “0” 磁道，硬盘数据的存放就是从最外圈开始的。

在硬盘中还有一个叫 “0” 磁道检测器的构件，它是用来完成硬盘的初始定位。

盘面

硬盘的盘片一般用铝合金材料做基片，硬盘的每一个盘片都有上下两个盘面，一般每个盘面都会得到利用，都可以存储数据，成为有效盘面，也有极个别的硬盘盘面数为单数。

每一个这样的有效盘面都有一个盘面号，按顺序从上至下从 0 开始编号。

在硬盘系统中，盘面号又叫磁头号，因为每一个有效盘面都有一个对应的读写磁头，硬盘的盘片组在 2-14 片不等，通常有 2-3 个盘片。

磁道

磁盘在格式化时被划分成许多同心圆，这些同心圆轨迹叫做磁道。

磁道从外向内从 0 开始顺序编号，硬盘的每一个盘面有 300-1024 个磁道，新式大容量硬盘每面的磁道数更多，信息以脉冲串的形式记录在这些轨迹中，这些同心圆不是连续记录数据，而是被划分成一段段的圆弧。

这些圆弧的角速度一样，由于径向长度不一样，所以线速度也不一样，外圈的线速度较内圈的线速度大，即同样的转速度下，外圈在同样时间段里，划过的圆弧长度要比内圈划过的圆弧长度大。

每段圆弧叫做一个扇区，扇区从 1 开始编号，每个扇区中的数据作为一个单元同时读出或写入。

磁道是看不见的，只是盘面上以特殊形式磁化了的一些磁化区，在磁盘格式化时就已规划完毕。

柱面

所有盘面上的同一磁道构成一个圆柱，通常称作柱面。

每个圆柱上的磁头由上而下从 0 开始编号，数据的读 / 写按柱面进行，即磁头读 / 写数据时首先在同一柱面内从 0 磁头开始进行操作，依次向下在同一柱面的不同盘面即磁头上进行操作。

只有在同一柱面所有的磁头全部读 / 写完毕后磁头才转移到下一柱面（同心圆再往里的柱面），因为选取磁头只需要通过电子切换即可，而选取柱面则必须机械切换，电子切换相当快，比在机械上的磁头向邻近磁道移动快得多。

所以，数据的读 / 写按柱面进行，而不按盘面进行，也就是说，一个磁道写满数据后，就在同一柱面的下一个盘面来写，一个柱面写满后，才移到下一个扇区开始写数据，读数据也按照这种方式进行，这样就提高了硬盘的读 / 写效率。

扇区

操作系统以扇区形式将信息存储在硬盘上，每个扇区包括 512 个字节的数据和一些其他信息，一个扇区有两个主要部分：存储数据地点的标识符和存储数据的数据段。

标识符就是扇区头标，包括组成扇区三维地址的三个数字：盘面号，柱面号，扇区号（块号）。

数据段可分为数据和保护数据的纠错码（ECC）。在初始准备期间，计算机用 512 个虚拟信息字节（实际数据的存放地）和与这些虚拟信息字节相应的 ECC 数字填入这个部分。

3. 访盘请求完成过程
1）确定磁盘地址（柱面号，磁头号，扇区号），内存地址（源 / 目）：

当需要从磁盘读取数据的时候，系统会将数据的逻辑地址传递个磁盘，磁盘的控制电路按照寻址逻辑将逻辑地址翻译成物理地址，即确定要读的数据在哪个磁道，哪个扇区。

2）为了读取这个扇区的数据，需要将磁头放到这个扇区上方，为了实现这一点：

A. 首先必须找到柱面，即磁头需要移动对准相应磁道，这个过程叫做寻道，所耗费时间叫做寻道时间。

B. 然后目标扇区旋转到磁头下，即磁盘旋转将目标扇区旋转到磁头下，这个过程耗费的时间叫做旋转时间。

3）即一次访盘请求（读 / 写）完成过程由三个动作组成：

A. 寻道（时间）：磁头移动定位到指定磁道。

B. 旋转延迟（时间）：等待指定扇区从磁头下旋转经过。

C. 数据传输（时间）：数据在磁盘与内存之间的实际传输。

4. 磁盘的读写原理
系统将文件存储到磁盘上时，按柱面、磁头、扇区的方式进行，即最先是第 1 磁道的第一磁头下的所有扇区，然后是同一柱面的下一个磁头……

一个柱面存储满后就推进到下一个柱面，直到把文件内容全部写入磁盘。

系统也以相同的顺序读出数据，读出数据时通过告诉磁盘控制器要读出扇区所在柱面号、磁头号和扇区号（物理地址的三个组成部分）进行。

5. 减少 I/O 的预读原理
由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费的时间，磁盘的存取速度往往是主存的几百分之一。

因此，为了提高效率，要尽量减少磁盘的 I/O。

磁盘往往不是严格地按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。

这样做的理论依据是计算机科学中著名的局部性原理：

当一个数据被用到时，其附近的数据一般来说也会被马上使用。

程序运行期间所需要的数据通常比较集中。

由于磁盘顺序读取的效率很高（不需要寻道时间，只需要很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高 I/O 效率。

预读的长度一般为页（Page）的整数倍。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储分割为连续的大小相等的块。

每个存储块称为一页（在许多操作系统中，页的大小通常为 4k），主存和磁盘以页为单位交换数据，当程序要读取的数据不在主存中时，会触发一个缺页异常。

此时系统会向磁盘发出读盘信息，磁盘会找到数据的起始位置并向后连续读取一页或几页的数据载入内存中，然后异常返回，程序继续运行。

6. MySQL 的索引
索引是一种用来实现 MySQL 高效获取数据的数据结构。

我们通常所说的在某个字段上建索引，意思就是让 MySQL 对该字段以索引这种数据结构来存储，然后查找的时候就有对应的查找算法。

建索引的根本目的是为了查找的优化，特别是当数据很庞大的时候，一般的查找算法有顺序查找、折半查找、快速查找等。

但是每种查找算法都只能应用于特定的数据结构之上，例如顺序查找依赖于顺序结构，折半查找通过二叉查找树或红黑树实现二分搜索。因此在数据之外，数据库系统还维护着满足特定查找算法的数据结构。

这些数据结构以某种方式引用数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

7. MySQL 的 B+Tree
目前大多数数据库系统及文件系统都采用 B-Tree 或其变种 B+Tree 作为索引结构。

B+ 树索引是 B+ 树在数据库中的一种实现，是最常见也是数据库中使用最为频繁的一种索引。B+ 树中的 B 代表平衡，而不是二叉。

因为 B+ 树是从最早的平衡二叉树演化而来的。B+ 树是由二叉查找树、平衡二叉树（AVLTree）和平衡多路查找树（B-Tree）逐步优化而来。

二叉查找树：左子树的键值小于根的键值，右子树的键值大于根的键值。

AVL 树：平衡二叉树（AVL 树）在符合二叉查找树的条件下，还满足任何节点的两个子树的高度最大差为 1。

平衡多路查找树（B-Tree）：为磁盘等外存储设备设计的一种平衡查找树。

系统从磁盘读取数据到内存时是以磁盘块（block）为基本单位的，位于同一磁盘块中的数据会被一次性读取出来，而不是按需读取。

InnoDB 存储引擎使用页作为数据读取单位，页是其磁盘管理的最小单位，默认 page 大小是 16k。

系统的一个磁盘块的存储空间往往没有这么大，因此 InnoDB 每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小 16KB。

InnDB 在把磁盘数据读入到磁盘时会以页为基本单位，在查询数据时如果一个页中的每条数据都能助于定位数据记录的位置，这将会减少磁盘 I/O 的次数，提高查询效率。

B-Tree 结构的数据可以让系统高效的找到数据所在的磁盘块。

为了描述 B-Tree，首先定义一条数据记录为一个二元组 [key, data]，key 为记录的键值，对于不同数据记录，key 是互不相同的；data 为数据记录除 key 外的数据。

那么 B-Tree 是满足下列条件的数据结构：

1. d 为大于 1 的一个正整数，称为 B-Tree 的度。
2. h 为一个正整数，称为 B-Tree 的高度。
3. 每个非叶子节点由 n-1 个 key 和 n 个指针组成，其中 d<=n<=2d。
4. 每个叶子节点最少包含一个 key 和两个指针，最多包含 2d-1 个 key 和 2d 个指针，叶节点的指针均为 null 。
5. 所有叶节点具有相同的深度，等于树高 h。
6. key 和指针互相间隔，节点两端是指针。
7. 一个节点中的 key 从左到右非递减排列。
8. 所有节点组成树结构。
9. 每个指针要么为 null，要么指向另外一个节点。
10. 如果某个指针在节点 node 最左边且不为 null，则其指向节点的所有 key 小于 v(key1)，其中 v(key1) 为
    node 的第一个 key 的值。
11. 如果某个指针在节点 node 最右边且不为 null，则其指向节点的所有 key 大于 v(keym)，其中 v(keym) 为
    node 的最后一个 key 的值。
12. 如果某个指针在节点 node 的左右相邻 key 分别是 keyi 和 keyi+1 且不为 null，则其指向节点的所有 key
    小于 v(keyi+1) 且大于 v(keyi)。

B-Tree 中的每个节点根据实际情况可以包含大量的关键字信息和分支，例：

每个节点占用一个盘块的磁盘空间，一个节点上有两个升序排序的关键字和三个指向子树根节点的指针，指针存储的是子节点所在磁盘块的地址。

两个关键词划分成的三个范围域对应三个指针指向的子树的数据的范围域。

以根节点为例，关键字为 17 和 35，P1 指针指向的子树的数据范围为小于 17，P2 指针指向的子树的数据范围为 17~35，P3 指针指向的子树的数据范围为大于 35。

模拟查找关键字 29 的过程：

1. 根据根节点找到磁盘块 1，读入内存。【磁盘 I/O 操作第 1 次】
2. 比较关键字 29 在区间（17,35），找到磁盘块 1 的指针 P2。
3. 根据 P2 指针找到磁盘块 3，读入内存。【磁盘 I/O 操作第 2 次】
4. 比较关键字 29 在区间（26,30），找到磁盘块 3 的指针 P2。
5. 根据 P2 指针找到磁盘块 8，读入内存。【磁盘 I/O 操作第 3 次】
6. 在磁盘块 8 中的关键字列表中找到关键字 29。

MySQL 的 InnoDB 存储引擎在设计时是将根节点常驻内存的，因此力求达到树的深度不超过 3，也就是说 I/O 不需要超过 3 次。

分析上面过程，发现需要 3 次磁盘 I/O 操作，和 3 次内存查找操作。由于内存中的关键字是一个有序表结构，可以利用二分法查找提高效率。

而 3 次磁盘 I/O 操作是影响整个 B-Tree 查找效率的决定因素。

B-Tree 相对于 AVLTree 缩减了节点个数，使每次磁盘 I/O 取到内存的数据都发挥了作用，从而提高了查询效率。

B+Tree 是在 B-Tree 基础上的一种优化，使其更适合实现外存储索引结构，InnoDB 存储引擎就是用 B+Tree 实现其索引结构。

在 B-Tree 中，每个节点中有 key，也有 data，而每一个页的存储空间是有限的，如果 data 数据较大时将会导致每个节点（即一个页）能存储的 key 的数量很小。

当存储的数据量很大时同样会导致 B-Tree 的深度较大，增大查询时的磁盘 I/O 次数，进而影响查询效率。

在 B+Tree 中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储 key 值信息，这样可以大大加大每个节点存储的 key 值数量，降低 B+Tree 的高度。

B+Tree 在 B-Tree 的基础上有两点变化：

1. 数据是存在叶子节点中的；
2. 数据节点之间是有指针指向的。

由于 B+Tree 的非叶子节点只存储键值信息，假设每个磁盘块能存储 4 个键值及指针信息，则变成 B+Tree 后其结构如下图所示：

通常在 B+Tree 上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。

因此可以对 B+Tree 进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。

8. Myisam 中的 B+Tree
Myisam 引擎也是采用的 B+Tree 结构来作为索引结构。

由于 Myisam 中的索引和数据分别存放在不同的文件，所以在索引树中的叶子节点中存的数据是该索引对应的数据记录的地址，由于数据与索引不在一起，所以 Myisam 是非聚簇索引。

9. InnoDB 中的 B+Tree
InnoDB 是以 ID 为索引的数据存储。

采用 InnoDB 引擎的数据存储文件有两个，一个定义文件，一个是数据文件。

InnoDB 通过 B+Tree 结构对 ID 建索引，然后在叶子节点中存储记录。

若建索引的字段不是主键 ID，则对该字段建索引，然后在叶子节点中存储的是该记录的主键，然后通过主键索引找到对应的记录。

MySQL 的相关优化
1. MySQL 性能优化：组成、表的设计
开启查询缓存。避免某些 SQL 函数直接在 SQL 语句中使用，从而导致 Mysql 缓存失效。

避免画蛇添足。目的是什么就取什么，例如某个逻辑是只需要判断是否存在女性，若是查到了一条即可，勿要全部都查一遍，此时要善用 limit。

建合适的索引。所以要建在合适的地方，合适的对象上。经常操作 / 比较 / 判断的字段应该建索引。

字段大小合宜。字段的取值是有限而且是固定的，这种情况下可以用 enum，IP 字段可以用 unsigned int 来存储。

表的设计。垂直分割表，使得固定表与变长表分割，从而降低表的复杂度和字段的数目。

2. SQL 语句优化：避免全表扫描
建索引：一般在 where 及 order by 中涉及到的列上建索引，尽量不要对可以重复的字段建索引。

尽量避免在 where 中使用 !（<>）或 or，也不要进行 null 值判断。

尽量避免在 where 中对字段进行函数操作、表达式操作。

尽量避免使用 like- %，在此种情况下可以进行全文检索。

Mysql数据库隔离级别？

一、数据库事务隔离级别

数据库事务的隔离级别有4个，由低到高依次为Read uncommitted 、Read committed 、Repeatable read 、Serializable ，这四个级别可以逐个解决脏读 、不可重复读 、幻读 这几类问题。

隔离级别	脏读	不可重复读	幻读
Read uncommitted	√	√	√
Read committed	×	√	√
Repeatable read	×	×	√
Serializable	×	×	×

注意：我们讨论隔离级别的场景，主要是在多个事务并发 的情况下，因此，接下来的讲解都围绕事务并发。

Read uncommitted 读未提交
公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而singo正好去查看账户，发现工资已经到账，是5000元整，非常高 兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有 2000元，singo空欢喜一场。

出现上述情况，即我们所说的脏读 ，两个并发的事务，“事务A：领导给singo发工资”、“事务B：singo查询工资账户”，事务B读取了事务A尚未提交的数据。

当隔离级别设置为Read uncommitted 时，就可能出现脏读，如何避免脏读，请看下一个隔离级别。

Read committed 读提交
singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好在网上转账，把singo工资卡的2000元转到另一账户，并在 singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有钱，扣款失败，singo十分纳闷，明明卡里有钱，为 何…

出现上述情况，即我们所说的不可重复读 ，两个并发的事务，“事务A：singo消费”、“事务B：singo的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。

当隔离级别设置为Read committed 时，避免了脏读，但是可能会造成不可重复读。

大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。

Repeatable read 重复读
当隔离级别设置为Repeatable read 时，可以避免不可重复读。当singo拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），singo的老婆就不可能对该记录进行修改，也就是singo的老婆不能在此时转账。

虽然Repeatable read避免了不可重复读，但还有可能出现幻读 。

singo的老婆工作在银行部门，她时常通过银行内部系统查看singo的信用卡消费记录。有一天，她正在查询到singo当月信用卡的总消费金额 （select sum(amount) from transaction where month = 本月）为80元，而singo此时正好在外面胡吃海塞后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction … ），并提交了事务，随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，singo的老婆很诧异，以为出 现了幻觉，幻读就这样产生了。

注：Mysql的默认隔离级别就是Repeatable read。

Serializable 序列化
Serializable 是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻像读。

二、脏读、幻读、不可重复读

1.脏读：
脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

2.不可重复读：
是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。（即不能读到相同的数据内容）
例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题。

3.幻读:
是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象
发生了幻觉一样。
例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。

———————————————— 版权声明：本文为CSDN博主「jiesa」的原创文章，遵循 CC 4.0 BY-SA
版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/JIESA/article/details/51317164

Mysql如何实现ACID？

事务是MySQL等关系型数据库区别于NoSQL的重要方面，是保证数据一致性的重要手段。本文将首先介绍MySQL事务相关的基础概念，然后介绍事务的ACID特性，并分析其实现原理。

MySQL博大精深，文章疏漏之处在所难免，欢迎批评指正。

一、基础概念
事务（Transaction）是访问和更新数据库的程序执行单元；事务中可能包含一个或多个sql语句，这些语句要么都执行，要么都不执行。作为一个关系型数据库，MySQL支持事务，本文介绍基于MySQL5.6。

首先回顾一下MySQL事务的基础知识。

1. 逻辑架构和存储引擎

如上图所示，MySQL服务器逻辑架构从上往下可以分为三层：

（1）第一层：处理客户端连接、授权认证等。

（2）第二层：服务器层，负责查询语句的解析、优化、缓存以及内置函数的实现、存储过程等。

（3）第三层：存储引擎，负责MySQL中数据的存储和提取。MySQL中服务器层不管理事务，事务是由存储引擎实现的。MySQL支持事务的存储引擎有InnoDB、NDB Cluster等，其中InnoDB的使用最为广泛；其他存储引擎不支持事务，如MyIsam、Memory等。

如无特殊说明，后文中描述的内容都是基于InnoDB。

2. 提交和回滚
典型的MySQL事务是如下操作的：

start transaction;
……  #一条或多条sql语句
commit;

其中start transaction标识事务开始，commit提交事务，将执行结果写入到数据库。如果sql语句执行出现问题，会调用rollback，回滚所有已经执行成功的sql语句。当然，也可以在事务中直接使用rollback语句进行回滚。

自动提交

MySQL中默认采用的是自动提交（autocommit）模式，如下所示：

在自动提交模式下，如果没有start transaction显式地开始一个事务，那么每个sql语句都会被当做一个事务执行提交操作。

通过如下方式，可以关闭autocommit；需要注意的是，autocommit参数是针对连接的，在一个连接中修改了参数，不会对其他连接产生影响。

如果关闭了autocommit，则所有的sql语句都在一个事务中，直到执行了commit或rollback，该事务结束，同时开始了另外一个事务。

特殊操作

在MySQL中，存在一些特殊的命令，如果在事务中执行了这些命令，会马上强制执行commit提交事务；如DDL语句(create table/drop table/alter/table)、lock tables语句等等。

不过，常用的select、insert、update和delete命令，都不会强制提交事务。

3. ACID特性
ACID是衡量事务的四个特性：

• 原子性（Atomicity，或称不可分割性）
• 一致性（Consistency）
• 隔离性（Isolation）
• 持久性（Durability）

按照严格的标准，只有同时满足ACID特性才是事务；但是在各大数据库厂商的实现中，真正满足ACID的事务少之又少。例如MySQL的NDB Cluster事务不满足持久性和隔离性；InnoDB默认事务隔离级别是可重复读，不满足隔离性；Oracle默认的事务隔离级别为READ COMMITTED，不满足隔离性……因此与其说ACID是事务必须满足的条件，不如说它们是衡量事务的四个维度。

下面将详细介绍ACID特性及其实现原理；为了便于理解，介绍的顺序不是严格按照A-C-I-D。

二、原子性

1. 定义
   原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么都不做；如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。

2. 实现原理：undo log
在说明原子性原理之前，首先介绍一下MySQL的事务日志。MySQL的日志有很多种，如二进制日志、错误日志、查询日志、慢查询日志等，此外InnoDB存储引擎还提供了两种事务日志：redo log(重做日志)和undo log(回滚日志)。其中redo log用于保证事务持久性；undo log则是事务原子性和隔离性实现的基础。

下面说回undo log。实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的sql语句。InnoDB实现回滚，靠的是undo log：当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

undo log属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚时，InnoDB会根据undo log的内容做与之前相反的工作：对于每个insert，回滚时会执行delete；对于每个delete，回滚时会执行insert；对于每个update，回滚时会执行一个相反的update，把数据改回去。

以update操作为例：当事务执行update时，其生成的undo log中会包含被修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前后的值等信息，回滚时便可以使用这些信息将数据还原到update之前的状态。

三、持久性

1. 定义
   持久性是指事务一旦提交，它对数据库的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

2. 实现原理：redo log
redo log和undo log都属于InnoDB的事务日志。下面先聊一下redo log存在的背景。

InnoDB作为MySQL的存储引擎，数据是存放在磁盘中的，但如果每次读写数据都需要磁盘IO，效率会很低。为此，InnoDB提供了缓存(Buffer Pool)，Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）。

Buffer Pool的使用大大提高了读写数据的效率，但是也带了新的问题：如果MySQL宕机，而此时Buffer Pool中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。

于是，redo log被引入来解决这个问题：当数据修改时，除了修改Buffer Pool中的数据，还会在redo log记录这次操作；当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复。redo log采用的是WAL（Write-ahead logging，预写式日志），所有修改先写入日志，再更新到Buffer Pool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求。

既然redo log也需要在事务提交时将日志写入磁盘，为什么它比直接将Buffer Pool中修改的数据写入磁盘(即刷脏)要快呢？主要有以下两方面的原因：

（1）刷脏是随机IO，因为每次修改的数据位置随机，但写redo log是追加操作，属于顺序IO。

（2）刷脏是以数据页（Page）为单位的，MySQL默认页大小是16KB，一个Page上一个小修改都要整页写入；而redo log中只包含真正需要写入的部分，无效IO大大减少。

3. redo log与binlog
   我们知道，在MySQL中还存在binlog(二进制日志)也可以记录写操作并用于数据的恢复，但二者是有着根本的不同的：

（1）作用不同：redo log是用于crash recovery的，保证MySQL宕机也不会影响持久性；binlog是用于point-in-time recovery的，保证服务器可以基于时间点恢复数据，此外binlog还用于主从复制。

（2）层次不同：redo log是InnoDB存储引擎实现的，而binlog是MySQL的服务器层(可以参考文章前面对MySQL逻辑架构的介绍)实现的，同时支持InnoDB和其他存储引擎。

（3）内容不同：redo log是物理日志，内容基于磁盘的Page；binlog的内容是二进制的，根据binlog_format参数的不同，可能基于sql语句、基于数据本身或者二者的混合。

（4）写入时机不同：binlog在事务提交时写入；redo log的写入时机相对多元：

前面曾提到：当事务提交时会调用fsync对redo log进行刷盘；这是默认情况下的策略，修改innodb_flush_log_at_trx_commit参数可以改变该策略，但事务的持久性将无法保证。
除了事务提交时，还有其他刷盘时机：如master thread每秒刷盘一次redo log等，这样的好处是不一定要等到commit时刷盘，commit速度大大加快。

四、隔离性
1. 定义
与原子性、持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。隔离性是指，事务内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰。严格的隔离性，对应了事务隔离级别中的Serializable (可串行化)，但实际应用中出于性能方面的考虑很少会使用可串行化。

隔离性追求的是并发情形下事务之间互不干扰。简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可以分为两个方面：

• (一个事务)写操作对(另一个事务)写操作的影响：锁机制保证隔离性
• (一个事务)写操作对(另一个事务)读操作的影响：MVCC保证隔离性

2. 锁机制
首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个事务对数据进行写操作，InnoDB通过锁机制来保证这一点。

锁机制的基本原理可以概括为：事务在修改数据之前，需要先获得相应的锁；获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。

行锁与表锁

按照粒度，锁可以分为表锁、行锁以及其他位于二者之间的锁。表锁在操作数据时会锁定整张表，并发性能较差；行锁则只锁定需要操作的数据，并发性能好。但是由于加锁本身需要消耗资源(获得锁、检查锁、释放锁等都需要消耗资源)，因此在锁定数据较多情况下使用表锁可以节省大量资源。MySQL中不同的存储引擎支持的锁是不一样的，例如MyIsam只支持表锁，而InnoDB同时支持表锁和行锁，且出于性能考虑，绝大多数情况下使用的都是行锁。

如何查看锁信息

有多种方法可以查看InnoDB中锁的情况，例如：

select * from information_schema.innodb_locks; #锁的概况
show engine innodb status; #InnoDB整体状态，其中包括锁的情况

下面来看一个例子：

#在事务A中执行：
start transaction;
update account SET balance = 1000 where id = 1;
#在事务B中执行：
start transaction;
update account SET balance = 2000 where id = 1;

此时查看锁的情况：

show engine innodb status查看锁相关的部分：

通过上述命令可以查看事务24052和24053占用锁的情况；其中lock_type为RECORD，代表锁为行锁(记录锁)；lock_mode为X，代表排它锁(写锁)。

除了排它锁(写锁)之外，MySQL中还有共享锁(读锁)的概念。由于本文重点是MySQL事务的实现原理，因此对锁的介绍到此为止，后续会专门写文章分析MySQL中不同锁的区别、使用场景等，欢迎关注。

介绍完写操作之间的相互影响，下面讨论写操作对读操作的影响。

3. 脏读、不可重复读和幻读
首先来看并发情况下，读操作可能存在的三类问题：

（1）脏读：当前事务(A)中可以读到其他事务(B)未提交的数据（脏数据），这种现象是脏读。举例如下（以账户余额表为例）：

（2）不可重复读：在事务A中先后两次读取同一个数据，两次读取的结果不一样，这种现象称为不可重复读。脏读与不可重复读的区别在于：前者读到的是其他事务未提交的数据，后者读到的是其他事务已提交的数据。举例如下：

（3）幻读：在事务A中按照某个条件先后两次查询数据库，两次查询结果的条数不同，这种现象称为幻读。不可重复读与幻读的区别可以通俗的理解为：前者是数据变了，后者是数据的行数变了。举例如下：

4. 事务隔离级别
SQL标准中定义了四种隔离级别，并规定了每种隔离级别下上述几个问题是否存在。一般来说，隔离级别越低，系统开销越低，可支持的并发越高，但隔离性也越差。隔离级别与读问题的关系如下：

在实际应用中，读未提交在并发时会导致很多问题，而性能相对于其他隔离级别提高却很有限，因此使用较少。可串行化强制事务串行，并发效率很低，只有当对数据一致性要求极高且可以接受没有并发时使用，因此使用也较少。因此在大多数数据库系统中，默认的隔离级别是读已提交(如Oracle)或可重复读（后文简称RR）。

可以通过如下两个命令分别查看全局隔离级别和本次会话的隔离级别：

InnoDB默认的隔离级别是RR，后文会重点介绍RR。需要注意的是，在SQL标准中，RR是无法避免幻读问题的，但是InnoDB实现的RR避免了幻读问题。

5. MVCC
RR解决脏读、不可重复读、幻读等问题，使用的是MVCC：MVCC全称Multi-Version Concurrency Control，即多版本的并发控制协议。下面的例子很好的体现了MVCC的特点：在同一时刻，不同的事务读取到的数据可能是不同的(即多版本)——在T5时刻，事务A和事务C可以读取到不同版本的数据。

MVCC最大的优点是读不加锁，因此读写不冲突，并发性能好。InnoDB实现MVCC，多个版本的数据可以共存，主要是依靠数据的隐藏列(也可以称之为标记位)和undo log。其中数据的隐藏列包括了该行数据的版本号、删除时间、指向undo log的指针等等；当读取数据时，MySQL可以通过隐藏列判断是否需要回滚并找到回滚需要的undo log，从而实现MVCC；隐藏列的详细格式不再展开。

下面结合前文提到的几个问题分别说明。

（1）脏读

当事务A在T3时间节点读取zhangsan的余额时，会发现数据已被其他事务修改，且状态为未提交。此时事务A读取最新数据后，根据数据的undo log执行回滚操作，得到事务B修改前的数据，从而避免了脏读。

（2）不可重复读

当事务A在T2节点第一次读取数据时，会记录该数据的版本号（数据的版本号是以row为单位记录的），假设版本号为1；当事务B提交时，该行记录的版本号增加，假设版本号为2；当事务A在T5再一次读取数据时，发现数据的版本号（2）大于第一次读取时记录的版本号（1），因此会根据undo log执行回滚操作，得到版本号为1时的数据，从而实现了可重复读。

（3）幻读

InnoDB实现的RR通过next-key lock机制避免了幻读现象。

next-key lock是行锁的一种，实现相当于record lock(记录锁) + gap lock(间隙锁)；其特点是不仅会锁住记录本身(record lock的功能)，还会锁定一个范围(gap lock的功能)。当然，这里我们讨论的是不加锁读：此时的next-key lock并不是真的加锁，只是为读取的数据增加了标记（标记内容包括数据的版本号等）；准确起见姑且称之为类next-key lock机制。还是以前面的例子来说明：

当事务A在T2节点第一次读取0<id<5数据时，标记的不只是id=1的数据，而是将范围(0,5)进行了标记，这样当T5时刻再次读取0<id<5数据时，便可以发现id=2的数据比之前标记的版本号更高，此时再结合undo log执行回滚操作，避免了幻读。

6. 总结
概括来说，InnoDB实现的RR，通过锁机制、数据的隐藏列、undo log和类next-key lock，实现了一定程度的隔离性，可以满足大多数场景的需要。不过需要说明的是，RR虽然避免了幻读问题，但是毕竟不是Serializable，不能保证完全的隔离，下面是一个例子，大家可以自己验证一下。

五、一致性

1. 基本概念
一致性是指事务执行结束后，数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。数据库的完整性约束包括但不限于：实体完整性（如行的主键存在且唯一）、列完整性（如字段的类型、大小、长度要符合要求）、外键约束、用户自定义完整性（如转账前后，两个账户余额的和应该不变）。

2. 实现
可以说，一致性是事务追求的最终目标：前面提到的原子性、持久性和隔离性，都是为了保证数据库状态的一致性。此外，除了数据库层面的保障，一致性的实现也需要应用层面进行保障。

实现一致性的措施包括：

保证原子性、持久性和隔离性，如果这些特性无法保证，事务的一致性也无法保证
数据库本身提供保障，例如不允许向整形列插入字符串值、字符串长度不能超过列的限制等
应用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有增加接收者的余额，无论数据库实现的多么完美，也无法保证状态的一致

六、总结

下面总结一下ACID特性及其实现原理：

• 原子性：语句要么全执行，要么全不执行，是事务最核心的特性，事务本身就是以原子性来定义的；实现主要基于undo log
• 持久性：保证事务提交后不会因为宕机等原因导致数据丢失；实现主要基于redo log
• 隔离性：保证事务执行尽可能不受其他事务影响；InnoDB默认的隔离级别是RR，RR的实现主要基于锁机制、数据的隐藏列、undo
  log和类next-key lock机制
• 一致性：事务追求的最终目标，一致性的实现既需要数据库层面的保障，也需要应用层面的保障

Mysql千万级优化？

优化优先级与实施顺序核心原则：成本由低到高，影响由小到大

1. SQL与索引优化（首要且基础）

技术要点：

• SQL语句重构：消除子查询嵌套、减少JOIN数量、避免SELECT *
• 索引策略：
  • 创建复合索引时遵循最左前缀原则
  • 利用覆盖索引避免回表查询
  • 定期分析索引使用情况，删除冗余索引
• 执行计划分析：使用EXPLAIN分析查询路径，确保使用最优索引

常见误区：

❌ 只根据SQL创建索引，缺乏整体优化思维
✅ 结合业务场景，综合考虑查询频率、数据分布、索引维护成本

2. 缓存层优化

实施策略：

• Redis/Memcached：缓存热点数据和查询结果
• 应用层缓存：合理设置缓存失效策略
• 预热机制：重要数据提前加载到缓存

3. 读写分离架构

技术实现：

• 主从复制：一主多从，读写分离
• 应用层路由：根据SQL类型分发到不同节点
• 中间件选择：
  • ProxySQL（推荐）：高性能、功能完善
  • MyCat：功能丰富但复杂度高
  • （原答案中的Atlas已停止维护）

4. MySQL分区表（结构化优化）

实施要点：

-- 按时间范围分区示例
CREATE TABLE large_table (id INT,create_time DATETIME,data VARCHAR(100)
) PARTITION BY RANGE (YEAR(create_time)) (PARTITION p2020 VALUES LESS THAN (2021),PARTITION p2021 VALUES LESS THAN (2022),PARTITION p2022 VALUES LESS THAN (2023)
);

关键注意事项：

• 查询必须包含分区键，否则全表扫描
• 避免跨分区查询
• 定期维护分区（删除旧分区、新增分区）

5. 垂直拆分（业务层面优化）

实施策略：

• 模块解耦：按业务功能拆分数据库
• 微服务架构：每个服务独立数据库
• 数据归类：高频访问与低频访问数据分离

6. 水平切分（终极解决方案）

核心技术要点：

• 分片键选择：选择分布均匀、查询频繁的字段
• 分片算法：哈希分片、范围分片、一致性哈希
• 应用改造：SQL路由、分布式事务处理
• 数据迁移：平滑扩容方案

存储引擎优化策略

InnoDB vs MyISAM对比分析

特性	InnoDB	MyISAM
事务支持	✅ 支持ACID	❌ 不支持
锁机制	行锁	表锁
数据存储	聚簇索引	堆表
MVCC支持	✅ 支持	❌ 不支持
崩溃恢复	✅ 自动恢复	❌ 需要修复

InnoDB优化要点

索引优化：

• 主键设计：递增主键避免页分裂
• 二级索引：利用索引覆盖技术
• 延迟关联：先用索引定位，再回表查询

配置优化：

# 缓冲池设置（建议为物理内存70-80%）
innodb_buffer_pool_size = 4G
# 日志文件大小
innodb_log_file_size = 256M
# 并发线程数
innodb_thread_concurrency = 16

关键技术概念解析

索引覆盖（Index Covering）

-- 好的示例：查询字段都在索引中
SELECT id, name FROM users WHERE age > 25;
-- 假设索引为 INDEX(age, id, name)-- 避免的示例：需要回表查询
SELECT * FROM users WHERE age > 25;

一致性非锁定读

• 快照读：普通SELECT使用MVCC读取快照数据
• 当前读：UPDATE/DELETE/SELECT FOR UPDATE读取最新数据

实施建议

优化流程图

监控与评估

• 性能指标：QPS、响应时间、连接数
• 系统指标：CPU、内存、磁盘I/O
• 慢查询日志：定期分析优化

总结

千万级数据优化是一个系统工程，需要：

1. 技术深度：精通SQL优化、索引原理、存储引擎特性
2. 架构思维：理解分布式系统设计原则
3. 业务理解：结合实际业务场景制定优化策略
4. 循序渐进：按照成本效益原则逐步实施

记住：最好的优化是找到技术实现与业务需求的最佳平衡点。

单表优化

除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量：

字段

• 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED
• VARCHAR的长度只分配真正需要的空间
• 使用枚举或整数代替字符串类型
• 尽量使用TIMESTAMP而非DATETIME，
• 单表不要有太多字段，建议在20以内
• 避免使用NULL字段，很难查询优化且占用额外索引空间
• 用整型来存IP

索引

• 索引并不是越多越好，要根据查询有针对性的创建，考虑在WHERE和ORDER
  BY命令上涉及的列建立索引，可根据EXPLAIN来查看是否用了索引还是全表扫描
• 应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃使用索引而进行全表扫描
• 值分布很稀少的字段不适合建索引，例如"性别"这种只有两三个值的字段
• 字符字段只建前缀索引
• 字符字段最好不要做主键
• 不用外键，由程序保证约束
• 尽量不用UNIQUE，由程序保证约束
• 使用多列索引时主意顺序和查询条件保持一致，同时删除不必要的单列索引

查询SQL

• 可通过开启慢查询日志来找出较慢的SQL
• 不做列运算：SELECT id WHERE age + 1 =
  10，任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等等，查询时要尽可能将操作移至等号右边
• sql语句尽可能简单：一条sql只能在一个cpu运算；大语句拆小语句，减少锁时间；一条大sql可以堵死整个库
• 不用SELECT *
• OR改写成IN：OR的效率是n级别，IN的效率是log(n)级别，in的个数建议控制在200以内
• 不用函数和触发器，在应用程序实现
• 避免%xxx式查询
• 少用JOIN
• 使用同类型进行比较，比如用’123’和’123’比，123和123比
• 尽量避免在WHERE子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描
• 对于连续数值，使用BETWEEN不用IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5
• 列表数据不要拿全表，要使用LIMIT来分页，每页数量也不要太大

引擎
目前广泛使用的是MyISAM和InnoDB两种引擎：

MyISAM
MyISAM引擎是MySQL 5.1及之前版本的默认引擎，它的特点是：

• 不支持行锁，读取时对需要读到的所有表加锁，写入时则对表加排它锁
• 不支持事务
• 不支持外键
• 不支持崩溃后的安全恢复
• 在表有读取查询的同时，支持往表中插入新纪录
• 支持BLOB和TEXT的前500个字符索引，支持全文索引
• 支持延迟更新索引，极大提升写入性能
• 对于不会进行修改的表，支持压缩表，极大减少磁盘空间占用

InnoDB
InnoDB在MySQL 5.5后成为默认索引，它的特点是：

• 支持行锁，采用MVCC来支持高并发
• 支持事务
• 支持外键
• 支持崩溃后的安全恢复
• 不支持全文索引

总体来讲，MyISAM适合SELECT密集型的表，而InnoDB适合INSERT和UPDATE密集型的表

系统调优参数
可以使用下面几个工具来做基准测试：

• sysbench：一个模块化，跨平台以及多线程的性能测试工具
• iibench-mysql：基于 Java 的 MySQL/Percona/MariaDB 索引进行插入性能测试工具
• tpcc-mysql：Percona开发的TPC-C测试工具

具体的调优参数内容较多，具体可参考官方文档，这里介绍一些比较重要的参数：

• back_log：back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。也就是说，如果MySql的连接数据达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log，如果等待连接的数量超过back_log，将不被授予连接资源。可以从默认的50升至500
• wait_timeout：数据库连接闲置时间，闲置连接会占用内存资源。可以从默认的8小时减到半小时
• max_user_connection: 最大连接数，默认为0无上限，最好设一个合理上限
• thread_concurrency：并发线程数，设为CPU核数的两倍
• skip_name_resolve：禁止对外部连接进行DNS解析，消除DNS解析时间，但需要所有远程主机用IP访问
• key_buffer_size：索引块的缓存大小，增加会提升索引处理速度，对MyISAM表性能影响最大。对于内存4G左右，可设为256M或384M，通过查询show
  status like ‘key_read%’，保证key_reads / key_read_requests在0.1%以下最好
• innodb_buffer_pool_size：缓存数据块和索引块，对InnoDB表性能影响最大。通过查询show status like
  ‘Innodb_buffer_pool_read%’，保证 (Innodb_buffer_pool_read_requests –
  Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests越高越好
• innodb_additional_mem_pool_size：InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，当数据库对象非常多的时候，适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率，当过小的时候，MySQL会记录Warning信息到数据库的错误日志中，这时就需要该调整这个参数大小
• innodb_log_buffer_size：InnoDB存储引擎的事务日志所使用的缓冲区，一般来说不建议超过32MB
• query_cache_size：缓存MySQL中的ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query
  Cache中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query
  Cache可能会得不偿失。根据命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))进行调整，一般不建议太大，256MB可能已经差不多了，大型的配置型静态数据可适当调大.
  可以通过命令show status like 'Qcache_%'查看目前系统Query catch使用大小
• read_buffer_size：MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。如果对表的顺序扫描请求非常频繁，可以通过增加该变量值以及内存缓冲区大小提高其性能
• sort_buffer_size：MySql执行排序使用的缓冲大小。如果想要增加ORDER
  BY的速度，首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能，可以尝试增加sort_buffer_size变量的大小
• read_rnd_buffer_size：MySql的随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySql会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。但MySql会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。
• record_buffer：每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描，可能想要增加该值
• thread_cache_size：保存当前没有与连接关联但是准备为后面新的连接服务的线程，可以快速响应连接的线程请求而无需创建新的
• table_cache：类似于thread_cache_size，但用来缓存表文件，对InnoDB效果不大，主要用于MyISAM

升级硬件
Scale up，这个不多说了，根据MySQL是CPU密集型还是I/O密集型，通过提升CPU和内存、使用SSD，都能显著提升MySQL性能

读写分离
也是目前常用的优化，从库读主库写，一般不要采用双主或多主引入很多复杂性，尽量采用文中的其他方案来提高性能。同时目前很多拆分的解决方案同时也兼顾考虑了读写分离

缓存
缓存可以发生在这些层次：

• MySQL内部：在系统调优参数介绍了相关设置
• 数据访问层：比如MyBatis针对SQL语句做缓存，而Hibernate可以精确到单个记录，这里缓存的对象主要是持久化对象Persistence
  Object
• 应用服务层：这里可以通过编程手段对缓存做到更精准的控制和更多的实现策略，这里缓存的对象是数据传输对象Data Transfer
  Object
• Web层：针对web页面做缓存
• 浏览器客户端：用户端的缓存

可以根据实际情况在一个层次或多个层次结合加入缓存。这里重点介绍下服务层的缓存实现，目前主要有两种方式：

• 直写式（Write Through）：在数据写入数据库后，同时更新缓存，维持数据库与缓存的一致性。这也是当前大多数应用缓存框架如Spring
  Cache的工作方式。这种实现非常简单，同步好，但效率一般。
• 回写式（Write Back）：当有数据要写入数据库时，只会更新缓存，然后异步批量的将缓存数据同步到数据库上。这种实现比较复杂，需要较多的应用逻辑，同时可能会产生数据库与缓存的不同步，但效率非常高。

表分区
MySQL在5.1版引入的分区是一种简单的水平拆分，用户需要在建表的时候加上分区参数，对应用是透明的无需修改代码

对用户来说，分区表是一个独立的逻辑表，但是底层由多个物理子表组成，实现分区的代码实际上是通过对一组底层表的对象封装，但对SQL层来说是一个完全封装底层的黑盒子。MySQL实现分区的方式也意味着索引也是按照分区的子表定义，没有全局索引

用户的SQL语句是需要针对分区表做优化，SQL条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区，可以通过EXPLAIN PARTITIONS来查看某条SQL语句会落在那些分区上，从而进行SQL优化，如下图5条记录落在两个分区上：

mysql> explain partitions select count(1) from user_partition where id in (1,2,3,4,5);
+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+
| id | select_type | table          | partitions | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+
|  1 | SIMPLE      | user_partition | p1,p4      | range | PRIMARY       | PRIMARY | 8       | NULL |    5 | Using where; Using index |
+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+
1 row in set (0.00 sec)

分区的好处是：

• 可以让单表存储更多的数据
• 分区表的数据更容易维护，可以通过清楚整个分区批量删除大量数据，也可以增加新的分区来支持新插入的数据。另外，还可以对一个独立分区进行优化、检查、修复等操作
• 部分查询能够从查询条件确定只落在少数分区上，速度会很快
• 分区表的数据还可以分布在不同的物理设备上，从而搞笑利用多个硬件设备
• 可以使用分区表赖避免某些特殊瓶颈，例如InnoDB单个索引的互斥访问、ext3文件系统的inode锁竞争
• 可以备份和恢复单个分区

分区的限制和缺点

• 一个表最多只能有1024个分区
• 如果分区字段中有主键或者唯一索引的列，那么所有主键列和唯一索引列都必须包含进来
• 分区表无法使用外键约束
• NULL值会使分区过滤无效

所有分区必须使用相同的存储引擎

分区的类型：

• RANGE分区：基于属于一个给定连续区间的列值，把多行分配给分区
• LIST分区：类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择
• HASH分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算。这个函数可以包含MySQL中有效的、产生非负整数值的任何表达式
• KEY分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值

分区适合的场景有：

最适合的场景数据的时间序列性比较强，则可以按时间来分区，如下所示：

CREATE TABLE members (firstname VARCHAR(25) NOT NULL,lastname VARCHAR(25) NOT NULL,username VARCHAR(16) NOT NULL,email VARCHAR(35),joined DATE NOT NULL
)
PARTITION BY RANGE( YEAR(joined) ) (PARTITION p0 VALUES LESS THAN (1960),PARTITION p1 VALUES LESS THAN (1970),PARTITION p2 VALUES LESS THAN (1980),PARTITION p3 VALUES LESS THAN (1990),PARTITION p4 VALUES LESS THAN MAXVALUE
);

查询时加上时间范围条件效率会非常高，同时对于不需要的历史数据能很容的批量删除。

• 如果数据有明显的热点，而且除了这部分数据，其他数据很少被访问到，那么可以将热点数据单独放在一个分区，让这个分区的数据能够有机会都缓存在内存中，查询时只访问一个很小的分区表，能够有效使用索引和缓存

另外MySQL有一种早期的简单的分区实现 - 合并表（merge table），限制较多且缺乏优化，不建议使用，应该用新的分区机制来替代

垂直拆分
垂直分库是根据数据库里面的数据表的相关性进行拆分，比如：一个数据库里面既存在用户数据，又存在订单数据，那么垂直拆分可以把用户数据放到用户库、把订单数据放到订单库。垂直分表是对数据表进行垂直拆分的一种方式，常见的是把一个多字段的大表按常用字段和非常用字段进行拆分，每个表里面的数据记录数一般情况下是相同的，只是字段不一样，使用主键关联

比如原始的用户表是：

垂直拆分后是：

垂直拆分的优点是：

• 可以使得行数据变小，一个数据块(Block)就能存放更多的数据，在查询时就会减少I/O次数(每次查询时读取的Block 就少)
• 可以达到最大化利用Cache的目的，具体在垂直拆分的时候可以将不常变的字段放一起，将经常改变的放一起
• 数据维护简单

缺点是：

• 主键出现冗余，需要管理冗余列
• 会引起表连接JOIN操作（增加CPU开销）可以通过在业务服务器上进行join来减少数据库压力
• 依然存在单表数据量过大的问题（需要水平拆分）
• 事务处理复杂

水平拆分
概述
水平拆分是通过某种策略将数据分片来存储，分库内分表和分库两部分，每片数据会分散到不同的MySQL表或库，达到分布式的效果，能够支持非常大的数据量。前面的表分区本质上也是一种特殊的库内分表

库内分表，仅仅是单纯的解决了单一表数据过大的问题，由于没有把表的数据分布到不同的机器上，因此对于减轻MySQL服务器的压力来说，并没有太大的作用，大家还是竞争同一个物理机上的IO、CPU、网络，这个就要通过分库来解决

前面垂直拆分的用户表如果进行水平拆分，结果是：

实际情况中往往会是垂直拆分和水平拆分的结合，即将Users_A_M和Users_N_Z再拆成Users和UserExtras，这样一共四张表

水平拆分的优点是:

• 不存在单库大数据和高并发的性能瓶颈
• 应用端改造较少
• 提高了系统的稳定性和负载能力

缺点是：

• 分片事务一致性难以解决
• 跨节点Join性能差，逻辑复杂
• 数据多次扩展难度跟维护量极大

分片原则

• 能不分就不分，参考单表优化
• 分片数量尽量少，分片尽量均匀分布在多个数据结点上，因为一个查询SQL跨分片越多，则总体性能越差，虽然要好于所有数据在一个分片的结果，只在必要的时候进行扩容，增加分片数量
• 分片规则需要慎重选择做好提前规划，分片规则的选择，需要考虑数据的增长模式，数据的访问模式，分片关联性问题，以及分片扩容问题，最近的分片策略为范围分片，枚举分片，一致性Hash分片，这几种分片都有利于扩容
• 尽量不要在一个事务中的SQL跨越多个分片，分布式事务一直是个不好处理的问题
• 查询条件尽量优化，尽量避免Select *
  的方式，大量数据结果集下，会消耗大量带宽和CPU资源，查询尽量避免返回大量结果集，并且尽量为频繁使用的查询语句建立索引。
• 通过数据冗余和表分区赖降低跨库Join的可能

这里特别强调一下分片规则的选择问题，如果某个表的数据有明显的时间特征，比如订单、交易记录等，则他们通常比较合适用时间范围分片，因为具有时效性的数据，我们往往关注其近期的数据，查询条件中往往带有时间字段进行过滤，比较好的方案是，当前活跃的数据，采用跨度比较短的时间段进行分片，而历史性的数据，则采用比较长的跨度存储。

总体上来说，分片的选择是取决于最频繁的查询SQL的条件，因为不带任何Where语句的查询SQL，会遍历所有的分片，性能相对最差，因此这种SQL越多，对系统的影响越大，所以我们要尽量避免这种SQL的产生。

解决方案
由于水平拆分牵涉的逻辑比较复杂，当前也有了不少比较成熟的解决方案。这些方案分为两大类：客户端架构和代理架构。

客户端架构
通过修改数据访问层，如JDBC、Data Source、MyBatis，通过配置来管理多个数据源，直连数据库，并在模块内完成数据的分片整合，一般以Jar包的方式呈现

这是一个客户端架构的例子：

可以看到分片的实现是和应用服务器在一起的，通过修改Spring JDBC层来实现

客户端架构的优点是：

• 应用直连数据库，降低外围系统依赖所带来的宕机风险
• 集成成本低，无需额外运维的组件

缺点是：

• 限于只能在数据库访问层上做文章，扩展性一般，对于比较复杂的系统可能会力不从心
• 将分片逻辑的压力放在应用服务器上，造成额外风险

代理架构
通过独立的中间件来统一管理所有数据源和数据分片整合，后端数据库集群对前端应用程序透明，需要独立部署和运维代理组件

这是一个代理架构的例子：

代理组件为了分流和防止单点，一般以集群形式存在，同时可能需要Zookeeper之类的服务组件来管理

代理架构的优点是：

• 能够处理非常复杂的需求，不受数据库访问层原来实现的限制，扩展性强
• 对于应用服务器透明且没有增加任何额外负载

缺点是：

• 需部署和运维独立的代理中间件，成本高
• 应用需经过代理来连接数据库，网络上多了一跳，性能有损失且有额外风险

各方案比较

4. 最好按大公司->社区->小公司->个人这样的出品方顺序来选择
5. 选择口碑较好的，比如github星数、使用者数量质量和使用者反馈
6. 开源的优先，往往项目有特殊需求可能需要改动源代码

按照上述思路，推荐以下选择：

客户端架构：ShardingJDBC
代理架构：MyCat或者Atlas

兼容MySQL且可水平扩展的数据库
目前也有一些开源数据库兼容MySQL协议，如：

• TiDB
• Cubrid

但其工业品质和MySQL尚有差距，且需要较大的运维投入，如果想将原始的MySQL迁移到可水平扩展的新数据库中，可以考虑一些云数据库：

• 阿里云PetaData
• 阿里云OceanBase
• 腾讯云DCDB

NoSQL
在MySQL上做Sharding是一种戴着镣铐的跳舞，事实上很多大表本身对MySQL这种RDBMS的需求并不大，并不要求ACID，可以考虑将这些表迁移到NoSQL，彻底解决水平扩展问题，例如：

• 日志类、监控类、统计类数据
• 非结构化或弱结构化数据
• 对事务要求不强，且无太多关联操作的数据

索引

Mysql中慢查询如何优化？

MySQL慢查询分析与优化指南

随着业务功能的扩展、用户量的增长以及流量的持续上升，数据存储服务常常面临响应变慢的问题。数据库性能下降的原因多种多样，作为研发人员（RD），快速定位并解决这些问题至关重要。

本文以 MySQL 为例，从多个角度分析可能导致数据库响应变慢的原因，并提供相应的优化方案。

一、慢查询问题定位

1.1 开启慢查询日志（Slow Query Log）

MySQL 默认关闭慢查询日志，可通过以下命令开启：

-- 开启慢查询日志
SET GLOBAL slow_query_log = ON;-- 设置慢查询时间阈值（单位为秒）
SET GLOBAL long_query_time = 0.5;

查看慢查询日志配置信息：

SHOW GLOBAL VARIABLES LIKE 'slow_query_log_file';
SHOW GLOBAL VARIABLES LIKE '%quer%';

输出示例：

+---------------------+-------------------------------------------------------+
| Variable_name       | Value                                                 |
+---------------------+-------------------------------------------------------+
| slow_query_log      | ON                                                    |
| long_query_time     | 0.500000                                              |
| slow_query_log_file | /usr/local/mysql/data/MacintoshdeMacBook-Pro-slow.log |
+---------------------+-------------------------------------------------------+

通过上述配置，系统会自动记录超过设定时间的 SQL 查询语句，便于后续分析。

二、使用 Explain 分析 SQL 执行计划

2.1 示例分析

假设有一个包含 500W 条记录的员工表 emp，在未加索引的字段上进行查询：

SELECT * FROM emp WHERE empname='LsHfFJA';

执行耗时约 2.239 秒，扫描了 4952492 行数据。

使用 EXPLAIN 查看执行计划：

EXPLAIN SELECT * FROM emp WHERE empname='LsHfFJA';

输出结果如下：

+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows    | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
|  1 | SIMPLE      | emp   | ALL  | NULL          | NULL | NULL    | NULL | 4952492 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+

• type = ALL 表示全表扫描，效率极低。
• rows = 4952492 表示预估需要扫描的行数。
• key = NULL 表示未使用任何索引。

这说明当前查询没有合理使用索引，需要优化。

2.2 Explain 关键字段说明

select_type：查询类型（简单、联合、子查询等）

• SIMPLE：简单查询
• PRIMARY：最外层查询
• SUBQUERY：子查询

type：访问类型（重要指标）

• system > const > eq_ref > ref > range > index > ALL

possible_keys：可能使用的索引
key：实际使用的索引
rows：预估扫描行数
Extra：其他额外信息

三、SQL 编写规范与优化建议

3.1 查询语句编写规范

✅ 推荐做法：

• 避免使用 SELECT *：只取需要的字段，减少 IO 和网络开销。
• JOIN 时明确字段：避免回表操作。
• 分页必须带排序条件：防止乱序。
• IN 替换 OR：提高可读性和性能。
• 避免 % 前缀模糊匹配：如 LIKE '%abc' 不走索引。
• LIMIT 大偏移量优化：如 WHERE id > 10000 LIMIT 20。

❌ 禁止行为：

• 全表扫描：如 SELECT * FROM t_name。
• TEXT 字段与普通字段混存：影响读写效率。
• WHERE 中使用函数或类型转换：如 WHERE YEAR(create_time) = 2023 或 WHERE age = '25'。
• 子查询滥用：优先转为 JOIN。
• 外键约束：推荐程序层面实现。

3.2 索引设计规范

✅ 推荐做法：

• 区分度高的列建索引：区分度 > 0.2。
• 组合索引遵循最左前缀原则：高频字段放前面。
• 覆盖索引优化：确保查询字段都在索引中。
• 前缀索引适用于长文本字段：如 LEFT(c_name, N)。
• 索引数量控制在 5 个以内：尤其对写频繁的表。
• 利用索引做排序：避免额外排序步骤。
• 扩展已有索引而非新建：如已有 (a)，新增 (a,b) 可直接修改原索引。

❌ 禁止行为：

• 非必要使用函数或运算符：如 UPPER(name)。
• 字符串字段数值比较：如 '123' = 123。
• 模糊匹配 %value%：无法利用索引。
• 强制依赖数据库外键机制：应在应用层处理。

四、总结与延伸

本文主要围绕 MySQL 慢查询的分析与优化方法 展开，涵盖了以下几个方面：

• 慢查询日志的开启与分析
• Explain 执行计划的理解与使用
• SQL 编写与索引设计的最佳实践

然而，数据库性能问题并不仅限于慢查询本身。后续可以进一步探讨以下内容：

• 读写分离
• 垂直/水平分库分表
• 缓存策略（Redis、Memcached）
• 数据库锁竞争优化
• 数据库参数调优
• 硬件资源升级

这些综合手段将帮助我们构建一个高性能、高可用的数据服务系统。

如需深入学习索引优化策略，可参考文章：《构建高性能索引（策略篇）》

作者建议团队在日常 Code Review 中严格执行上述规范，提升整体 SQL 质量与系统性能。

索引是什么？

索引是对数据库表中一列或多列的值进行排序的一种结构。MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。

简单类比一下，数据库如同书籍，索引如同书籍目录，假如我们需要从书籍查找与 xx 相关的内容，我们可以直接从目录中查找，定位到 xx 内容所在页面，如果目录中没有 xx 相关字符或者没有设置目录（索引），那只能逐字逐页阅读文本查找，效率可想而知。

索引的优缺点

索引可以大大提高MySQL的检索速度，为什么不对表中的每一个列创建一个索引呢？

优点

1. 索引大大减小了服务器需要扫描的数据量，从而大大加快数据的检索速度，这也是创建索引的最主要的原因。
2. 索引可以帮助服务器避免排序和创建临时表
3. 索引可以将随机IO变成顺序IO
4. 索引对于InnoDB（对索引支持行级锁）非常重要，因为它可以让查询锁更少的元组，提高了表访问并发性
   • 关于InnoDB、索引和锁：InnoDB在二级索引上使用共享锁（读锁），但访问主键索引需要排他锁（写锁）
5. 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
6. 可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
7. 在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
8. 通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

缺点

1. 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加
2. 索引需要占物理空间，除了数据表占用数据空间之外，每一个索引还要占用一定的物理空间，如果需要建立聚簇索引，那么需要占用的空间会更大
3. 对表中的数据进行增、删、改的时候，索引也要动态的维护，这就降低了整数的维护速度
4. 如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
5. 对于非常小的表，大部分情况下简单的全表扫描更高效；

索引为什么快？

索引之所以能让查询变快，是因为它把原本要在磁盘上“顺序翻遍整本字典”的线性扫描，变成了在内存里“按目录跳读”的对数级查找。

展开说就是三层提速原理：

1. 少读盘
   数据在机械硬盘上，最坏情况得把 10 万条记录所在的 2 万个数据块全部读一遍；而索引（B+ 树）把这 2 万个块做成一棵高度只有 3～4 层的树，最多读 3～4 个索引块就能把目标行定位出来，磁盘 I/O 从 O(n) 降到 O(log n)。

2. 二分查找
   索引块内部是有序的，因此可以在内存里用二分查找，13 次比较就能在 10 万条记录里找到目标，而全表扫描需要 10 万次比较，差距约 800 倍。

3. 顺序访问变随机访问
   没有索引时，行在磁盘上是“堆”放的，读取行 A 后，下一行 B 可能在任意磁道，磁头得重新寻道；索引把行号或主键顺序存好，一次就能算出目标行的物理地址，直接跳转过去，省掉大量机械等待时间。

代价是：
写操作要同时更新索引，磁盘写次数 ×2；索引本身也占空间；建得过多反而让“目录比字典还厚”，得不偿失。

为什么B+Tree快？

1 ，B+Tree拥有B-Tree的优点,深度浅,数据块大
2 ，因为只在叶子结点存储数据,从而导致扫全表的能力强,因为叶子结点是顺序的,从而导致排序功能更强。
3 ，查询时间相对稳定,因为原因1:平衡二叉树,解决了查询不会受到结点分布的影响, 原因2:因为数据在叶子结点,导致每次查询的深度是一样的(相对于B-Tree)

若采用二叉树:

缺点是:若是一个斜二叉树,查询速度和全表扫描没有区别,图如下,所以查询速度由结点的分布决定

若采用平衡二叉树（认为:二路平衡二叉树）

缺点:太深了:深度决定者io的次数,而io耗时大如若查询8,则需要进行3次io操作太小了:结点存储的信息太小了，从而导致频繁的io操作

若采用多路平衡二叉树:（B-Tree B树）

路数是结点+1,因为这个是判断逻辑来决定如下图,图一是<1:选择p1,=15:则命中,>15:选择p2,图二会导致>35的无法选择。

一个磁盘块的结点个数:一个磁盘块的大小是16K,若节点存储是int型数据(4个字节)加结点的其他信息(如p1 4个字节),一个磁盘块的结点个数:16*1024/(4+4)=2048个结点,路数是2049路，从而解决了太深了和太小的问题

若采用加强版多路平衡二叉树(B+Tree)

和B-Tree区别:
判断逻辑:B+Tree采用的是闭合区间判断,B-Tree采用开合区间结点:B+Tree非叶子

结点:关键字和子节点的引用,叶子结点:存储数据 B-Tree 非叶子结点和叶子结点存储的是关键字,数据和子节点的引用

顺序:B+Tree叶子结点是顺序的,相邻结点存在顺序引用

为什么选择B+Tree
1 B+Tree拥有B-Tree的优点,深度浅,数据块大

2因为只在叶子结点存储数据,从而导致扫全表的能力强,因为叶子结点是顺序的,从而导致排序功能更强。

3查询时间相对稳定,因为原因1:平衡二叉树,解决了查询不会受到结点分布的影响, 原因2:因为数据在叶子结点,导致每次查询的深度是一样的(相对于B-Tree)

B+Tree索引在mysql中的体现形式
体现形式之一: myisam

体现形式之二: innodb

特点:以主键作为索引,同时也是聚集索引:记录在数据库的顺序和物理地址的顺序是一样的

若以name作为索引,则先用辅助索引找到主键,在根据主键找到对应的数据库记录

两者的区别:
Innodb:通过辅助索引找到主键,在通过主键索引来找到记录,
myisam通过索引找到物理地址,再通过物理地址找到对应的记录。

索引的优点、缺点？

索引的优点

1.通过创建唯一索引，可以保证数据库每一行数据的唯一性
2.可以大大提高查询速度
3.可以加速表与表的连接
4.可以显著的减少查询中分组和排序的时间。

索引的缺点

1.创建索引和维护索引需要时间，而且数据量越大时间越长
2.创建索引需要占据磁盘的空间，如果有大量的索引，可能比数据文件更快达到最大文件尺寸
3.当对表中的数据进行增加，修改，删除的时候，索引也要同时进行维护，降低了数据的维护速度

如何建索引？

1.不是越多越好，因为如果建立过多的索引，保存的速度就会下降
2.常更新的表越少越好，因为在字段中做更新（插入）操作后，索引也会更新的，这样的话效率会大大降低
3.数据量小的表最好不要建立索引，因为小的表即使建立索引也不会有大的用处,还会增加额外的索引开销
4.不同的值比较多的列才需要建立索引
5.某种数据本身具备唯一性的时候，建立唯一性索引，可以保证定义的列的数据完整性，以提高查询熟度
6.频繁进行排序或分组的列(group by或者是order by)可以建立索引，提高搜索速度
7.经常用于查询条件的字段应该建立索引

不经常引用的列不要建立索引,因为不常用,即使建立了索引也没有多大意义
经常频繁更新的列不要建立索引,因为肯定会影响插入或更新的效率
索引并不是一劳永逸的,用的时间长了需要进行整理或者重建

如何理解索引最左前缀匹配？

在创建一个n列的索引时，需要遵循“最左前缀”原则。

创建表：create table abc(a varchar(32) not null, b varchar(32), c date, d varchar(32) );

创建普通索引：create index in_abc_acb on abc(a, c, b);

1、必须用到索引的第一个字段

select * from abc where  d='d' and b='b';  不会用到索引，必须要用到左边第一个字段；

2、对于索引的第一个字段，用like时左边必须是固定值，通配符只能出现在右边

select * from AAA where a like ‘1%’;会用到索引;而select * from abc where a like ‘%1’;不会用到索引。

3、遇到范围（>、<、between、like）查询就停止匹配，

select * from abc where a like '1%' and c=sysdate;  a 会用到索引，c 则不会

4、字段前加了函数（表达式）索引会被抑制，

select * from abc where trim(a) = 'a' ; a不会用到索引 
select * from abc where a = 'a' and c + 1 > sysdate;  a会用到索引 c不会用到索引
select * from abc where a = 'a' and c > sysdate - 2;  a会用到索引 c会用到索引

5、索引是从左到右匹配，in 和 = 可以乱序

select * from abc where b like 'b%' and c = sysdate and a='a' ；acb的索引都可以用到

Mysql索引失效有哪几种情况？

1.索引无法存储null值
　　
　　a.单列索引无法储null值，复合索引无法储全为null的值。

       b.查询时，采用is null条件时，不能利用到索引，只能全表扫描。

为什么索引列无法存储Null值？

a.索引是有序的。NULL值进入索引时，无法确定其应该放在哪里。（将索引列值进行建树，其中必然涉及到诸多的比较操作，null 值是不确定值无法比较，无法确定null出现在索引树的叶子节点位置。）

b.如果需要把空值存入索引，方法有二：其一，把NULL值转为一个特定的值，在WHERE中检索时，用该特定值查找。其二，建立一个复合索引。例如

create index ind_a on table(col1,1); 通过在复合索引中指定一个非空常量值，而使构成索引的列的组合中，不可能出现全空值。

2.不适合键值较少的列（不适合重复数据较多的列）
　　假如索引列TYPE有5个键值，如果有1万条数据，那么 WHERE TYPE = 1将访问表中的2000个数据块。

再加上访问索引块，一共要访问大于200个的数据块。

如果全表扫描，假设10条数据一个数据块，那么只需访问1000个数据块，既然全表扫描访问的数据块

少一些，肯定就不会利用索引了。

3.前导模糊查询不能利用索引(like '%XX’或者like ‘%XX%’)
　　假如有这样一列code的值为’AAA’,‘AAB’,‘BAA’,‘BAB’ ,如果where code like '%AB’条件，由于前面是

模糊的，所以不能利用索引的顺序，必须一个个去找，看是否满足条件。这样会导致全索引扫描或者全表扫

描。如果是这样的条件where code like 'A % '，就可以查找CODE中A开头的CODE的位置，当碰到B开头的

数据时，就可以停止查找了，因为后面的数据一定不满足要求。这样就可以利用索引了。

4.其他几种索引失效的情况
　　
1.如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)

要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引

2.对于多列索引，不是使用的第一部分，则不会使用索引

3.like查询以%开头

4.如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引

5.如果mysql估计使用全表扫描要比使用索引快,则不使用索引

5.MySQL主要提供2种方式的索引：B-Tree索引，Hash索引
　　B树索引具有范围查找和前缀查找的能力，对于有N节点的B树，检索一条记录的复杂度为O(LogN)。相当于二分查找。

哈希索引只能做等于查找，但是无论多大的Hash表，查找复杂度都是O(1)。

显然，如果值的差异性大，并且以等值查找（=、 <、>、in）为主，Hash索引是更高效的选择，它有O(1)的查找复杂度。

如果值的差异性相对较差，并且以范围查找为主，B树是更好的选择，它支持范围查找。

Mysql索引如何优化？

作为免费又高效的数据库，mysql基本是首选。良好的安全连接，自带查询解析、sql语句优化，使用读写锁（细化到行）、事物隔离和多版本并发控制提高并发，完备的事务日志记录，强大的存储引擎提供高效查询（表记录可达百万级），如果是InnoDB，还可在崩溃后进行完整的恢复，优点非常多。即使有这么多优点，仍依赖人去做点优化，看书后写个总结巩固下，有错请指正。

完整的mysql优化需要很深的功底，大公司甚至有专门写mysql内核的，sql优化攻城狮，mysql服务器的优化，各种参数常量设定，查询语句优化，主从复制，软硬件升级，容灾备份，sql编程，需要的不是一星半点的知识与时间来掌握，作为一名像俺这样的菜鸟开发，强吃这么多消化不了也没意义：没地儿用啊，况且还有运维和dba，还不如把手头的业务写好，也就是写好点的sql，而且很多sql语句优化跟索引还是有很大关系的。

首先，mysql的查询流程大致是：mysql客户端通过协议与mysql服务器建立连接，发送查询语句，先检查查询缓存，如果命中，直接返回结果，否则进行语句解析，有一系列预处理，比如检查语句是否写正确了，然后是查询优化（比如是否使用索引扫描，如果是一个不可能的条件，则提前终止），生成查询计划，然后查询引擎启动，开始执行查询，从底层存储引擎调用API获取数据，最后返回给客户端。怎么存数据、怎么取数据，都与存储引擎有关。然后，mysql默认使用的BTREE索引，并且一个大方向是，无论怎么折腾sql，至少在目前来说，mysql最多只用到表中的一个索引。

mysql通过存储引擎取数据，自然跟存储引擎有很大关系，不同的存储引擎索引也不一样，如MyISAM的全文索引，即便索引叫一个名字内部组织方式也不尽相同，最常用的当然就是InnoDB了（还有完全兼容mysql的MariaDB，它的默引擎是XtraDB，跟InnoDB很像），这里写的是InnoDB引擎。而索引的实现也跟存储引擎，按照实现方式分，InnoDB的索引目前只有两种：BTREE索引和HASH索引。通常我们说的索引不出意外指的就是B树索引，InnoDB的BTREE索引，实际是用B+树实现的，因为在查看表索引时，mysql一律打印BTREE，所以简称为B树索引。至于B树与B+树的区别，原谅的俺数据结构没好好学，也是需要补的地方。

使用了BTREE索引，意味着所有的索引是按顺序排列存储的（升序），mysql就是这么干的，mysl中的BTREE索引抽象结构如下图（参考高性能mysql）。

结构中，每一层节点均从左往右从小到大排列，key1 < key2 < … < keyN，对于小于key1或在[key1，key2)或其他的值的节点，在进入叶子节点查找，是一个范围分布，同时，同一层节点之间可直接访问，因为他们之间有指针指向联系（MyISAM的BTREE索引没有）。每次搜索是一个区间搜索，有的话就找到了，没有的话就是空。索引能加快访问速度，因为有了它无需全表扫描数据（不总是这样），根据查找的值，跟节点中的值比较，通常使用二分查找，对于排好序的数值来说，平均速度几乎是最快的。

val指向了哪里，对于InnoDB，它指向的就是表数据，因为InnoDB的表数据本身就是索引文件，这是与MyISAM索引的显著区别，MyISAM的索引指向的是表数据的地址（val指向的是类似于0x7DFF…之类）。比如对于InnoDB一个主键索引来说，可能是这样

InnoDB的索引节点val值直接指向表数据，即它的叶子节点就是表数据，它们连在一起，表记录行没有再单独放在其他地方，叶子节点（数据）之间可访问。

前面在BTREE的抽象结构中，索引值的节点是放在页中的，这里有两个需注意的问题：

1. 叶子页、页中的值（上上图），即所谓的页是啥，俺加了个节点注释，即这里的页最小可近似当做是单个节点。我们知道计算机的存储空间是一块一块的，通常一块用完了再用另一块，如果上一块只剩余5kb，但这里刚好要申请8kb的空间，就得在一个新的块上申请这个空间，然后以后的申请又接在这个8kb后面，只要这个块的空间足够，那么上一块的5kb通常就成了所谓的“碎片”，电脑用多了会有很多这样零散的碎片空间，因此有碎片整理。在mysql中，这里的页可理解为块存储空间，即索引的树节点是存放在页中的，每一页（称为逻辑页）有固定大小，InnoDB目前是16kb，一页用完了，当继续插入表生成新的索引节点时，就去新的页中存储这个节点，再有新的节点就继续放在这个新的页的节点后面。

2. 页分裂问题，一页总要被存满，然后新开一页继续，这种行为被称作页分裂。何时开辟新的页，mysql规定了一个分裂因子，达到页存储空间的15/16则存到下一页。页分裂的存在可能极大影响性能维护索引的性能。通常提倡的是，设定一个无意义的整数自增索引，有利于索引存储

如果非自增或不是整数索引，如非自增整数、类似MD5的字符串，以他们作为索引值时，因为待插入的下一条数据的值不一定比上一条大，甚至比当前页所有值都小，需要跑到前几页去比较而找到合适位置，InnoDB无法简单的把新行插入到上一行后面，而找到并插入索引后，可能导致该页达到分裂因子阀值，需要页分裂，进一步导致后面所有的索引页的分裂和排序，数据量小也许没什么问题，数据量大的话可能会浪费大量时间，产生许多碎片。

主键总是唯一且非空，InnoDB自动对它建立了索引（primary key），对于非主键字段上建立的索引，又称辅助索引，索引排列也是顺序排列，只是它还附带一个本条记录的主键值的数据域，不是指向本数据行的指针，在使用辅助索引查找时，先找到对应这一列的索引值，再根据索引节点上的另一个数据域—主键值，来查找该行记录，即每次查找实际经过查找了两次。额外的数据域存储主键值的好处是，当页分裂发生时，无需修改数据域的值，因为即使页分裂，该行的主键值是不变的，而地址就变了。比如name字段的索引简示如下

包含一列的索引称为单列索引，多列的称为复合索引，因为BTREE索引是顺序排列的，所以比较适合范围查询，但是在复合索引中，还应注意列数目、列的顺序以及前面范围查询的列对后边列的影响。

比如有这样一张表

create table staffs(id int primary key auto_increment,name varchar(24) not null default '' comment '姓名',age int not null default 0 comment '年龄',pos varchar(20) not null default '' comment '职位',add_time timestamp not null default current_timestamp comment '入职时间') charset utf8 comment '员工记录表';

添加三列的复合索引

alter table staffs add index idx_nap(name, age, pos);

在BTREE索引的使用上，以下几种情况可以用到该索引或索引的一部分（使用explain简单查看使用情况）：

1. 全值匹配

如select * from staffs where name = 'July' and age = '23' and pos = 'dev' ，key字段显示使用了idx_nap索引

2. 匹配最左列，对于复合索引来说，不总是匹配所有字段列，但是可以匹配索引中靠左的列

如select * from staffs where name = 'July' and age = '23'，key字段显示用到了索引，注意，key_len字段（表示本次语句使用的索引长度）数值比上一条小了，意思是它并未使用全部索引列（通常这个长度可估摸着用了哪些索引列，埋个坑），事实上只用到了name和age列

再试试select * from staffs where name = 'July'，它也用了索引，key_len值更小，实际只用到了索引中的name列

3. 匹配列前缀，即一个索引中列的前一部分，主要用在模糊匹配，如select * fromstaffs where name like 'J%'，explain信息的key字段表示使用了索引，但是mysql的B树索引不能非列前缀的模糊匹配，如select * from staffs where name like '%y' 或者 like ‘%u%’，`据说是由于底层存储引擎的API限制

4. 匹配范围，如select * from staffs where name > 'Mary'，但俺在测试时发现>可以，>=却不行，至少在字符串列上不行（测试mysql版本5.5.12），然而在时间类型（timestamp）上却可以，不测试下还真不能确定说就用到了索引==

出于好奇测了下整型字段的索引（idx_cn(count, name)，count为整型），发现整型受限制少很多，下面的都能用到索引，连前模糊匹配的都行

select * from indexTest1 where count > '10'select * from indexTest1 where count >= '10'select * from indexTest1 where count > '10%'select * from indexTest1 where count >= '10%'select * from indexTest1 where count > '%10%'select * from indexTest1 where count >= '%10%'

5. 精确匹配一列并范围匹配右侧相邻列，即前一列是固定值，后一列是范围值，它用了name与age两个列的索引（key_len推测）

如select * from staffs where name = 'July' and age > 25

6. 只访问索引的查询，比如staffs表的情况，索引建立在(name,age,pos)上面，前面一直是读取的全部列，如果我们用到了哪些列的索引，查询时也只查这些列的数据，就是只访问索引的查询，如

 select name,age,pos from staffs where name = 'July' and age = 25 and pos = 'dev'select name,age from staffs where name = July and age > 25

第一句用到了全部索引列，第二句只用了索引前两列，select的字段就最多只能是这两列，这种查询情况的索引，mysql称为覆盖索引，就是索引包含（覆盖）了查询的全部字段。是不是用到了索引查询，在explain中需要看最后一个Extra列的信息，Using index表明使用了覆盖索引，同时Using where表明也使用了where过滤

7. 前缀索引

区别于列前缀（类似like 'J%'形式的模糊匹配）和最左列索引（顺序取索引中靠左的列的查询），它只取某列的一部分作为索引。通常在说InnoDB跟MyISAM的区别时，一个明显的区别是：MyISAM支持全文索引，而InnoDB不行，甚至对于text、blob这种超长的字符串或二进制数据时，MyISAM会取前多少个字符作为索引，InnoDb的前缀索引跟这个类似，某些列，一般是字符串类型，很长，全部作为索引大大增加存储空间，索引也需要维护，对于长字符串，又想作为索引列，一个可取的办法就是取前一部分（前缀），代表一整列作为索引串，问题是：如何确保这个前缀能代表或大致代表这一列？所以mysql中有个概念是索引的选择性，是指索引中不重复的值的数目（也称基数）与整个表该列记录总数（#T）的比值，比如一个列表（1,2,2,3），总数是4，不重复值数目为3，选择性为3/4，因此选择性范围是[1/#T, 1]，这个值越大，表示列中不重复值越多，越适合作为前缀索引，唯一索引（UNIQUE KEY）的选择性是1。

比如有一列a varchar(255)，以它作前缀索引，比如以7个测试，逐个增加看看选择性值增长到那个数基本不变，就表示可以代表整列了，再结合这个长度的索引列是否存储数据太多，做个权衡，基本就行了。但如果这个选择性本来就小的可怜还是算了

 select count(distinct left(a, 7))/count(*) as non_repeat from tab;

定好一个前缀数目，如9，添加索引时可以这样

  alter table tab add index idx_cpn(count, name(9)) --复合前缀索引

以上为常见的使用索引的方式，有这么些情况不能用或不能全用，有的就是上面情况的反例，以key(a, b, c)为例

1. 跳过列，where a = 1 and c = 3，最多用到索引列a；where b = 2 and c = 3，一个也用不到，必须从最左列开始

2. 前面是范围查询，where a = 1 and b > 2 and c = 3，最多用到 a, b两个索引列；

3. 顺序颠倒，where c = 3 and b = 2 and a = 1，一个也用不到；

4. 索引列上使用了表达式，如where substr(a, 1, 3) = ‘hhh’，where a = a + 1，表达式是一大忌讳，再简单mysql也不认。有时数据量不是大到严重影响速度时，一般可以先查出来，比如先查所有有订单记录的数据，再在程序中去筛选以’cp1001’开头的订单，而不是写sql过滤它；

5. 模糊匹配时，尽量写 where a like ‘J%’，字符串放在左边，这样才可能用得到a列索引，甚至可能还用不到，当然这得看数据类型，最好测试一下。

排序对索引的影响

order by是经常用的语句，排序也遵循最左前缀列的原则，比如key(a, b)，下面语句可以用到（测试为妙）

  select * from tab where a > 1 order by bselect * from tab where a > 1 and b > '2015-12-01 00:00：00' order by bselect * from tab order by a, b

以下情况用不到

1. 非最左列，select * from tab order by b;

2. 不按索引列顺序来的，select * from tab where b > '2015-12-01 00:00:00' order by a;

3. 多列排序，但列的顺序方向不一致，select * from tab a asc, b desc。

聚簇索引与覆盖索引

前面说到，mysql索引从结构上只有两类，BTREE与HASH，覆盖索引只是在查询时，要查询的列刚好与使用的索引列完全一致，mysql直接扫描索引，然后就可返回数据，大大提高效率，因为不需再去原表查询、过滤，这种形式下的索引称作覆盖索引，比如key(a,b)，查询时select a,b from tab where a = 1 and b > 2，本质原因：BTREE索引存储了原表数据。

聚簇索引也不是单独的索引，前面简要写到，BTREE索引会把数据放在索引中，即索引的叶子页中，包括主键，主键是跟表数据紧挨着放在一起的，因为表数据只有一份，一列键值要跟每一行数据都紧挨在一起，所以一张表只有一个聚簇索引，对于mysql来说，就是主键列，它是默认的。

聚簇索引将表数据组织到了一起（参考前面主键索引简略图），插入时严重依赖主键顺序，最好是连续自增，否则面临频繁页分裂问题，移动许多数据。

哈希索引

简要说下，类似于数据结构中简单实现的HASH表（散列表）一样，当我们在mysql中用哈希索引时，也是对索引列计算一个散列值（类似md5、sha1、crc32），然后对这个散列值以顺序（默认升序）排列，同时记录该散列值对应数据表中某行的指针，当然这只是简略模拟图

比如对姓名列建立hash索引，生成hash值按顺序排列，但是顺序排列的hash值并不对应表中记录，从地址指针可反应出来，而且，hash索引可能建立在两列或者更多列上，取得是多列数据后的hash值，它不存储表中数据。它先计算列数据的hash值，与索引中的hash值比较，找到了然后比对列数据是否相等，可能涉及其他列条件，然后返回数据。hash当然会有冲突，即碰撞，除非有很多冲突，一般hash索引效率很高，否则hash维护成本较高，因此哈希索引通常用在选择性较高的列上面。哈希索引的结构决定了它的特点：

1. hash索引只是hash值顺序排列，跟表数据没有关系，无法应用于order by；

2. hash索引是对它的所有列计算哈希值，因此在查询时，必须带上所有列，比如有(a, b)哈希索引，查询时必须 where a = 1 and b = 2，少任何一个不行；

3. hash索引只能用于比较查询 = 或 IN，其他范围查询无效，本质还是因不存储表数据；

4. 一旦出现碰撞，hash索引必须遍历所有的hash值，将地址所指向数据一一比较，直到找到所有符合条件的行。

填坑

前面提到通过explain的key_len字段，可大致估计出用了哪些列，索引列的长度跟索引列的数据类型直接相关，一般，我们说int是4字节，bigint8字节，char是1字节，考虑到建表时要指定字符集，比如utf8，还跟选的字符集有关（==!），在utf8下边，一个char是3字节，但是知道这些仍不能说key_len就是将用到的索引列的数据类型代表字节数一加不就完啦？事实总有点区别，测试方法比较机械（以下基于mysql 5.5.2）

建表，加索引，int型

–测试表

 create table keyLenTest1(id int primary key auto_increment,typeKey int default 0 ,add_time timestamp not null default current_timestamp) charset utf8

–添加索引

  alter table keyLenTest1 add index idx_k(typeKey);

可知int型索引默认长度为5，在4字节基础上+1

char型

–改为char型，1个字符

 alter table keyLenTest1 modify typeKey char(1);

–改为char型，2个字符

  alter table keyLenTest1 modify typeKey char(2);

可知，char型初始是4字节（3+1 bytes），后续按照3字节递增

varchar型

–改为varchar型，1个字符

  alter table keyLenTest1 modify typeKey varchar(1);

–改为varchar型，2个字符

  alter table keyLenTest1 modify typeKey varchar(2);

可知，varchar型，1个字符时，key_len为6，以后以3字节递增

所以，如果一个语句用到了int、char、varchar，key_len如何计算以及用了哪些索引列应该很清楚了。

如果想了解的更详细点，explain各字段意义，索引的更多细节，除了explain，还有show profiles、慢查询日志等（没细看），推荐看高性能mysql