mysql 目前在使用中，就是代码通过mybatis 链接了数据库，然后购买了阿里云的RDS，然后就啥也没管了。随着数据表和数据量的增多，越来越需要注意数据库的性能问题。

之前数据库的配置是2核4G，所有的业务基本都是连的一个数据库，创建表的时候基本没有创建索引的习惯。就是一个能用就行的心态。目前我们是有547张表，整个数据库的大小大概是5G左右，

之前数据库的内存还好，正常运行一般也就40%的使用量，cpu使用率大概是60%，但是当遇到定时器执行的时候，cpu立马就飙升到了100%。

这其中cpu的问题，主要是代码业务也存在问题，比如可以不用去频繁查询数据库的，也去查询了数据库；再一个查询数据库的时候，有些sql语句，没有建索引，太多的关联查询，函数，导致查询慢，个人觉得一条查询的sql语句不应该超过1s,否则都可以定义为查询慢，看是否有优化的空间。

这次这么关注这个问题，也是最近使用了zipkin的问题，服务链路请求都会给这个服务发送请求，一是请求接口次数多，而是这个表再创建的时候，索引规划的不是很好，很冗余，占用了大量的数据库资源，导致仅有的2核cpu立马飙升到了100%，虽说没有导致业务完全崩溃，数据库还是能连接请求，但是明显还是感觉查询很慢【页面的查询】，所以不得不开始优化。

好在阿里云数据库rds的工具基本能分析出那些sql语句是慢查询，可以进行优化，我的优化方向主要是：

1.给表加索引。这个效果真的是显而易见的，看得见的查询快

2.大表数据删除。有些表达到千万级别的，就把几年前不用的数据直接删除了，这里有点偷懒了，最好当然是大表进行分表分库。

3.sql语句的优化，有些count字段没有索引的，count有索引的字段会快很多，sql语句中能不用函数sum这类的，不用也会快一点

对于数据库的维护，接下来可能关注：

1.读写分离，现在都是在一起

2.账号安全性，不能所有业务用一个账户，账户关联表权限问题

3.访问安全性，主要ip白名单限制

4.针对大表的分表

5.监控与报警：cpu,内存，连接数的报警阈值提醒配置

6.mysql的备份恢复机制，库表恢复，应急恢复

7.日志管理：特别关注错误日志和慢查询日志

8.参数配置，一般都是默认配置，个别时候可能需要对最大连接数等进行调整

9.会话管理，个人认为连接数是一个比较重要的指标，很多时候链接实际已经不起作用了，但还是占着连接数