m0_73302761的博客

共享池 ：将查询的sql语句的。查询缓存 ：将查询的sql语句和。

事务需要保证原子性，也就是事务中的操作要么全部完成，要不什么都不做。每当我们要对一条数据做改动时(insert、delete、update)，都需要留一手，把需要回滚的记录都记录下来。

其实这也很好算，我们假设主键ID为bigint类型，长度为8字节，而指针大小在InnoDB源码中设置为6字节，这样一共14字节，我们一个页中能存放多少这样的单元，其实就代表有多少指针，即16384/14=1170。需要注意的是，InnoDB中的B+树是自平衡的，当插入或删除数据时，会自动重新调整树结构，以保持树的平衡性和性能。是按页加载的，一行行数据加载到一页页里面，也就是说我们的索引数据都是放在一页一页里面的，而一页的大小是16kb，生成B+树的过程中，首先会生成目录页，然后再生成数据页。

对应的就是undo log版本链，用户线程进来查询的那条记录，如果有人要进行修改，则会将修改后的内容引一个指针出来指向旧的数据，这样用户线程读取的一直都是之前的那个版本的数据，自然也就解决了不可重复读和幻读的问题了。我将MVCC与CopyOnWrite做比较，在java中底层就是写时复制技术，我觉得两者是互通的。MVCC在MySQL InnoDB中的实现主要是为了提高数据库的并发性能，用更好的方式去处理。当前读实际上是一种加锁的操作，是悲观锁的实现，而MVCC是乐观锁。的多个版本管理来实现数据库的。

在MyISAM则不一样。

Checkpoint是一种机制，用于将内存中的数据页刷新到磁盘上，以保证数据的持久性。比如，某个事务将系统表空间中第10号页面中偏移量为100处的那个字节的值1改为2，我们只需要记录一下将系统表空间中第10号页面中偏移量为100处的那个字节的值1改为2，不需要将整个页面从缓冲池刷新到磁盘，这是比较耗时的。我们只是想让已经提交了的事物对数据库中数据所做的修改永久生效，即使后来系统崩溃，在重启后也能把这种修改恢复出来，所以我们其实没有必要在每次事务提交时就把事务在内存中修改过的全部页面刷新到磁盘，只需要。

为什么说能不用子查询就不用子查询

在该语句执行完后，就把AUTO-INC锁释放掉**一个事务在持有AUTO-INC锁的过程中，其他事务的插入语句都需要被阻塞，**因为有表级锁的竞争，并发性能很低。一个事务在写，另外一个事务也要写，就会造成脏写的问题，所以在一个事务在写的时候，我们会添加行锁，确保只能有一个事务进行一条数据的写操作。读 - 写 或 写 - 读，即一个事务在进行写操作的时候，另外一个事务在进行读操作，一个事物在进行读操作，另外一个线程在进行写操作。针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞。

回表的概念为什么需要有回表解决回表问题 — 索引覆盖

最终选择索引和filesort进行排序是由优化器决定的，走索引要回表什么的会耗时，由联合索引另说。举个例子，A表中有20个数据，B表中有30个数据，在没有索引的情况下，每一个A表的id都要对B表对数据id进行全表遍历，mysql会先将select的数据查出来放到内存中，让数据在内存中进行排序，我们称为 filesort。联合索引 + 索引覆盖，可能效率会快过 filesort，具体看数据量，由优化器视成本决定。会自动将表数据少的那个表作为被驱动表，当然有索引的另说，我们说的是没有索引的情况。

索引失效情况1.联合索引 — 最左匹配原则 导致索引失效2.计算 函数 导致索引失效3.类型转换导致索引失效4.!= <> is not null 这些否定导致索引失效5.like以通配符%开头导致索引失效6.or前后字段存在非索引列导致索引失效7.order By 不加 limit 导致索引失效8.总结

此处我们拿二级索引举例但是！！！哪怕是通过二级索引找到了数据，其实也就是找到了二级索引的数据条件的对应的主键罢了，最后还是要回表到主键索引去找到真实数据。

永久性是指一个事物一旦被提交，它对数据库中数据的改变是永久性的，接下来的其他操作和数据库故障不会对永久性数据产生影响。事务A在读到一条数据后，此时事务B将该条数据修改并提交了，此时事务A再读取该数据，读到的还是原来的内容，不能避免幻读。我的理解是数据一致性，举个例子就能明白，拿转账来说，假设用户A和用户B两者的钱加起来一共是500，那么不管A和B。之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是500，这就是事务的一致性。当一个处在部分提交的状态的事务，，此时事务状态就是失败的。

当我们查询数据时，其是以页为单位，将磁盘中的数据加载到缓冲池中的。同理，更新数据也是以页为单位，将我们对数据的修改刷回磁盘。mysql中的具体数据是存储在行中的，而行是存储在页中的，每页的默认大小为16k（大小可以通过配置文件修改）事务数据页（Transaction System Page），与数据库相关的所有内容都存储在Page结构里。Undo页（Undo Log Page），数据页（B-Tree Node），系统页（System Page），

多次单表和单次多表到底哪个效率高

两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。

二阶段提交prepare 和 commit所以为什么要这样设计呢？这样的设计怎么就能够实现崩溃恢复呢？如果redo log里面的事务时完整的，也就是已经有了commit标识，则直接提交如果redo log里面的事务处于prepare状态，则需要判断对应的事务在bin log是否存在并完整如果bin log存在并完整，则提交事务如果bin log不完整，则回滚事务这样我们就保证了主从一致此时我们的整体架构就变成了。

总之，长事务可能会对数据库的性能、内存消耗、数据一致性和回滚时间等方面带来危害，因此需要合理设计和管理事务，以确保数据库的正常运行和数据的完整性。

参考 原文链接：https://blog.youkuaiyun.com/ddzzz_/article/details/119277573。

B+树只有叶子结点存放真实数据，非叶子结点只存放主键最小值和数据页页数，二级索引…B树因为非叶子结点也会存储真实数据，导致B树的高度 > B+树的高度。B+树的叶子结点是通过链表相连接的，而B树是没有的。B树是叶子结点和非叶子结点都存放真实数据。先说一下B树和B+树 区别。

bin log 以事件形式记录，不是事务日志。对于非事务表的操作，每当语句执行完成则直接写入；对于事务表的操作则会在事务提交时（先记录到缓存中）一次性写入。bin log 是 MySQL 的一种二进制日志，记录引起或可能（更新删除没有匹配的记录）引起数据库变动的事件信息。主要用于数据备份和恢复、主从同步等…在主从同步中有两个线程。

Buffer Pool也是需要性能开销的，innodb规定：当 innodb_buffer_pool_size 小于1G时，设置多个实例是无效的，InnoDB会默认innodb_buffer_pool_instances 的值为1；当我们对数据库中的记录进行修改时，首先会对缓冲池中的信息进行修改，然后以一定的频率刷新到磁盘上，这里并不是每次更新操作都会立刻写回磁盘，而会采用一种 checkpoint 的机制，触发时才回写到磁盘上，更好的提升整体性能；，从而提高并发处理能力。

查询缓存为什么没用

系统(客户端)访问MySQL服务器之前，做的第一件事就是建立TCP连接经过三次握手之后建立连接成功后，MySQL服务器对TCP传输过来的账号密码做身份验证、权限获取TCP连接收到请求后，必须要分配一个线程专门与这个客户端进行交互，所以还会有一个线程池，省去创建和销毁线程的开销Parser 解析器SQL命令传递到解析器时，会被解析器验证和解析，并为其创建语法树，MySQL还会对SQL查询进行语法上的优化，进行重写Optimizer 查询优化器SQL语句在语法解析之后，查询之前会使用查询优化器确定SQL语句的执

SQL执行流程解析树&语法树优化器总结一览