一、架构
MySQL逻辑架构整体分为三层,最上层为客户端,并非MySQL独有,诸如:连接处理,授权认证,安全等功能均在这一层处理
MySQL大多数核心服务均在中间这一层,包括查询解析,分析优化,缓存,内置函数,所有的跨存储引擎功能也在这一层实现:存储过程,触发器,视图等。
最下层为存储引擎,负责MySQL中的数据存储和提取
1.MySQL查询过程
连接层(客户端/服务端通信协议)
- MySQL客户端/服务端的通信协议通常是半双工,要么服务器向客户端发送数据,要么客户端向服务器发送数据,当客户端要查询的时候向服务端发送消息,进行TCP/IP连接或者socket连接,并且向服务端提供自己的用户名和密码,服务端提供专用连接线程,接受用户的SQL,后返回结果
SQL层
- 接受上层传送的SQL语句
- 进行语义检查:判断sql语句的类型
- 权限检查
- 对sql语句进行解析
- 通过关键字将sql语句进行解析,并生成一颗对应的解析树。这个过程解析器主要通过语法规则来验证和校验,比如sql中是否使用了错误的关键字或者关键字的顺序是否正确等。预处理会根据M有SQL规则进一步检查解析树是否合法等
- 进行查询优化
- 重新定义表的关联顺序
- 优化MIN()和MAX()函数(找出某列的最小值,如果该列有索引,只需要查找B+tree索引最左端)
- 提前终止查询(比如:使用limit时,查找到满足数量的结果集合后立即终止查询)
- 优化排序(老版本中先读取行指针和需要排序的字段你在内存中对其排序,然后再更具排序结果去读取数据行,新版本中采用单词传输排序,一次性读取所有的数据行,然后根据给定的列排序,对于I/O密集型应用,会提高效率)
- 性能优化
- 用多个小表代替一个大表,不要过度设计
- 批量插入代替循环单挑插入
- 合理控制缓存空间大小,一般来说其大小设置为及时找比较合适
- 查询缓存(不建议轻易打开查询缓存)
- 在解析一个查询语句钱,如果查询缓存时打开的,那么mysql会检查这个查询语句是否名字拆线呢缓存中的数据,如果当前查询恰好命中查询缓存,在检查一次用户权限后直接返回缓存中的结果
- mysql将缓存放在一个引用表中,可以理解为一个类似于HashMap的数据结构
- 任何的查询语句在开始之前都必须经过检查,即使这条SQL语句永远不会命中缓存
- 如果查询结果可以被缓存,那么执行完成后,会将结果存入缓存,也会带来额外的系统消耗
存储引擎层(类似于linux中的文件)
负责根据SQL层的执行结果,从磁盘上拿数据,返回给客户端
2.MyISAM和InnoDB的特点
MyISAM引擎特点:
- 不支持事务(保证数据安全ACID)
- 表级锁定
- 读写相互阻塞,写时不能读,读时不能写
- 只缓存索引
- 读取数据较快,占用资源较少
- 不支持MVCC(多版本并发控制机制)高并发
- 奔溃恢复性较差
使用场景:
只读(或者写较少时),表较小
InnoDB引擎特点
- 行级锁
- 支持事务,适合处理大量短期事务
- 读写阻塞与事务隔离级别有关
- 可缓存数据和索引
- 奔溃后恢复性较好
- 支持MVCC高并发
- MYSQL5.5后支持全文索引,也是5.5后的默认搜索引擎
备份:备份的时候备份业务数据库和mysql数据库(因为mysql数据库中有用户及权限设置)
3.修改mysql的最大并发连接数
bash
mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 500 |
+-----------------+-------+
1 row in set (0.00 sec)
mysql> set global max_connections =2000;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 2000 |
+-----------------+-------+
1 row in set (0.00 sec)
# 也可在配置文件中修改
[root@server ~]# vim /etc/my.cnf
4.服务器状态变量
服务器状态变量:分全局和会话两种
状态变量(只读):用于保存mysqld运行中的统计数据变量,不可更改
show global status;
show [session] status;
5.服务器变量SQL_MODE
SQL_MODE:对其设置可以完成一些约束检查的工作,可分别进行全局的设置或当前会话的设置
常见MODE:
- NO_AUTO_CREATE_USER: 禁止GRANT创建密码为空的用户
- NO_ZERO_DATE:在严格模式,不允许使用'0000-00-00'的时间
- ONLY_FULL_GROUP_BY: 对于GROUP BY聚合操作,如果在SELECT中的列,没有在GROUP BY中出现,那么将认为这个SQL是不合法的
- NO_BACKSLASH_ESCAPES: 反斜杠""作为普通字符而非转义字符
- PIPES_AS_CONCAT: 将"||"视为连接操作符而非"或"运算符
二、索引
1.index索引介绍
索引:索引是排序的快速查找的特殊数据结构,定义作为查找条件的字段,又称为key,索引通过存储引擎实现,加快查询速度
2.索引优缺点
索引的优点是可以提高检索数据的速度,这是创建索引的最主要的原因;对于有依赖关系的子表和父表之间的;联合查询时,可以提高查询速度;使用分组和排序子句进行数据查询时,同样可以显著节省查询中分组和排序的时间。
索引的缺点是创建和维护索引需要耗费时间,耗费时间的数量随着数据量的增加而增加;索引需要占用物理空间,每一个索引要占一定的物理空间;增加、删除和修改数据时,要动态的维护索引,造成数据的维护速度降低了
优点
- 降低服务需要扫描的数据量,减少I/O次数
- 索引可以帮助服务器避免排序和使用临时表
- 索引可以帮助将随机I/O转为顺序 I/O
缺点:
- 占用额外空间
- 影响插入速度
索引类型:
- B+ TREE、HASH、R TREE、FULL TEXT
- 聚簇(集)索引、非聚簇索引:数据和索引是否存储在一起
- 主键索引、二级(辅助)索引
- 稠密索引、稀疏索引:是否索引了每一个数据项
- 简单索引、组合索引: 是否是多个字段的索引
- 左前缀索引:取前面的字符做索引
- 覆盖索引:从索引中即可取出要查询的数据,性能高
3.B+TREE
B+tree索引:按顺序储存,每一个叶子节点到根节点的举例是相同的;左前缀索引,适合查询范围类的索引;
B-TREE
B+TREE
页面搜索严禁做模糊或者全模糊,如果需要择走搜索引擎来解决
说明:索引文件具有 B-Tree 的最左前缀匹配特性,如果左边的值未确定,那么无法使用此索引
可以使用B+TREE索引的查询类型
- 全值匹配:精确所有索引列
- 匹配最左前缀:只使用索引的第一列
- 匹配列前缀:只匹配一列值开头部分
- 精确匹配某一列范围并匹配另一列
- 只访问索引的查询
B+TREE索引的限制
- 如不从最左列开始,则无法使用索引
- 不能跳过索引中的列
4.索引优化
- 独立的使用列:经历避免其参与运算,独立的列指索引列不能是表达式的而一部分,也不能是函数的参数,在where条件中,始终将索引列单独放在比较符号的一侧,尽量不在列上进行运算
- 左前缀索引:构建指定索引字段的左侧的字符数,要通过索引选择(不重复的索引值和数据表的记录总数的比值)来评估,尽量使用短索引,如果可以,指定一个前缀长度
- 多列索引和索引顺序:AND操作时更适合使用多列索引,而非为每个列创建单独的索引;
- 当出现多个索引做相交操作时(多个AND条件),通常来说一个包含所有相关列的索引要优于多个独立索引
- 当出现多个索引做联合操作时(多个OR条件),对结果集的合并、排序等操作需要耗费大量的CPU和内存资源,特别是当其中的某些索引的选择性不高,需要返回大量合并数据时,查询成本更高
- 选择合适的索引列顺序:无排序和分组时。将选择性最高放左侧
- 只要列中含有NULL值,就最好不要在此列设置索引,复合索引如果有null值,此列在使用时也不会使用索引
- 对于经常在where子句使用的列,最好设置索引
- 对于有多个列where或者order by子句,应该建立复合索引
- 对于like语句,以%或者_开头的不会使用索引,以%结尾会使用索引
- 尽量不要使用not in 和<>操作,虽然可能使用索引,但性能不高
- 不要使用RLIK正则表达式会导致索引失效
- 查询时,能不用就不用,尽量写全字段名,比如select id,name,age from students;
- 大部分情况连接效率远大于子查询
- 在有大量记录的表分页时使用limit
- 对于经常使用的查询,可以开启查询缓存
- 多使用explain和profile分析查询语句
- 查看慢日志,找出执行时间长的sql语句优化
三、并发控制
1.锁机制
类型:
- 读锁:共享锁,也成为S锁,只读不可写(包括当前事务),多个读互不阻塞
- 写锁:独占锁,排它锁,也成为X锁,写锁会阻塞其他事务(不包括当前事务)的的读和写
- S锁和S锁是兼容的,X锁和其他锁都不兼容
- 例:事务 T1 获取了一个行 r1 的 S 锁,另外事务 T2 可以立即获得行 r1 的 S 锁,此时 T1 和 T2 共同获得行 r1 的 S 锁,此种情况称为锁兼容,但是另外一个事务 T2 此时如果想获得行 r1 的 X 锁,则必须等待 T1 对行 r1 锁的释放,此种情况也称为锁冲突
锁粒度:
- 表级锁:MyISAM
- 行级锁:InnoDB
实现
- 存储引擎:自行实现其锁策略和锁粒度
- 服务器级:实现了锁、表级锁、用户可显示请求
分类:
- 隐式锁:由于存储引擎自动施加锁
- 显式锁:用户手动请求
锁策略:在锁粒度以及数据安全性寻求的平衡机制
四、事务
简介:事务Transactios:一组原子性的sql语句,或一个独立工作单元
事务日志:记录事务信息,实现undo,redo故障恢复功能
1.ACID特性:
- A:automictiy原子性:整个事务中的所有操作要么全部成功执行,要么全部失败后回滚
- C:consistency一致性:数据库总是从一个状态转换为另一个一致性状态,类似于能量守恒定律
- I:isolation隔离性:一个事务所作出的操作是在提交之前,是不能为其他事务所见;隔离有多种隔离级别,实现并发(事务的隔离性是多个用户并发访问数据库时,数据库为每一个用户开启的事务,不能被其他事务的操作数据所干扰,多个并发事务之间要相互隔离。)
- D:Durability持久性:持久性是指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,所做的修改永久保存于数据库中,接下来即使数据库发生故障也不应该对其有任何影响,
begin
说明:在5.5 以上的版本,不需要手工begin,只要你执行的是一个DML,会自动在前面加一个begin命令。
commit:提交事务
完成一个事务,一旦事务提交成功 ,就说明具备ACID特性了。
rollback :回滚事务
将内存中,已执行过的操作,回滚回去
注意 :只有事务型存储引擎中的DML语句方能支持此类操作
自动提交:
set autocommit={1|0} 默认未1,未0时设为非自动提交,为0可以提高数据库性能
死锁:
两个或多个事务在同一资源相互占用,并请求锁定对方占用的资源的状态
开始事务流程:
bash
1、检查autocommit是否为关闭状态
select @@autocommit;
或者:
show variables like 'autocommit';
2、开启事务,并结束事务
begin
delete from student where name='alexsb';
update student set name='alexsb' where name='alex';
rollback;
begin
delete from student where name='alexsb';
update student set name='alexsb' where name='alex';
commit;
对于使用 InnoDB 存储引擎的表来说,它的聚簇索引记录中都包含 3 个隐藏列
- db_row_id:隐藏的行 ID。在没有自定义主键也没有 Unique 键的情况下,会使用该隐藏列作为主键。
- db_trx_id:操作这个数据的事务 ID,也就是最后一个对该数据进行插入或更新的事务 ID。
- dbroll_ptr:回滚指针,也就是指向这个记录的 Undo Log 信息。Undo Log 中存储了回滚需要的数据
2.事务的隔离级别
多个线程开启各自事务操作数据库中数据时,数据库系统要负责隔离操作,以保证各个线程在获取数据时的准确性。
如果不考虑隔离性,可能会引发如下问题:
- 幻读 : 是指在一个事务内读取到了别的事务插入的数据,导致前后读取不一致。
- 事务A 按照一定条件进行数据读取, 期间事务B 插入了相同搜索条件的新数据,事务A再次按照原先条件进行读取时,发现了事务B 新插入的数据 称为幻读。
- 不可重复读取 :是指在数据库访问中,一个事务范围内两个相同的查询却返回了不同数据。
- 在一个事务内,多次读同一个数据。在这个事务还没有结束时,另一个事务也访问该同一数据并修改数据。那么,在第一个事务的两次读数据之间。由于另一个事务的修改,那么第一个事务两次读到的数据可能不一样,这样就发生了在一个事务内两次读到的数据是不一样的,因此称为不可重复读,即原始读取不可重复。
- 脏读:指一个事务读取了另外一个事务未提交的数据
bash
# 这是非常危险的,假设A向B转帐100元,对应sql语句如下所示
1. update account set money=money+100 where name='b';
2. update account set money=money-100 where name='a';
隔离级别 | 脏读 | 不可重复读 | 幻读 | 加读锁 |
---|---|---|---|---|
读未提交 | 可以出现 | 可以出现 | 可以出现 | 否 |
读提交 | 不允许出现 | 可以出现 | 可以出现 | 否 |
可重复读 | 不允许出现 | 不允许出现 | 可以出现 | 否 |
序列化 | 不允许出现 | 不允许出现 | 不允许出现 | 是 |
数据库共定义了四种隔离级别:
- Serializable:可避免脏读、不可重复读、虚读情况的发生。(串行化)
- Repeatable read:可避免脏读、不可重复读情况的发生。(可重复读)
- Read committed:可避免脏读情况发生(读已提交)。可读取到提交数据,但未提交数据不可读,产生不可重复读,即可读取到多个提交数据,导致每次
读取数据不一致 - Read uncommitted:最低级别,以上情况均无法保证。(读未提交)
MVCC和事务的隔离级别:
MVCC(多版本并发控制机制)只在READ COMMITTED和REPEATABLE READ两个隔离级别下工作。其
他两个隔离级别都和MVCC不兼容,因为READ UNCOMMITTED总是读取最新的数据行,而不是符合当前
事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁