MySQL的常用优化方案

概述

我们知道， MySQL DB 的数据是存放在磁盘上的，其读写速度无法和存放在内存中的 redis 相比，当 MySQL 记录数过大时，增删改查时系统的吞吐量会非常的大，数据增删改查的性能会急剧下降。为了改善以上情况，我们需要对 MySQL 进行相关优化，可以参考以下步骤来优化：

表结构的优化

字段设计

• 尽量使用 TINYINT 、  SMALLINT 、  MEDIUM_INT 作为整数类型而非  INT ，如果非负则加上UNSIGNED
• VARCHAR 的长度只分配真正需要的空间
• 使用枚举 enum 代替字符串类型
• 尽量使用 TIMESTAMP 而非  DATETIME ，
• 单表不要有太多字段，建议在20以内
• 避免使用 NULL 字段，很难查询优化且占用额外索引空间
• 用整型来存 IP（ INET_ATON(str)，INET_NTOA(number) )
• 适当的字段荣誉，避免过多的 join 查询

索引

• 索引并不是越多越好，要根据查询有针对性的创建，考虑在 WHERE 和  ORDER BY 命令上涉及的列建立索引，可根据  EXPLAIN 来查看是否用了索引还是全表扫描
• 应尽量避免在 WHERE 子句中对字段进行  NULL 值判断，否则将导致引擎放弃使用索引而进行全表扫描
• 值分布很稀少的字段不适合建索引，例如"性别"这种只有两三个值的字段
• 字符字段只建前缀索引
• 字符字段最好不要做主键
• 不用外键，由程序保证约束
• 尽量不用 UNIQUE ，由程序保证约束
• 使用多列索引时主意顺序和查询条件保持一致，同时删除不必要的单列索引

SQL 语句的优化

索引失效的情况

• 当我们使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx%这两种方式都会造成索引失效；
• 当我们在查询条件中对索引列使用函数，就会导致索引失效。
• 当我们在查询条件中对索引列进行表达式计算，也是无法走索引的。
• MySQL 在遇到字符串和数字比较的时候，会自动把字符串转为数字，然后再进行比较。如果字符串是索引列，而条件语句中的输入参数是数字的话，那么索引列会发生隐式类型转换，由于隐式类型转换是通过 CAST 函数实现的，等同于对索引列使用了函数，所以就会导致索引失效。
• 联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引失效。
• 在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。

从以上索引失效的场景分析，我们可对相关查询的 SQL 语句进行以下优化：

查询SQL

• 可通过开启慢查询日志来找出较慢的SQL
• 不做列运算： SELECT id WHERE age + 1 = 10 ，任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等等，查询时要尽可能将操作移至等号右边
• sql语句尽可能简单：一条sql只能在一个cpu运算；大语句拆小语句，减少锁时间；一条大sql可以堵死整个库
• 不用 SELECT *
• OR 改写成  IN ： OR 的效率是n级别，  IN 的效率是log(n)级别，in的个数建议控制在200以内
• 不用函数和触发器，在应用程序实现
• 避免 %xxx 式查询
• 少用 JOIN
• 使用同类型进行比较，比如用 '123' 和  '123' 比，  123 和  123 比
• 尽量避免在 WHERE 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描
• 对于连续数值，使用 BETWEEN 不用  IN ： SELECT id FROM t WHERE num BETWEEN 1 AND 5
• 列表数据不要拿全表，要使用 LIMIT 来分页，每页数量也不要太大
• 对join语句匹配关系（on）涉及的字段建立索引

读写分离

也是目前常用的优化，从库读主库写，一般不要采用双主或多主引入很多复杂性，尽量采用文中的其他方案来提高性能。同时目前很多拆分的解决方案同时也兼顾考虑了读写分离。 cloud.tencent.com/developer/a…

分区

一般情况下我们创建的表对应一组存储文件，使用MyISAM存储引擎时是一个.MYI和.MYD文件，使用Innodb存储引擎时是一个.ibd和.frm（表结构）文件。MySQL的物理数据，存储在表空间文件（.ibdata1和.ibd）中，这里讲的分区的意思是指将同一表中不同行的记录分配到不同的物理文件中，几个分区就有几个.idb文件。

MySQL在5.1时添加了对水平分区的支持。分区是将一个表或索引分解成多个更小，更可管理的部分。每个区都是独立的，可以独立处理，也可以作为一个更大对象的一部分进行处理。这个是MySQL支持的功能，业务代码无需改动。

MySQL分区类型

目前MySQL支持一下几种类型的分区：

• RANGE分区：基于一个给定区间边界，得到若干个连续区间范围，按照分区键的落点，把数据分配到不同的分区；
• LIST分区：类似RANGE分区，区别在于LIST分区是基于枚举出的值列表分区，RANGE是基于给定连续区间范围分区；
• HASH分区：基于用户自定义的表达式的返回值，对其根据分区数来取模，从而进行记录在分区间的分配的模式。这个用户自定义的表达式，就是MySQL希望用户填入的哈希函数。
• KEY分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且使用MySQL 服务器提供的自身的哈希函数。

如果表存在主键或者唯一索引时，分区列必须是唯一索引的一个组成部分。

在实战中，十有八九都是用RANGE分区。

分区优化

用户的SQL语句是需要针对分区表做优化，SQL条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区，可以通过 EXPLAIN PARTITIONS 来查看某条SQL语句会落在那些分区上，从而进行SQL优化，如下图5条记录落在两个分区上：

分区的好处是：

• 可以让单表存储更多的数据
• 分区表的数据更容易维护，可以通过清楚整个分区批量删除大量数据，也可以增加新的分区来支持新插入的数据。另外，还可以对一个独立分区进行优化、检查、修复等操作
• 部分查询能够从查询条件确定只落在少数分区上，速度会很快
• 分区表的数据还可以分布在不同的物理设备上，从而搞笑利用多个硬件设备
• 可以使用分区表赖避免某些特殊瓶颈，例如InnoDB单个索引的互斥访问、ext3文件系统的inode锁竞争
• 可以备份和恢复单个分区

分区的限制和缺点：

• 一个表最多只能有1024个分区
• 如果分区字段中有主键或者唯一索引的列，那么所有主键列和唯一索引列都必须包含进来
• 分区表无法使用外键约束
• NULL值会使分区过滤无效
• 所有分区必须使用相同的存储引擎

分区场景

• 最适合的场景数据的时间序列性比较强，则可以按时间来分区，如下所示：

CREATE TABLE members ( 
    firstname VARCHAR(25) NOT NULL,        
    lastname VARCHAR(25) NOT NULL,        
    username VARCHAR(16) NOT NULL,        
    email VARCHAR(35),        
    joined DATE NOT NULL    
) PARTITION BY RANGE( YEAR(joined) ) (        
    PARTITION p0 VALUES LESS THAN (1960),        
    PARTITION p1 VALUES LESS THAN (1970),        
    PARTITION p2 VALUES LESS THAN (1980),        
    PARTITION p3 VALUES LESS THAN (1990),        
    PARTITION p4 VALUES LESS THAN MAXVALUE    
); 

查询时加上时间范围条件效率会非常高，同时对于不需要的历史数据能很容的批量删除。

如果数据有明显的热点，而且除了这部分数据，其他数据很少被访问到，那么可以将热点数据单独放在一个分区，让这个分区的数据能够有机会都缓存在内存中，查询时只访问一个很小的分区表，能够有效使用索引和缓存。

注意，如果sql语句不指定分区，则会走所有分区，性能反而会不升反降。所以分区表后，select语句必须走分区键。

水平分割和垂直分割

水平分割

水平分割是通过某种策略将数据分片来存储，分库内分表和分库两部分，每片数据会分散到不同的MySQL表或库，达到分布式的效果，能够支持非常大的数据量。前面的表分区本质上也是一种特殊的库内分表

库内分表，仅仅是单纯的解决了单一表数据过大的问题，由于没有把表的数据分布到不同的机器上，因此对于减轻MySQL服务器的压力来说，并没有太大的作用，大家还是竞争同一个物理机上的IO、CPU、网络，这个就要通过分库来解决。

水平拆分的优点是:

• 不存在单库大数据和高并发的性能瓶颈
• 应用端改造较少
• 提高了系统的稳定性和负载能力

缺点是：

• 分片事务一致性难以解决
• 跨节点Join性能差，逻辑复杂
• 数据多次扩展难度跟维护量极大

垂直分割

垂直分割是根据数据库里面的数据表的相关性进行拆分，比如：一个数据库里面既存在用户数据，又存在订单数据，那么垂直拆分可以把用户数据放到用户库、把订单数据放到订单库。垂直分表是对数据表进行垂直拆分的一种方式，常见的是把一个多字段的大表按常用字段和非常用字段进行拆分，每个表里面的数据记录数一般情况下是相同的，只是字段不一样，使用主键关联。

垂直拆分的优点是：

• 可以使得行数据变小，一个数据块(Block)就能存放更多的数据，在查询时就会减少I/O次数(每次查询时读取的Block 就少)
• 可以达到最大化利用Cache的目的，具体在垂直拆分的时候可以将不常变的字段放一起，将经常改变的放一起
• 数据维护简单

缺点是：

• 主键出现冗余，需要管理冗余列
• 会引起表连接JOIN操作（增加CPU开销）可以通过在业务服务器上进行join来减少数据库压力
• 依然存在单表数据量过大的问题（需要水平拆分）
• 事务处理复杂

分片原则

• 能不分就不分，参考 单表优化
• 分片数量尽量少，分片尽量均匀分布在多个数据结点上，因为一个查询SQL跨分片越多，则总体性能越差，虽然要好于所有数据在一个分片的结果，只在必要的时候进行扩容，增加分片数量
• 分片规则需要慎重选择做好提前规划，分片规则的选择，需要考虑数据的增长模式，数据的访问模式，分片关联性问题，以及分片扩容问题，最近的分片策略为范围分片，枚举分片，一致性Hash分片，这几种分片都有利于扩容
• 尽量不要在一个事务中的SQL跨越多个分片，分布式事务一直是个不好处理的问题
• 查询条件尽量优化，尽量避免Select * 的方式，大量数据结果集下，会消耗大量带宽和CPU资源，查询尽量避免返回大量结果集，并且尽量为频繁使用的查询语句建立索引。
• 通过数据冗余和表分区赖降低跨库Join的可能

这里特别强调一下分片规则的选择问题，如果某个表的数据有明显的时间特征，比如订单、交易记录等，则他们通常比较合适用时间范围分片，因为具有时效性的数据，我们往往关注其近期的数据，查询条件中往往带有时间字段进行过滤，比较好的方案是，当前活跃的数据，采用跨度比较短的时间段进行分片，而历史性的数据，则采用比较长的跨度存储，即数据冷热分离

总体上来说，分片的选择是取决于最频繁的查询 SQL 的条件，因为不带任何 where 语句的查询 SQL ，会遍历所有的分片，性能相对最差，因此这种 SQL 越多，对系统的影响越大，

慢查询日志

用于记录执行时间超过某个临界值的SQL日志，用于快速定位慢查询，为我们的优化做参考。

开启慢查询日志

配置项：slow_query_log

可以使用show variables like ‘slov_query_log’查看是否开启，如果状态值为OFF，可以使用set GLOBAL slow_query_log = on来开启，它会在datadir下产生一个xxx-slow.log的文件。

设置临界时间

配置项：long_query_time

查看：show VARIABLES like 'long_query_time'，单位秒

设置：set long_query_time=0.5

实操时应该从长时间设置到短的时间，即将最慢的SQL优化掉

查看日志

一旦SQL超过了我们设置的临界时间就会被记录到xxx-slow.log中

profile信息

配置项：profiling

开启profile

set profiling=on

开启后，所有的SQL执行的详细信息都会被自动记录下来

mysql> show variables like 'profiling';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling     | OFF   |
+---------------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> set profiling=on;
Query OK, 0 rows affected, 1 warning (0.00 sec)

查看profile信息

show profiles

mysql> show variables like 'profiling';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling     | ON    |
+---------------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> insert into article values (null,'test profile',':)');
Query OK, 1 row affected (0.15 sec)

mysql> show profiles;
+----------+------------+-------------------------------------------------------+
| Query_ID | Duration   | Query                                                 |
+----------+------------+-------------------------------------------------------+
|        1 | 0.00086150 | show variables like 'profiling'                       |
|        2 | 0.15027550 | insert into article values (null,'test profile',':)') |
+----------+------------+-------------------------------------------------------+

通过Query_ID查看某条SQL所有详细步骤的时间

show profile for query Query_ID

上面show profiles的结果中，每个SQL有一个Query_ID，可以通过它查看执行该SQL经过了哪些步骤，各消耗了多场时间

典型的服务器配置

以下的配置全都取决于实际的运行环境

• max_connections，最大客户端连接数

  mysql> show variables like 'max_connections';
  +-----------------+-------+
  | Variable_name   | Value |
  +-----------------+-------+
  | max_connections | 151   |
  +-----------------+-------+
  

• table_open_cache，表文件句柄缓存（表数据是存储在磁盘上的，缓存磁盘文件的句柄方便打开文件读取数据）

  mysql> show variables like 'table_open_cache';
  +------------------+-------+
  | Variable_name    | Value |
  +------------------+-------+
  | table_open_cache | 2000  |
  +------------------+-------+
  

• key_buffer_size，索引缓存大小（将从磁盘上读取的索引缓存到内存，可以设置大一些，有利于快速检索）

  mysql> show variables like 'key_buffer_size';
  +-----------------+---------+
  | Variable_name   | Value   |
  +-----------------+---------+
  | key_buffer_size | 8388608 |
  +-----------------+---------+
  

• innodb_buffer_pool_size，Innodb存储引擎缓存池大小（对于Innodb来说最重要的一个配置，如果所有的表用的都是Innodb，那么甚至建议将该值设置到物理内存的80%，Innodb的很多性能提升如索引都是依靠这个）

  mysql> show variables like 'innodb_buffer_pool_size';
  +-------------------------+---------+
  | Variable_name           | Value   |
  +-------------------------+---------+
  | innodb_buffer_pool_size | 8388608 |
  +-------------------------+---------+
  

• innodb_file_per_table（innodb中，表数据存放在.ibd文件中，如果将该配置项设置为ON，那么一个表对应一个ibd文件，否则所有innodb共享表空间）