你还在这样使用 MYSQL 吗?
在初创型互联网公司中,开发们整天想的唯一一件事,就是“把功能做出来”。而当公司业务量逐渐上涨、甚至翻了好几番之后,最开始的程序上的问题,就一个接一个地暴露了出来。其中,最明显的,就是数据库的压力问题。
下面列举一些常见的、会引发问题的用法。
下文提到的数据库,都指MYSQL。
1. 宽表
现象
开发在设计表结构的时候,很大程度上是在参考产品原型的设计。通常会把产品原型中,需要一起查询的条件、一起展示的字段,都放在同一张表中。而互联网公司的产品迭代又是非常快的,新功能层出不穷,开发没有时间重新梳理数据库结构,就盲目地在原来的表上增加冗余字段,为了使功能尽快开发完成。这就使得某些“老古董”的表,越来越宽,七八十个字段以上的大宽表越来越多。
建议
单个InnoDB表的字段数,建议少于50个;
大字段,例如:text、blob类型,考虑单独存放;
2. 列表的行数查询
现象
在后台或者部分前端的功能中,常常会出现类似MIS系统的列表查询功能。一般这种功能,都是按照选定的查询条件,先查出行数,再按照分页规则查询出第一页的数据。于是,就出现了这样的几种情况:(1)查询列表明细,是需要使用多表关联查询的。开发为了方便,直接把这个查询明细的“多表关联”的SQL拿过来,把select
后边的字段改成count(*)
,就直接作为查询行数的SQL,甚至连order by
都不去掉。而从业务上来说,查询行数的时候,只需要查询其中一张表就可以了;(2)代码逻辑的设计不合理,导致某些开发,直接套用“首页”逻辑,查询后续每一页的时候,都重新查询了一遍行数;
建议
增加SQL审核机制,不合规范的SQL不允许上线;
增加代码审核机制;
3. 查询不走索引
现象
很常见的情况是,某些表最开始的数据量很小,后来由于产品功能重心的调整,变成了大表。之前做好的程序、SQL、表结构却没有跟着调整。就出现了很多大表查询,没走索引,导致的慢查询。而慢查询堆积多了,整个数据库就瘫痪了,于是就出现了“次要业务拖累主要业务”的现象。
建议
根据查询场景,设置合理的索引,组合索引优先;
当组合索引和单字段索引同时存在时,建议删掉单字段索引,避免优化器做“无用功”;
4. 线上数据和线下数据没有隔离
现象
这里说的线上数据,指的是直接面对广大用户的数据;线下数据,是面向公司内部客服、运营的后台系统用到的数据。后台系统由于工作职责的不同,会有各种各样的查询需求,有的可能会很大、很复杂,比如导出一整个月、一整个季度的数据。会直接导致数据的压力非常大,进而影响了整个数据库实例,导致线上系统发生故障。
建议
线上数据的特点是:
访问量大;
每个用户只查自己的数据,可以命中索引;
查询条件简单;
返回条数少;
对响应时间要求极高;
对数据的时效性要求高;
线下数据的特点是:
访问量小;
后台同事会查询整个平台的数据,不容易命中索引;
查询条件复杂;
返回条数大;
对响应时间要求不高;
对数据的时效性要求不是特别高;
综上,两类数据从各个方面都是完全不同的。要把线上数据和线下数据隔离开来。更新时,统一更新线上数据;查询时,线上查线上,线下查线下。线上数据通过DTS等实时数据同步的方式更新到线下。
5. 过于依赖MYSQL,没有考虑其他的存储
现象
某些列表查询类场景,可能涉及到10~20个查询条件,而且检索数据量一般也很大。此时再使用MYSQL就比较吃力了,索引几乎无法覆盖。
建议
除了关系型数据库之外,我们有很多不同的数据存储的选择,比如:搜索引擎类、NOSQL类、时序类、缓存类,等等。应当根据不同的查询场景,选择最适合的数据存储方式。企图用MYSQL解决一切问题,是不明智的。
6. 没有站在数据库的角度去思考
现象
比如,子查询。开发站在人类的角度思考问题,就会出现形如:
这种子查询。而MYSQL在处理子查询的时候,是拿外层的每一条数据,去内层扫描,结果就是扫描了table1的行数 × table2的行数
次。
建议
避免使用子查询,改为通过索引做表关联等方式;
7. 直接在数据库中做计算
现象
部分开发会在SQL中写例如case when
、group by + count/sum
等的计算。MYSQL擅长的是,数据的查询与存储,并不擅长做计算——虽然它可以做。导致出现了很多慢SQL。MYSQL只对查询做了优化,并没有对计算做优化。
建议
group by + count/sum
可以考虑进行预计算;case when
可以在业务端或者前端进行;要有效利用每个工具最擅长做的事。
8. 在索引字段上用函数
现象
部分表在bigint类型的、存放时间戳的字段上做了索引,而查询的条件是精确到天的。某些开发就会把SQL写成:
这样。在索引字段上使用函数,索引就起不到作用,扫描数据的时候依然是全表扫描,并对每一行数据的create_timestamp做from_unixtime
运算。
建议
如:
这种场景,可以改为:
这样,只会计算一次,然后直接去匹配索引。避免了全表扫描。
9. 没有充分利用缓存
现象
部分对数据实时性要求不高的场景。会有相同条件的查询频繁执行的情况,甚至于并发执行多个相同查询条件的查询。这时候如果每次都查询数据库,势必造成了资源的浪费,甚至引起雪崩。
建议
把这部分查询结果,缓存到redis中。把大部分请求量引到redis去。
10. 单表数据量过大
现象
由于对MYSQL依赖严重,导致很多更适合存在NOSQL数据库的数据,也被存到了MYSQL中,而且行数非常多。这样的表,无论是查询、还是更新、或是DDL操作,都需要停服之后、花大量时间去做。
建议
单表不要超过1千万行,大小不要超过5G;如果超过,可以考虑分库分表;
根据场景,考虑用其他数据存储工具、或其他业务上的逻辑来解决大表的问题;
版权声明: 本文为 InfoQ 作者【无箭的丘比特】的原创文章。
原文链接:【http://xie.infoq.cn/article/cb4d416e77dbc78613bd3c42f】。文章转载请联系作者。
评论