vlambda博客
学习文章列表

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

一、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 -