开发者社区> neo.wang> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

如何从设计和规范上规避RDS性能问题?【阿里云MVP月度分享】

简介: 在初创型互联网公司中,开发们整天想的唯一一件事,就是“把功能做出来”;而当公司业务量逐渐上涨、甚至翻了好几番之后,最开始的程序上的问题,就一个接一个地暴露了出来。
+关注继续查看

在初创型互联网公司中,开发们整天想的唯一一件事,就是“把功能做出来”。而当公司业务量逐渐上涨、甚至翻了好几番之后,最开始的程序上的问题,就一个接一个地暴露了出来。
其中,最明显的,就是数据库的压力问题。下文提到的数据库,都指RDS for MYSQL

场景一:宽表

现象

开发在设计表结构的时候,很大程度上是在参考产品原型的设计。通常会把产品原型中,需要一起查询的条件、一起展示的字段,都放在同一张表中。而互联网公司的产品迭代又是非常快的,新功能层出不穷,开发没有时间重新梳理数据库结构,就盲目地在原来的表上增加冗余字段,为了使功能尽快开发完成。这就使得某些“老古董”的表,越来越宽,七八十个字段以上的大宽表越来越多。

建议

(1)单个InnoDB表的字段数,建议少于50个;
(2)大字段,例如:text、blob类型,考虑单独存放;

场景二:列表的行数查询

现象

在后台或者部分前端的功能中,常常会出现类似MIS系统的列表查询功能。一般这种功能,都是按照选定的查询条件,先查出行数,再按照分页规则查询出第一页的数据。于是,就出现了这样的几种情况:
(1)查询列表明细,是需要使用多表关联查询的。开发为了方便,直接把这个查询明细的“多表关联”的SQL拿过来,把select后边的字段改成count(*),就直接作为查询行数的SQL,甚至连order by都不去掉。而从业务上来说,查询行数的时候,只需要查询其中一张表就可以了;
(2)代码逻辑的设计不合理,导致某些开发,直接套用“首页”逻辑,查询后续每一页的时候,都重新查询了一遍行数;

建议

(1)增加SQL审核机制,不合规范的SQL不允许上线;
(2)增加代码审核机制;

场景三:查询不走索引

现象

很常见的情况是,某些表最开始的数据量很小,后来由于产品功能重心的调整,变成了大表。之前做好的程序、SQL、表结构却没有跟着调整。就出现了很多大表查询,没走索引,导致的慢查询。而慢查询堆积多了,整个数据库就瘫痪了,于是就出现了“次要业务拖累主要业务”的现象。

建议

(1)根据查询场景,设置合理的索引,组合索引优先;
(2)当组合索引和单字段索引同时存在时,建议删掉单字段索引,避免优化器做“无用功”;

场景四:线上数据和线下数据没有隔离

现象

这里说的线上数据,指的是直接面对广大用户的数据;线下数据,是面向公司内部客服、运营的后台系统用到的数据。后台系统由于工作职责的不同,会有各种各样的查询需求,有的可能会很大、很复杂,比如导出一整个月、一整个季度的数据。会直接导致数据的压力非常大,进而影响了整个数据库实例,导致线上系统发生故障。

建议

  • 线上数据的特点是:

    1. 访问量大;
    2. 每个用户只查自己的数据,可以命中索引;
    3. 查询条件简单;
    4. 返回条数少;
    5. 对响应时间要求极高;
    6. 对数据的时效性要求高;
  • 线下数据的特点是:

    1. 访问量小;
    2. 后台同事会查询整个平台的数据,不容易命中索引;
    3. 查询条件复杂;
    4. 返回条数大;
    5. 对响应时间要求不高;
    6. 对数据的时效性要求不是特别高;

综上,两类数据从各个方面都是完全不同的。要把线上数据和线下数据隔离开来。更新时,统一更新线上数据;查询时,线上查线上,线下查线下。线上数据通过DTS等实时数据同步的方式更新到线下。

场景五:过于依赖MYSQL,没有考虑其他的存储

现象

某些列表查询类场景,可能涉及到10~20个查询条件,而且检索数据量一般也很大。此时再使用MYSQL就比较吃力了,索引几乎无法覆盖。

建议

除了关系型数据库之外,我们有很多不同的数据存储的选择,比如:搜索引擎类、NOSQL类、时序类、缓存类,等等。应当根据不同的查询场景,选择最适合的数据存储方式。企图用MYSQL解决一切问题,是不明智的。

场景六:没有站在数据库的角度去思考

现象

比如,子查询。开发站在人类的角度思考问题,就会出现形如:

SELECT * FROM table1 WHERE id IN ( SELECT id FROM table2 );

这种子查询。而MYSQL在处理子查询的时候,是拿外层的每一条数据,去内层扫描,结果就是扫描了table1的行数 × table2的行数次。

建议

避免使用子查询,改为通过索引做表关联等方式;

场景七:直接在数据库中做计算

现象

部分开发会在SQL中写例如case whengroup by + count/sum等的计算。MYSQL擅长的是,数据的查询与存储,并不擅长做计算——虽然它可以做。导致出现了很多慢SQL。MYSQL只对查询做了优化,并没有对计算做优化。

建议

(1)group by + count/sum可以考虑进行预计算;
(2)case when可以在业务端或者前端进行;
(3)要有效利用每个工具最擅长做的事。

场景八:在索引字段上用函数

现象

部分表在bigint类型的、存放时间戳的字段上做了索引,而查询的条件是精确到天的。某些开发就会把SQL写成:

WHERE from_unixtime(create_timestamp) >= '2018-01-01'
AND from_unixtime(create_timestamp) < '2018-02-01'

这样。在索引字段上使用函数,索引就起不到作用,扫描数据的时候依然是全表扫描,并对每一行数据的create_timestamp做from_unixtime运算。

建议

如:

WHERE from_unixtime(create_timestamp) >= '2018-01-01'
AND from_unixtime(create_timestamp) < '2018-02-01'

这种场景,可以改为:

WHERE create_timestamp >= unix_timestamp('2018-01-01')
AND create_timestamp < unix_timestamp('2018-02-01')

这样,只会计算一次,然后直接去匹配索引。避免了全表扫描。

场景九:没有充分利用缓存

现象

部分对数据实时性要求不高的场景。会有相同条件的查询频繁执行的情况,甚至于并发执行多个相同查询条件的查询。这时候如果每次都查询数据库,势必造成了资源的浪费。

建议

把这部分查询结果,缓存到redis中。把大部分请求量引到redis去。

场景十:单表数据量过大

现象

由于对MYSQL依赖严重,导致很多更适合存在NOSQL数据库的数据,也被存到了MYSQL中,而且行数非常多。这样的表,无论是查询、还是更新、或是DDL操作,都需要停服之后、花大量时间去做。

建议

(1)单表不要超过1千万行,大小不要超过5G;如果超过,可以考虑分库分表;
(2)根据场景,考虑用其他数据存储工具、或其他业务上的逻辑来解决大表的问题;

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
十分钟了解阿里云数据库RDS
简介:阿里云关系型数据库(Relational Database Service,简称RDS)是一种稳定可靠、可弹性伸缩的在线数据库服务。基于阿里云分布式文件系统和SSD盘高性能存储,RDS支持MySQL、SQL Server、PostgreSQL、PPAS(Postgre Plus Advanced Server,高度兼容Oracle数据库)和MariaDB TX引擎,并且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。
10723 0
免费享受同城双可用区高可用容错能力!阿里云云数据库RDS新增可用区6月汇总(内含福利)
6月份,阿里云云数据库 MySQL 版,云数据库 PPAS 版,云数据库 SQL Server 版,云数据库 PostgreSQL 版均宣布新增可用区,用户在控制台上按需求创建实例,即可享受同城双可用区高可用容错能力。接下来小编将为大家详细列出新增可用区。
2729 0
MSSQL · 最佳实践 · 实例级别数据库上云RDS SQL Server
摘要 到目前,我们完成了SQL Server备份还原专题系列八篇月报分享:三种常见的数据库备份、备份策略的制定、查找备份链、数据库的三种恢复模式与备份之间的关系、利用文件组实现冷热数据隔离备份方案、如何监控备份还原进度、阿里云RDS SQL自动化迁移上云的一种解决方案以及上个月分享的RDS SDK实现数据库迁移上阿里云,本期我们分享如何将用户线下或者ECS上自建实例级别数据库一键迁移上阿里云RDS SQL Server。
1675 0
阿里云云数据库RDS秒级监控功能解锁,通宵加班找故障将成为过去式
每一个奋斗在前线的数据库管理员和运维人员似乎运气都不太好,这些人都绝对经历过的诡异事件就是:逢年过节必出故障,明明眼看着要休假了,又接到故障通知,只好通宵加班找问题。没问题的时候可能大家都不会想到你,一出问题就先拿运维试问,于是每逢佳节便出现拜数据库的戏谑图片。
2716 0
重磅干货免费下载!阿里云RDS团队论文被数据库顶会SIGMOD 2018收录
来自阿里云RDS团队的论文“**TcpRT: Instrument and Diagnostic Analysis System for Service Quality of Cloud Databases at Massive Scale in Real-time” (TcpRT:面向大规模海量云数据库的服务质量实时采集与诊断系统)**被数据库顶会SIGMOD 2018收录。
10381 0
参与 API 创新应用大赛,体验RDS CloudDBA数据库性能优化 API
阿里云的RDS数据库,有开发者所需要的一系列的功能,但很多功能很多开发者可能并没有使用过。这里,介绍一个RDS比较有用的功能:CloudDBA数据库性能优化 API。
12948 0
同步RDS数据库到自建mysql数据库
同步RDS数据库到自建mysql数据库
4410 0
如何搭建阿里云RDS PostgreSQL数据库的逻辑备库
适用于PostgreSQL数据库之间的逻辑增量同步。 对PostgreSQL的版本要求,8.3以上即可。 最小的同步单位为行,用户可以选择表为同步对象,并且可以对表进行分组(有事务关联的表作为一个分组)。
1456 0
从运维的角度分析使用阿里云数据库RDS的必要性--你不应该在阿里云上使用自建的MySQL/SQL Server/Oracle/PostgreSQL数据库
开宗明义,你不应该在阿里云上使用自建的MySQL or SQL Server数据库,对了,还有Oracle or PostgreSQL数据库。 云数据库 RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务。
4454 0
+关注
neo.wang
阿里云MVP
文章
问答
文章排行榜
最热
最新
相关电子书
更多
TcpRT:阿里云RDS智能诊断系统云上大规模部署自动化服务的客户实践经验
立即下载
袋鼠云基于阿里云RDS的数据库架构实践
立即下载
“移”步到位:一站式移动应用研发体系
立即下载