契机

最近到了新的部门任职，开展工作的时候，由于对数据库相关的工作非常熟悉，因此切入点就选择了先从数据库开始，在短短2周的时间里，让线上DB的成本下降80%，并且业务稳定运行。这里把我的经验整理出来分享给大家，大家如果到了一家新环境也可以用类似的方法来做数据库相关的梳理和优化工作，在此次的整理中，我从下面几个部分来做梳理。

如何梳理

一、数据库实例梳理

数据库梳理部分，可以详细梳理各个环境的数据库的资源使用情况，包括数据库的规格，实例的数量等等，一般包含如下几个环境的梳理，有的公司环境会有多套，建议分类梳理：

DEV环境数据库梳理
QA环境数据库梳理
仿真环境数据库梳理
线上环境数据库梳理

通过这个数据库实例的梳理，你能够从宏观上了解线上数据库的部署情况，根据后面的梳理结果，可以评估数据使用是否合理以及哪些地方需要做改造和优化。

二、DB部署情况梳理

这部分主要是要了解线上数据的部署情况，一般包含如下几个方面：

数据库部署的路径（程序路径、数据目录、日志目录等）
数据库使用字符集
使用的引擎
数据库的版本
实例高可用
数据库的核心参数：

核心参数一般包含性能、数据一致性等相关参数，一般关注如下几个（下面参数仅仅适用于MySQL数据库）：

innodb_buffer_pool_size
innodb_flush_log_at_trx_commit
sync_binlog
binlog_format
character_set_server
character_set_database
max_connections

这里仅仅列出了少量比较重要的参数，大家可以根据自身的情况做参数的梳理。

三、DB运营情况梳理

这部分涉及的内容比较多，大致概括如下：

容量使用情况
QPS访问量
TPS访问量
慢查询
CPU使用量
活动线程数
备份方案
权限方案

通过这些信息可以看出一个实例的健康度以及实例资源使用是否合理。

四、DB相关需求调研

调研相关的需求，比如对高可用的需求、对数据一致性的需求、分库分表、数据回滚等需求，通过这些需求能知道现在线上的部署模式是否符合要求。

举个简单的例子，比如业务有数据强一致性的需求，而线上同步方式是异步，以及innodb_flush_log_at_trx_commit和sync_binlog参数并不是双1，那么这里就存在风险，需要做相应的改造。

思考和分析

在完成资料的收集以后，下一步就是根据自己的专业度进行分析和思考，下面列举几个思考的维度，大家在工作中可以经常这么去反问自己，然后思考出答案。

1、资源使用合理吗？

一般根据存储容量、QPS、TPS以及CPU的使用情况就可以很清楚的确认实例的运行状态，是过于空闲、负载适中还是高负载？然后根据具体的情况对数据库做实例缩容或者扩容。

2、数据库参数设置合理吗？

3、实例负载是否在正常范围？

4、实例的权限是否设置合理？

权限这部分比较好评估，是否存在业务权限过大的情况？root的权限是否有限定访问IP？这里一般的原则是：

业务权限一般只给select/insert/update三个权限就OK；
禁止针对账号做%的授权；
root用户只由DBA控制。

5、是否存在低版本，以及低版本是否需要升级？

线上一般需要保持版本的统一，特殊情况除外。

6、数据一致性需求能满足吗？

7、实例是否需要高可用？

8、慢查询是否正常？

9、索引设计是否合理？

索引这里一般根据慢查询来判断，还有一个维度，大家可以通过pt的pt-duplicate-key-checker工具来看线上是否存在重复的索引。

10、数据库的变更流程是否合理？

11、实例监控是否合理？

12、实例的备份策略是否合理？

上面列出了我自己常用的一些主要的维度，大家可以根据自身的情况酌情添加或者删除。

改造

根据上面的分析，就可以进一步对DB做优化，这里需要根据具体的情况来进行推进，就我们现在的DB存在的问题，我做了如下的优化：

1、实例降级和升级改造

仅仅这一步就为公司每个月节约成本20多万！但是需要注意：实例降级需要准确评估实例的负载情况，并对线上留有比较大的余量的情况下进行，把控好风险。

2、版本升级

3、监控告警优化

4、权限改造

5、SQL和索引优化

6、变更流程规范化

总结

做了前面的工作，你可以把前面你做的事情整理成一封非常好的邮件，你的优化成果、思考以及项目推进的详细过程，还有别忘记记录其中遇到的问题和经验教训。总结的时候可以用思维导图来展现，这一点非常重要，公司中不仅要积极主动干事情，也要积极主动的总结和回报，曾经自己因为只知道埋头干事情吃了不少亏，大家一定要谨记。

鹅厂资深DBA是怎么做数据梳理的？

契机