第4版高性能MySQL 第一章 MySQL架构读书笔记( 二 ) _生活百科

有一些命令,当在活动的事务中发出时,会导致MySQL在事务的所有语句执行完毕前提交当前事务比如一些DDL命令 alter table等
可以通过SET TRANSACTION ISOLATION LEVEL改变隔离级别下一个事务开始时生效
在事务中混合使用存储引擎MySQL的事务由下层存储引擎实现在同一个事务中,混合使用多种存储引擎是不可靠的.
隐式锁定和显式锁定InnoDB使用两阶段锁定协议(two-phase locking protocol).事务执行期间,随时都可以获取锁,但锁只有在提交或回滚后才会释放,并且所有的锁会同时释放.前面描述的锁定机制都是隐式的.InnoDB会根据隔离级别自动处理锁.
显式的(不属于SQL规范)
SELECT … FOR SHARESELECT … FOR UPDATEMySQL还支持LOCK TABLES和UNLOCK TABLES这两个命令在服务器级别实现因为InnoDB支持行级锁没必要使用
建议: 除了在禁用AUTOCOMMIT的事务中可以使用之外,其他任何时候都不要显式地执行LOCK TABLES,不管使用的是什么存储引擎.
多版本并发控制MySQL的大多数事务型存储引擎使用的都不是简单的行级锁机制.它们会将行级锁和可以提高并发性能的多版本并发控制(MVCC)技术结合使用.
不同数据库的实现细节不一样
可以认为MVCC是行级锁的一种变种它在很多情况下避免加锁因此开销更低
通过数据快照实现

InnoDB为每个事务启动时分配一个事务ID
该事务修改记录时向Undo log写入一条如何恢复回去的undo记录事务回滚指针指向该记录
当不同会话读取聚簇主键索引记录时 InnoDB会把记录的事务ID和该会话的读取视图比较如果更改他的事务未提交则跟踪undo log直到一个符合可见条件的事务ID

大多数读取通过这种方式不需要获取锁(通过读取快照) 缺点是存储引擎会对每一行存储更多数据做更多工作
MVCC仅适用于REPEATABLE READ和READ COMMITTED隔离级别.(可以想象对于可重复读读取的事务id固定为事务进行中第一次读的可见事务id 对于读已提交读最新的可见事务id另外两个因为不需要事务版本(一个是脏读一个是串行化的) 和MVCC不是很适配(当然要看不同引擎的实现)
复制Replication一主多从
数据文件结构在8.0版本中,MySQL将表的元数据重新设计为一种数据字典,包含在表的.ibd文件中使得表结构上的信息支持事务和原子级数据定义更改
除了以来information_schema检索表定义和元数据引入了字典对象缓存 LRU的内存缓存使得服务器访问表的元数据减少了I/O每个表的.ibd和.frm文件被替换为已经被序列化的字典信息(.sdi).
InnoDB引擎为处理大量短期事务而设计这些事务预期通常是正常提交很少会被回滚
默认情况下,InnoDB将数据存储在一系列的数据文件中,这些文件统被称为表空间(tablespace)
InnoDB使用MVCC来实现高并发性,并实现了所有4个SQL标准隔离级别.默认为REPEATABLE READ隔离级别,并且通过间隙锁(next-key locking)策略来防止在这个隔离级别上的幻读：InnoDB不只锁定在查询中涉及的行,还会对索引结构中的间隙进行锁定,以防止幻行被插入
基于聚簇索引构建但是,因为二级索引（secondary index,非主键索引）需要包含主键列,如果主键较大,则其他索引也会很大.如果表中的索引较多,主键应当尽量小.
微信读书: https://weread.qq.com/web/bookDetail/00a32b70813ab746fg018ec7博客位置: https://bingowith.me/2022/11/08/high-performance-mysql-4th-ch01-note/