鲸技术：MySql数据库之性能优化

Posted 2021-04-29 中航鲸技术

一、mysql的整体结构

二、存 储引擎介绍

MySQL中的数据用各种不同的技术存储在文件(或者内存)中，这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。而存储引擎说的就是：

1)如何存储数据。

2)如何为存储的数据建立索引。

3)如何更新、查询数据等技术的实现方法。

下面我们介绍两种存储引擎：InnoDB和MyISAM。

1) InnoDB

InnoDB是一个健壮的事务型存储引擎，这种存储引擎已经被很多互联网公司使用，为用户操作非常大的数据存储提供了一个强大的解决方案。InnoDB还引入了行级锁定和外键约束。

在以下场合下，使用InnoDB是最理想的选择：更新密集的表、事务、自动灾难恢复、外键约束、自动增加列AUTO_INCREMENT属性。

一般来说，如果需要事务支持，并且有较高的并发读取频率，InnoDB是不错的选择。

2) MyISAM

MyISAM表是独立于操作系统的，每当我们建立一个MyISAM引擎的表时，就会在本地磁盘上建立三个文件，文件名就是表名。如果创建一个system_user表，那么就会生成以下三个文件：system_user.frm(存储表定义)、system_user.MYD(存储数据)、system_user.MYI(存储索引)。MyISAM表无法处理事务，这就意味着有事务处理需求的表，不能使用MyISAM存储引擎。

在以下场合下，使用MyISAM是最理想的选择：选择密集型的表、插入密集型的表。

一般来说，MyISAM存储引擎很适合管理服务器日志数据。

3) 存储引擎对比

特性	InnoDB	MyISAM
存储限制	64TB	No
支持事物	Yes	No
锁机制	表锁、行锁	表锁
CRUD操作	读写	读多
Count操作	扫表	专门存储的位置
索引结构	B+Tree	B+Tree

三、性能优化

1) 优化原则

a.永远用小结果集驱动大结果集。

b.只取出自己需要的列。

c.仅仅使用最有效的过滤条件。

d.尽可能避免复杂的join和子查询。

2) Join、Order by、Group by、Distinct解释

a.Join

永远用小结果集驱动大结果集。

保证被驱动表上的join条件字段已经被索引。

Join buffer大小。

b.Order by

索引顺序一致的话不需要排序。

加大max_length_for_sort_data从而使用更快的排序方法(排序只针对需要排序的字段)。

内存不充足时，去掉不必要的返回字段。

增大sort_buffer_size，减少排序过程中对需要排序的数据进行分析。

c.Group by

Group by的前提是Order by

d.Distinct

Distinct前提是Group by

总结：性能是一个整体概念，很多Join、Order by、Group by、Distinct、limit都是基于索引的，所以需要把索引创建好。

四、实战场景

1) 典型OLTP(on-line transaction processing)应用系统

对于各种数据库系统环境中大家最常见的OLTP系统，其特点是 并发量大 ， 整体数据量比较多 ，但 每次访问的数据比较少 ，且访问的 数据比较离散 ， 活跃数据占总体数据的比例不是太大 。对于这类系统的数据库实际上是最难维护，最难以优化的，对主机整体性能要求也是最高的。

针对上面的这些特点和分析，我们可以对OLTP的得出一个大致的方向：

a.虽然系统总体数据量较大，但是系统活跃数据在数据总量中所占的比例不大，那么我们可以通过扩大内存容量来尽可能多的将活跃数据cache到内存中；

b.虽然IO访问非常频繁，但是每次访问的数据量较少且很离散，那么我们对磁盘存储的要求是IOPS表现要很好，吞吐量是次要因素；

c.并发量很高，CPU每秒所要处理的请求自然也就很多，所以CPU处理能力需要比较强劲；

d.虽然与客户端的每次交互的数据量并不是特别大，但是网络交互非常频繁，所以主机与客户端交互的网络设备对流量能力也要求不能太弱；

2) 典型OLAP(on-line analyses processing)应用系统

用于数据分析的OLAP系统的主要特点就是 数据量非常大 ， 并发访问不多 ，但每次访问所需要 检索的数据量都比较多 ，而且 数据访问相对较为集中 ， 没有太明显的活跃数据概念 。

针对上面的这些特点和分析，我们可以对OLAP的得出一个大致的方向：

a.数据量非常大，所以磁盘存储系统的单位容量需要尽量大一些；

b.单次访问数据量较大，而且访问数据比较集中，那么对IO系统的性能要求是需要有尽可能大的每秒IO吞吐量，所以应该选用每秒吞吐量尽可能大的磁盘；

c.虽然IO性能要求也比较高，但是并发请求较少，所以CPU处理能力较难成为性能瓶颈，所以CPU处理能力没有太苛刻的要求；

d.虽然每次请求的访问量很大，但是执行过程中的数据大都不会返回给客户端，最终返回给客户端的数据量都较小，所以和客户端交互的网络设备要求并不是太高；

e.由于OLAP系统由于其每次运算过程较长，可以很好的并行化，所以一般的OLAP系统都是由多台主机构成的一个集群，而集群中主机与主机之间的数据交互量一般来说都是非常大的，所以在集群中主机之间的网络设备要求很高。

五、运营平台

运营平台日常使用的收益统计相关的性能优化，可根据业务需求先查询出产品代码，然后根据产品代码查询出申请日期和代理公司列表，再根据产品代码、申请日期和代理公司构造出三级联动的列表。这样处理的结果既满足了业务需求，又避免了一些不必要的查找结果。

如图所示：

一级列表sql语句

SELECT
 ''' result column '''
 FROM
 Table_name_1 pdr,
 Table_name_2 pi,
 Table_name_3 pti 
WHERE
 pdr.productid = pi.id 
 AND pi.fundcode = pti.fundcode 
GROUP BY pti.fundcode, pti.NAME

二级列表sql语句

SELECT
 ''' result column '''
FROM
 (
SELECT
 ''' result column '''
FROM
 table_name_1 pdr
 INNER JOIN table_name_2 pi ON pi.id = pdr.productid
 INNER JOIN table_name_3 pti ON pti.fundcode = pi.fundcode
 INNER JOIN table_name_4 o ON o.pay_detail_raiser_pkid = pdr.pkid
 LEFT JOIN table_name_5 pdp ON pdp.orderid = o.id
WHERE AND pi.fundcode = 'DM001' 
) t 
GROUP BY t.request_date, t.vendor

三级列表sql语句

SELECT
  ''' result column '''
FROM
 table_name_1 pi
 LEFT JOIN table_name_2 pdr ON pdr.productid = pi.id
 LEFT JOIN table_name_3 pti ON pi.fundcode = pti.fundcode
 LEFT JOIN table_name_4 pr ON pti.product_raiser_pkid = pr.pkid
WHERE pi.transferable = '1' 
 AND pr.investor_type = '01' 
 AND pi.fundcode IN ( 'DM001' ) 
 AND pi.vendor IN ( '02' ) 
 AND pdr.request_date IN ( '2019-03-11' ) 
GROUP BY pi.id, pi.NAM

总结：对于性能的优化方式有很多种，可以优化现有表结构数据的存储方式等。也可根据现有数据的特性采用关系型数据库或者非关系型数据库。

The world's most popular open source database

---

- END -