time 20200102
author Venki
MYSQL点注
- MysQL 最重要、最与众不同的特性是它的存储引擎架构，这种架构的设计将查询处理（ Que 斗 Processing ）及其他系统任务（ Servcr 介 sk ）和数据的存储／提取相分离。这种处理和存储分离的设计可以在使用时根据性能、特性，以及其他需求来选择数据存储的方式。
- MySQL默认采用自动提交模式，如果不是显示的开始一个事务，则每个查询都被当作一个事务执行提交操作。但是如果禁用，那么所有查询都是在一个事务中直至显式地执行commit提交或者rollback回滚。修改autocommit对非事务型的表，比如myisam或者内存表，不会有任何影响。
- MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的
- 如果事务需要回滚，非事务型的表上的变更就无法撤销，这会导致数据库处于不一致的状态，这种情况很难修复，事务的最终结果将无法确定
- InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较
关键逻辑图
- MySQL逻辑架构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zVGrWgIA-1609308479142)(http://images1.poetchao.com/MySQL%E9%80%BB%E8%BE%91%E6%9E%B6%E6%9E%84.png)]
- 最上层的服务并不是 MySQL 所独有的，大多数基于网络的客户端／服务器的工具或者服务都有类似的架构。比如连接处理、授权认证、安全等等
- 第二层架构是 MySQL 比较有意思的部分。大多数MySQL的核心服务功能都在这一层，包括查询解析、分析、优化、缓存以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等
- 第三层包含了存储引擎。存储引擎负责 MysQL 中数据的存储和提取。和GNu/Linux下的各种文件系统一样，每个存储引擎都有它的优势和劣势。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎API包含几十个底层函数，用于执行诸如“开始一个事务”或者“根据主键提取一行记录”等操作。但存储引擎不会去解析SQL注’，不同存储引擎之间也不会相互通信，而只是简单地响应上层服务器的请求
第一章
- 连接管理与安全性
- 每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程往。当客户端（应用）连接到 MySQL 服务器时，服务器需要对其进行认证．认证基于用户名、原始主机信息和密码。如果使用了安全套接字（ SSL ）的方式连接，还可以使用 X.509 证书认证，一旦客户端连接成功，服务器会继续验证该客户端是否具有执行某个特定查询的权限（例如，是否允许客户端对 world 数据库的 Country 表执行 SELEcr 语句）
- 优化器并不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等
- 对于 SELECT 语句，在解析查询之前，服务器会先检查查询缓存（ Query cachc ) ，如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集
- 共享锁也叫读锁，排他锁也叫写锁
- 读锁是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一个资源，而互不干扰。写锁则是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑，只有这样，才能确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源
- 表锁
表锁是 MySQL 中最基本的锁策略，并且是开销最小的策略。表锁非常类似于前文描述的邮箱加锁机制：它会锁定整张表
一个用户在对表进行写操作（插入、删除、更新等）前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作
只有没有写锁时，其他读取的用户才能获得读锁，读锁之间是不相互阻塞的。在特定的场景中，表锁也可能有良好的性能
写锁也比读锁有更高的优先级，因此一个写锁请求可能会被插入到读锁队列的前面（写锁可以插人到锁队列中读锁的前面，反之读锁则不能插入到写锁的前面）
尽管存储引擎可以管理自己的锁， MySQL 本身还是会使用各种有效的表锁来实现不同的目的。例如，服务器会为诸如 ALTER TABL 〔 之类的语句使用表锁，而忽略存储引擎的锁机制
- 行锁
行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）
众所周知，在 InnoDB 和 xtraDB ，以及其他一些存储引擎中实现了行级锁
行级锁只在存储引擎层实现，而 MySQL 服务器层没有实现．服务器层完全不了解存储引擎中的锁实现。在本章的后续内容以及全书中，所有的存储引擎都以自己的方式显现了锁机制
- 事务
4.2 ACID
- 原子性
一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性
- 一致性
数据库总是从一个一致性的状态转换到另外一个一致性的状态。在前面的例子中，一致性确保了，即使在执行第三、四条语句之间时系统崩溃，支票账户中也不会损失 200 美元，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中
- 隔离性
通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。在前面的例子中，当执行完第三条语句、第四条语句还未开始时，此时有另外一个账户汇总程序开始运行，则其看到的支票账户的余额并没有被减去 200 美元。后面我们讨论隔离级别（ Isolation level ）的时候，会发现为什么我们要说“通常来说”是不可见的
- 持久性
一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。持久性是个有点模糊的概念，因为实际上持久性也分很多不同的级别。有些持久性策略能够提供非常强的安全保障，而有些则未必。而且不可能有能做到 100 ％的持久性保证的策略（如果数据库本身就能做到真正的持久 J 性，那么备份又怎么能增加持久性呢？）
4.3 隔离级别
- READ UNCOMMITTED （未提交读）
在此级别中，事务中的修改，即使没有提交，对其他事务也是可见的。
- READ COMMITTED（提交读）
只能看见已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。
- REPEATABLE READ（可重复读）
该级别保证了在同一个事务中多次读取同样记录的结果是一致的。
- SERIALIZABLE（可串行化）
隔离级别中，最高级别。强制事务串行执行，避免了前面说的幻读问题。SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题
- 数据引擎
5.1 InnoDB
5.2 MyISAM
-
MyISAM不支持事务和行级锁，而且有一个毫无疑问的缺陷就是崩溃后无法安全恢复
-
MyISAM特性-加锁并发
MyISAM对整张表加锁，而不是针对行。读取时会对需要读到的所有表加共享锁，写入时则对表加排他锁。但是在表有读取查询的同时，也可以往表中插入新的记录（这被称为并发插入）
- MyISAM特性-修复
对于MyISAM表，MySQL可以手工或者自动执行检查和修复操作，但这里说的修复和事务恢复以及崩溃恢复是不同的概念。执行表的修复可能导致一些数据丢失，而且修复操作是非常慢的。
- MyISAM特性-索引特性
对于MyISAM表，即使是BLOB和TEXT等长字段，也可以基于其前500个字符创建索引。MyISAM也支持全文索引。
- MyISAM特性-延迟更新索引键
创建MyISAM表的时候，如果指定了DELAY_KEY_WRITE选项，在每次修改执行完成时，不会立刻将修改的索引数据写入磁盘，而是会写到内存中的缓冲区，只有在情理键缓冲区或者关闭表的时候才会将对应的索引块写入到磁盘。这种方式可以极大地提升写入性能，但是在数据库或者主机崩溃时会造成索引损坏，需要执行修复操作。延迟更新的特性，可以在全局设置，也可以为单个表设置
辅助知识
- 线程
线程（英语：thread）是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务
数据库幻读：指的就是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入新的记录，当之前的事务再次读取该范围的记录时，会产生幻行
InnoDB目前处理死锁的方法是：将持有最少行级排它锁的事务进行回滚
第三章 服务器性能分析
- 性能优化简介
- 吞吐量
单位时间内的查询数量