【本文转自云栖社区 作者neo.Wang】
在初创型互联网公司中，开发们整天想的唯一一件事，就是“把功能做出来”。而当公司业务量逐渐上涨、甚至翻了好几番之后，最开始的程序上的问题，就一个接一个地暴露了出来。
其中，最明显的，就是数据库的压力问题。下文提到的数据库，都指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 when、group 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性能问题？
转载注明：http://azwzsj.com/article/gcsjgh.html