[[431243]]太阳城娱乐体育

然而在咱们的日常开导当中，「并不是整个的表一定要得志三大范式」，偶然候冗余几个字段不错少关联几张表，带来的查询后果的擢升有可能是质变的

1.普通索引的 B+ 树上存放的是主键索引的值，要是该值较大，会「导致普通索引的存储空间较大」

2.使用自增 id 作念主键索引新插入数据只消放在该页的最尾端就不错，平直「按照规章插入」，无须刻意欷歔

3.页分裂容易欷歔，当插入数据确面前页快满时，会发生页分裂的阵势，要是主键索引不为自增 id，那么数据就可能从页的中间插入，页的数据会经常的变动，「导致页分裂欷歔老本较高」

1.通过贯穿器跟客户端「诞生贯穿」

2.通过查询「缓存查询」之前是否有查询过该 sql

有则平直复返落幕

莫得则实行第三步

3.通过分析器「分析该 sql 的语义」是否正确，包括神志，表等等

4.通过优化器「优化该语句」，比如采用索引，join 表的贯穿规章

5.「考据权限」，考据是否有该表的查询权限

6.通过实行器调用存储引擎实行该 sql，然后复返「实行落幕」

用以下语句来例如，c 字段无索引，id 为主键索引

update 太阳城娱乐体育T set c=c+1 where id=2; 

1.实行器先找引擎取 id=2 这一溜。id 是主键，引擎平直用树搜索找到这一溜

2.实行器拿到引擎给的行数据，把这个值加上 1，比如蓝本是 N，当今即是 N+1，得到新的一溜数据，再调用引擎接口「写入这行新数据」

3.引擎将这行新数据更新到内存中，同期将这个更新操作「记载到 redo log 内部」，此时 redo log 处于 「prepare」 景况。然后见告实行器实行完成了，随时不错提交事务

4.实行器「生成这个操作的 binlog」，并把 binlog 「写入磁盘」

5.实行器调用引擎的「提交事务」接口，引擎把刚刚写入的 redo log 改成提交(commit)景况，「更新完成」

不错看到，「要是不使用“两阶段提交”，那么数据库的景况就有可能和用它的日记复原出来的库的景况不一致」。

确信大家小时候学习汉字的时候王人会查字典，想想你查字典的门径，咱们是通过汉字的首字母 a～z 一个一个在字典目次中查找，最终找到该字的页数。想想，要是莫得目次会何如样，最差的落幕是你有可能翻到字典的终末一页才找到你想要找的字。

索引就「荒谬于咱们字典中的目次」，不错极大的提高咱们在数据库的查询后果。

以下随意列举几个，不同版块的 mysql 场景不一

1.最左前缀法例(带头索引不可死，中间索引不可断

2.不要在索引上作念任何操作(筹划、函数、自动/手动类型调遣)，否则会导致索引失效而转向全表扫描

3.不可不时使用索引中限制条目(bettween、<、>、in等)右边的列，如：

select a from user where c > 5 and b = 4； 

4.索引字段上使用(!= 或者 < >)判断时，会导致索引失效而转向全表扫描

5.索引字段上使用 is null / is not null 判断时，会导致索引失效而转向全表扫描。

6.索引字段使用like以通配符开端(‘%字符串’)时，会导致索引失效而转向全表扫描，亦然最左前缀原则。

7.索引字段是字符串，但查询时不加单引号，会导致索引失效而转向全表扫描

8.索引字段使用 or 时，会导致索引失效而转向全表扫描

B+ 树只在叶子结点储存数据，非叶子结点不存具体数据，只存 key，查询更清楚，增大了广度，而一个节点即是磁盘一个内存页，内存页大小固定，那么比较 B 树，B- 树这些「不错存更多的索引结点」，宽度更大，树高矮，节点小，拉取一次数据的磁盘 IO 次数少，何况 B+ 树只需要去遍历叶子节点就不错竣私密棵树的遍历。而且在数据库中基于限制的查询瑕瑜常经常的，后果更高。

WAL 即是 Write-Ahead Logging，其实即是「整个的修改王人先被写入到日记中，然后再写磁盘」，用于保证数据操作的原子性和抓久性。

自制:

1.「读和写不错弥漫地并发实行」，不会彼此攻击

2.先写入 log 中，磁盘写入从「立时写变为规章写」，缩小了 client 端的蔓延就。何况，由于规章写入粗略率是在一个磁盘块内，这么产生的 io 次数也大大缩小

3.写入日记当数据库崩溃的时候「不错使用日记来复原磁盘数据」

回表即是先通过数据库索引扫描出该索引树中数据场所的行，取到主键 id，再通过主键 id 取出主键索引数中的数据，即基于非主键索引的查询需要多扫描一棵索引树.

要是存在某些被索引的列的判断条目时，MySQL 将这一部分判断条目传递给存储引擎，然后由存储引擎通过判断索引是否相宜 MySQL 办事器传递的条目，「惟有当索引相宜条目时才会将数据检索出来复返给 MySQL 办事器」 。

皇冠hg86a

覆盖索引(covering index)指一个查询语句的实行只用从索引中就能够获得，不必从数据表中读取，不错减少回表的次数。比如:

select id from t where age = 1; 

id 为主键索引，age 为普通索引，age 这个索引树存储的即是慢慢信息，皇冠app不错平直复返

最左前缀其实说的是，在 where 条目中出现的字段，「要是惟有组合索引中的部分列，则这部分列的触发索引规章」，是按照界说索引的时候的规章从前到后触发，最左面一个列触发不了，之后的整个列索引王人无法触发。

比如「有一个 (a，b，c) 的组合索引」

where a = 1 and b = 1 

此时 a，b 会射中该组合索引

where a = 1 and c = 1 

此时 a 会射中该组合索引， c 不会

where b = 1 and c = 1 

此时不会射中该组合索引

查询

更新

是以「唯一索引愈加稳当查询的场景，普通索引更稳当插入的场景」

事务是指是圭臬中一系列操作必须全部到手完成，有一个失败则全部失败。

特质

「1.原子性(Atomicity)」：要么全部实行到手，要么全部演叨行。

「2.一致性(Consistency)」：事务前后数据的齐全性必须保抓一致。

「3.间隔性(Isolation)」：间隔性是当多个事务共事触发时，不可被其他事务的操作所干与，多个并发事务之间要彼此间隔。

「4.抓久性(Durability)」：事务完成之后的改变是长久的。

1.「读提交」:即能够「读取到那些也曾提交」的数据

2.「读未提交」:即能够「读取到莫得被提交」的数据

3.「可类似读」:可类似读指的是在一个事务内，最开动读到的数据和事务收尾前的「恣意时刻读到的褪色批数据王人是一致的」

4.「可串行化」:最高事务间隔级别，不论若处事务，王人是「纪律按序一个一个实行」

「脏读」

「不可类似读」

「幻读」

binlog 是存档日记，属于 Server 层的日记，是一个二进制神志的文献，用于「记载用户对数据库更新的SQL语句信息」。

主要作用

undolog 是 InnoDB 存储引擎的日记，用于保证数据的原子性，「保存了事务发生之前的数据的一个版块，也即是说记载的是数据是修改之前的数据，不错用于回滚」，同期不错提供多版块并发适度下的读(MVCC)。

主要作用

relaylog 是中继日记，「在主从同步的时候使用到」，它是一个中介临时的日记文献，用于存储从master节点同步过来的binlog日记骨子。

master 主节点的 binlog 传到 slave 从节点后，被写入 relay log 里，从节点的 slave sql 线程从 relaylog 里读取日记然后应用到 slave 从节点腹地。从办事器 I/O 线程将驾驭事器的二进制日记读取过来记载到从办事器腹地文献，然后 SQL 线程会读取 relay-log 日记的骨子并应用到从办事器，从而「使从办事器和驾驭事器的数据保抓一致」。

redolog 是 「InnoDB 存储引擎所特有的一种日记」，用于记载事务操作的变化，记载的是数据修改之后的值，不功绩务是否提交王人会记载下来。

不错作念「数据复原何况提供 crash-safe 智商」

当有增蜕变关连的操作时，会先记载到 Innodb 中，并修改缓存页中的数据，「比及 mysql 闲下来的时候才会真确的将 redolog 中的数据写入到磁盘当中」。

InnoDB 的 redo log 是固定大小的，比如不错建设为一组4个文献，每个文献的大小是1GB，那么统共就不错记载4GB的操作。「从新开动写，写到末尾就又回到开端轮回写」。

是以，要是数据写满了然而还莫得来得及将数据真确的刷入磁盘当中，那么就会发生「内存抖动」阵势，从肉眼的角度来不雅察会发现 mysql 会宕机霎时，此时即是正在刷盘了。

1.「redolog」 是 「Innodb」 特有的日记，而 「binlog」 是 「server」 层的，整个的存储引擎王人有使用到

2.「redolog」 记载了「具体的数值」，对某个页作念了什么修改，「binlog」 记载的「操作骨子」

3.「binlog」 大小达到上限或者 flush log 「会生成一个新的文献」，而 「redolog」 有固定大小「只可轮回哄骗」

4.「binlog 日记莫得 crash-safe 的智商」，只可用于存档。而 redo log 有 crash-safe 智商。

MVCC:多版块并发适度，是当代数据库(包括 MySQL、Oracle、PostgreSQL 等)引擎齐全中常用的处理读写突破的期间，指标在于「提高数据库高并发场景下的隐约性能」。

在 MVCC 条约下，每个读操作会看到一个一致性的快照，「这个快照是基于整个这个词库的」，何况不错齐全非攻击的读，用于「救援读提交和可类似读间隔级别的齐全」。

MVCC 允许数据具有多个版块，这个版块不错是时候戳或者是全局递加的事务 ID，在褪色个时候点，不同的事务看到的数据是不同的，这个修改的数据是「记载在 undolog 中」的。

「1.没灵验到索引」

比如函数导致的索引失效，或者本人就莫得加索引

「2.表数据量太大」

磋商分库分表吧

「3.优化器选错了索引」

「磋商使用」 force index 强制走索引

「1. 数据库在刷新脏页」

比如 「redolog 写满了」，「内存不够用了」开释内存要是是脏页也需要刷，mysql 「泛泛悠闲景况刷脏页」

「2. 莫得拿到锁」

1.master 主库将这次更新的事件类型「写入到主库的 binlog 文献」中

2.master 「创建 log dump 线程陈述 slave」 需要更新数据

3.「slave」 向 master 节点发送苦求，「将该 binlog 文献骨子存到腹地的 relaylog 中」

4.「slave 开启 sql 线程」读取 relaylog 中的骨子，「将其中的骨子在腹地再行实行一遍」，完成主从数据同步

「同步战术」：

1.「全同步复制」：主库强制同步日记到从库，等全部从库实行完才复返客户端，性能差

2.「半同步复制」：主库收到至少一个从库阐发就以为操作到手，从库写入日记到手复返ack阐发

1.MySQL 5.6 版块以后，提供了一种「并行复制」的方法，通过将 SQL 线程调遣为多个 work 线程来进行重放

2.「提高机器建设」(王说念)

3.在业务初期就采用合适的分库、分表战术，「幸免单表单库过大」带来特地的复制压力

4.「幸免长事务」

5.「幸免让数据库进行多样大批运算」

6.关于一些对蔓延很明锐的业务「平直使用主库读」

在使用 delete 删除数据时，其实对应的数据行并不是真确的删除，是「逻辑删除」，InnoDB 只是是将其「记号成可复用的景况」，是以表空间不会变小

当界说varchar长度小于等于255时，长度标记位需要一个字节(utf-8编码)

当大于255时，长度标记位需要两个字节，何况诞生的「索引也会失效」

1.「腹地音书表」

2.「音书事务」

3.「二阶段提交」

4.「三阶段提交」

5.「TCC」

6.「最大力争陈述」

7.「Seata 框架」

七种散播式事务的措置决策，一次讲给你听

以下并不全，主措施略下锁的真谛即可

1.并发情况下，数据库「贯穿池容易被撑爆」

2.「容易形成大批的攻击和锁超时」

长事务还占用锁资源，也可能拖垮整个这个词库，

3.实行时候长，容易形成「主从蔓延」

4.「回滚所需要的时候比较长」

事务越长整个这个词时候段内的事务也就越多

5.「undolog 日记越来越大」

长事务意味着系统内部会存在很老的事务视图。由于这些事务随时可能打听数据库内部的任何数据，是以这个事务提交之前，数据库内部它可能用到的回滚记载王人必须保留，这就会导致大批占用存储空间。

buffer pool 是一块内存区域，为了「提高数据库的性能」，当数据库操作数据的时候，把硬盘上的数据加载到 buffer pool，反抗直和硬盘打交说念，操作的是 buffer pool 内部的数据，数据库的增蜕变查王人是在 buffer pool 上进行

buffer pool 内部缓存的数据骨子亦然一个个数据页

其中「有三大双向链表」:

「free 链表」

「flush 链表」

「lru 链表」

预读机制:

Buffer Pool 有一项特技叫预读，存储引擎的接口在被 Server 层调用时，会在反应的同期进行预判，将下次可能用到的数据和索引加载到 Buffer Pool

1.「表结构优化」

1.1拆分字段

1.2字段类型的采用

1.3字段类型大小的为止

1.4合理的加多冗余字段

1.5新建字段一定要有默许值

2.「索引方面」

2.1索引字段的采用

2.2哄骗好mysql救援的索引下推，覆盖索引等功能

2.3唯一索引和普通索引的采用

3.「查询语句方面」

3.1幸免索引失效

3.2合理的书写where条目字段规章

3.3小表驱动大表

3.4不错使用force index()扎眼优化器选错索引

4.「分库分表」