MySQL性能优化(一)：MySQL架构与核心问题

时间  2020-07-15 标签 mysql 性能 优化 架构 核心 问题

在这里插入图片描述

1、前言

做为程序员的你，数据库做为一门必修课，而MySQL数据库毫无疑问已是最经常使用的数据库了。系统的稳定、高效、高并发等指标，很大程度上取决于数据库性能是否够优，可见性能优化的重要性，这也就不难理解各位在任何一场面试中都会被问及到数据库调优相关的问题。html

所以，这就是我为什么考虑写该系列文章的主要缘由，但愿该系列文章(MySQL性能优化)可以给你带来收获，让你更系统、更全面的掌握MySQL性能优化的技能、技巧。该系列文章将会持续分享、更新，若是以为如今或者未来可能对你有用，不妨持续关注、收藏。mysql

在MySQL性能优化以前，你有必要从新再认识下MySQL，便于后续更容易理解MySQL性能优化中涉及到的知识点。本文将从MySQL架构、核心问题来针对性展开讨论，这也将是MySQL性能优化系列文章的开篇之做。程序员

2、MySQL逻辑架构

想深刻探究MySQL以前，有必要了解一下MySQL的逻辑架构，逻辑架构图以下：
在这里插入图片描述
MySQL的逻辑架构中，分为三层，如上图红色虚线框的三部分。web

最上层架构并非MySQL所独有的，大多数基于客户端/服务器形态的系统或者服务，都有相似的架构，其中包含MySQL的链接处理、受权认证、安全控制等等。面试

第二层架构是MySQL中最为核心的部分，其中包括查询解析、分析、优化、缓存以及全部的内置函数(如：日期、时间、函数等)，全部跨存储引擎的功能都在这一层实现，例如：存储过程、触发器、视图等。sql

第三层架构是存储引擎。存储引擎负责MySQL中数据的存储和提取，相似与Linux系统下的各类文件系统同样，不一样存储引擎都有各自的优点和劣势，不一样场景可选择不一样的引擎。不一样存储引擎之间是不会相互通讯的，只是简单地响应上层的请求。数据库

3、如何控制高并发的读写？

不管什么时候，对于数据库而言，高并发的读写操做是很常见的，针对同一条记录在同一时刻进行修改、查询操做，都会产生并发控制的问题，处理不当将会出现大量的脏数据。那么，如何控制高并发的读写操做呢？缓存

1.读写锁

在咱们学习任何一门语言时，针对处理并发问题都会选择锁机制来解决并加以控制，这也是解决并发控制的经典方法，MySQL也不例外。在MySQL处理高并发的读或者写时，能够经过实现两种类型的锁来解决，这两种类型的锁一般被称为共享锁(Shared lock)和排他锁(exclusive lock)，其实就是你们叫的读锁(read lock)和写锁(write lock)。安全

读锁，是共享的，也就是说是互相不阻塞的。多个请求在同一时刻能够同时读取同一条记录，而互不干扰。性能优化

写锁，是排他的，也就是说一个写锁会阻塞其余的写锁和读锁，避免在写的过程当中进行读、再写的操做，这更是出于安全的考虑，只有这样才能确保数据的准确、干净。在数据库中，每时每刻都在发生锁定，当某次请求修改数据时，MySQL都会经过锁来防止其余请求读取同一数据。

2.锁策略

有了锁的机制，就能更好的控制高并发的读写操做，咱们都知道锁也是有范围的，锁定对象范围的选择，更具备挑战性。尽可能只锁定须要修改的部分数据，而不是全部数据，这也是选择锁定对象范围最想知足的。锁定范围越精确，锁定的数据量就越小，则系统的并发程度越高，加锁自己消耗的资源也就越小。

上述提到的无非就是设定锁的粒度，而MySQL则提供了多种选择，每种MySQL存储引擎均可以实现本身的锁策略和锁粒度。下面将介绍两种最经常使用的锁策略。

2.1 表级锁(table lock)

表级锁是MySQL最基本的锁策略，而且是开销最小的策略，它会锁定整张表。一个请求在对表进行写操做(插入、修改、删除等)前，须要先得到写锁，此时会阻塞其余请求对该表的全部读写操做。只有没有写锁时，其余请求才能读取并得到读锁，读锁之间是不相互阻塞的。

尽管存储引擎能够管理本身的锁，并且MySQL自己还会使用各类有效的表级锁来实现不一样的目的。例如，诸如ALTER TABLE之类的语句就使用了表级锁，而忽略存储引擎的锁机制。

开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的几率最高，并发度最低。

表级锁，更适用于以查询为主，只有少许按索引条件更新数据的应用。

2.2 行级锁(row lock)

行级锁能够最大程度地支持并发处理(同时也带来了最大的锁开销)。

开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的几率最低，并发度最高。

行级锁，更适合于有大量按索引起更新少许不一样数据，同时又有并发查询的应用，如一些在线事务处理系统。

4、MySQL存储引擎是怎样的？

在文件系统中，MySQL将每一个数据库(即：schema)保存为数据目录data下的一个子目录。建立表时，MySQL会在数据库data目录下建立一个和表同名的.frm文件来保存表的定义。

不一样的存储引擎保存数据和索引的方式是不一样的，但表的定义则是在MySQL服务层统一处理的。

可使用show table status like '表名' \G命令来查看表的存储引擎以及表的其余相关信息，例如，查看mysql数据库中的user表：

mysql> use mysql;
No connection. Trying to reconnect...
Connection id:    20587
Current database: *** NONE ***

Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show table status like 'user' \G;
*************************** 1. row ***************************
           Name: user
         Engine: MyISAM
        Version: 10
     Row_format: Dynamic
           Rows: 3
 Avg_row_length: 125
    Data_length: 512
Max_data_length: 281474976710655
   Index_length: 4096
      Data_free: 136
 Auto_increment: NULL
    Create_time: 2019-07-12 14:45:17
    Update_time: 2019-12-20 15:55:44
     Check_time: NULL
      Collation: utf8_bin
       Checksum: NULL
 Create_options: 
        Comment: Users and global privileges
1 row in set (0.00 sec)

ERROR: 
No query specified

从查询结果的Engine字段能够代表，user表的存储引擎类型为MyISAM，其余字段在此就不一一说明，如想详细了解可查阅相关文档。

在了解MySQL存储引擎前，能够先看看你的MySQL数据库支持哪些存储引擎，可经过show engines命令查看。我使用的MySQL版本为5.7.25，查看结果以下图所示：
在这里插入图片描述

从上述结果能够看出，支持的存储引擎有： InnoDB、Mrg_Myisam、Memory、Blackhole、MyISAM、CSV、 Archive、Performance_Schema、Federated，其中也作了简单的解释说明。

本文只针对InnoDB、MyISAM两种最多见的存储引擎进行着重说明，其它存储引擎只作简单说明，详细可查阅官方文档。

1.InnoDB存储引擎

InnoDB是MySQL的默认事务型引擎，也是最重要、使用最普遍的存储引擎，而且有行级锁定和外键约束。

它被设计用来处理大量的短时间(short-lived)事务，短时间事务大部分状况是正常提交，不多会被回滚。InnoDB的性能和自动崩溃恢复特性，使得它在非事务型存储的需求中也很流行。除非有很是特别的缘由须要使用其余的存储引擎，不然应该优先考虑InnoDB引擎。

InnoDB的适用场景/特性，有如下几种：

  • 常常更新的表，适合处理多重并发的更新请求。
  • 支持事务。
  • 能够从灾难中恢复（经过bin-log日志等）。
  • 外键约束。只有他支持外键。
  • 支持自动增长列属性auto_increment。

2.MyISAM存储引擎

MyISAM提供了大量的特性，包括全文检索、压缩等，但不支持事务和行级锁，支持表级锁。
对于只读的数据，或者表较小、能够忍受修复操做的场景，依然可使用MyISAM。

MyISAM的适用场景/特性，有如下几种：

  • 不支持事务的设计，可是并不表明着有事务操做的项目不能用MyISAM存储引擎，彻底能够在程序层进行根据本身的业务需求进行相应的控制。
  • 不支持外键的表设计。
  • 查询速度很快，若是数据库insert和update的操做比较多的话比较适用。
  • 成天 对表进行加锁的场景。
  • MyISAM极度强调快速读取操做。
  • MyIASM中存储了表的行数，因而SELECT COUNT(*) FROM TABLE时只须要直接读取已经保存好的值而不须要进行全表扫描。若是表的读操做远远多于写操做且不须要数据库事务的支持，那么MyIASM也是很好的选择。

3.MySQL内建的其余存储引擎

MySQL还有一些特殊用途的存储引擎，在一些特殊场景下用起来会很爽的。在MySQL新版本中，有些可能由于一些缘由已经再也不支持了，还有一些会继续支持，可是须要明确地启用后才能使用。

3.1 Archive存储引擎

Archive引擎只支持insert和select操做，而且在MySQL 5.1以前连索引都不支持。

Archive引擎会缓存全部的写并利用zlib对插入的行进行压缩，因此比MyISAM引擎的磁盘I/O更少。可是每次select查询都须要进行全表扫描，因此Archive更适合日志和数据采集类应用，何况这类应用在作数据分析时每每须要全表扫描。

Archive引擎支持行级锁和专用的缓冲区，因此能够实现高并发的插入。在一个查询开始直到返回表中存在的全部行以前，Archive引擎会阻止其余的select执行，以实现一致性读。另外，这也实现了批量插入在完成以前对读操做是不看见的。

3.2 Blackhole存储引擎

Blackhole引擎没有实现任何的存储机制，它会丢失全部插入的数据，不作任何保存。怪哉，岂不是一无用处？

可是服务器会记录Blackhole的日志，因此能够用于复制数据到备库，或者只是简单地记录到日志。这种特殊的存储引擎能够在一些特殊的复制架构和日志审核时发挥做用。

但这种存储引擎的存在，至今仍是有些难以理解。

3.3 CSV存储引擎

CSV引擎能够将普通的CSV文件做为MySQL的表来处理，但这种表不支持索引。

CSV引擎能够在数据库运行时拷入或者拷出文件，能够将Excel等电子表格软件中的数据存储为CSV文件，而后复制到MySQL数据目录下，就能在MySQL中打开使用。一样，若是将数据写入到一个CSV引擎表中，其余的外部程序也能当即从表的数据文件中读取CSV格式的数据。

所以，CSV引擎能够做为一种数据交换的机制，是很是有用的。

3.4 Memory存储引擎

若是须要快速地访问数据，而且这些数据不会被修改，重启之后丢失也没有关系，那么使用Memory引擎是很是有用的。Memory引擎至少比MyISAM引擎要快一个数量级，由于全部的数据都保存在内存中，不须要进行磁盘I/O。Memory引擎的表结构在重启之后还会保留，但数据会丢失。

Memory引擎在不少场景下能够发挥很好的做用：

  • 用于查找或者映射表，例如将邮箱和州名映射的表。
  • 用于缓存周期性聚合数据的结果。
  • 用于保存数据分析中产生的中间数据。

Memory引擎支持Hash索引，所以查找很是快。虽然Memory的速度很是快，但仍是没法取代传统的基于磁盘的表。Memory引擎是表级锁，所以并发吸入的性能较低。

若是MySQL在执行查询的过程当中，须要使用临时表来保存中间结果，内部使用的临时表就是Memory引擎。若是中间结果太大超出了Memory的限制，或者含有BLOB或TEXT字段，则临时表会转换成MyISAM的引擎。

看了上面的说明，你们就会常常混淆Memory和临时表了。临时表是指使用CREATE TEMPORARY TABLE语句建立的表，它可使用任何存储引擎，所以和Memory不是一回事。临时表只在单个链接中可见，当链接断开时，临时表也将不复存在。

关于临时表和Memory引擎的那些事，可参考MySQL · 引擎特性 · 临时表那些事儿。

MySQL的存储引擎及第三方存储引擎，还有不少，在此就不一一介绍了，后续若有须要，再进一步来谈谈。

4.如何选择合适的存储引擎呢

这么多存储引擎，真是眼花缭乱，咱们该如何选择呢？

大部分状况下，都会选择默认的存储引擎——InnoDB，而且这也是最正确的选择，因此Oracle在MySQL 5.5版本时终于将InnoDB做为默认的存储引擎了。

对于如何选择合适的存储引擎，能够简单地概括为一句话：”除非须要用到某些InnoDB不具有的特性，而且没有其余能够替代，不然都应该优先选择InnoDB引擎”。

例如，若是要用到全文检索，建议优先考虑InnoDB加上Sphinx的组合，而不是使用支持全文检索的MyISAM。固然，若是不须要用到InnoDB的特性，同时其余引擎的特性可以更好地知足需求，就能够考虑一下其余存储引擎。

除非万不得已，建议不要混合使用多种存储引擎，不然可能带来一系列复杂的问题，以及一些潜在的bug和边界问题。

若是须要使用不一样的存储引擎，建议考虑从如下几个因素进行衡量考虑。

  • 事务
  • 备份
  • 恢复
  • 特有的特性

参考文章：

  1. https://www.cnblogs.com/sunsky303/p/8274586.html

  2. https://www.cnblogs.com/coderyuhui/p/10773143.html

联系我们 沪ICP备13005482号-10