背景
去年的微盟“删库跑路”导致公司市值蒸发10亿，前不久的网传某互联网公司实习生“删库”事件也上了头条，到最近的巴西一个数据库泄露近30T数据，影响2.2亿人，关于数据库安全的事件从未停止。
数据库作为业务的数据核心，其安全及性能是所有企业都必须面对的问题。当企业上云后，如何更加方便的监控云上数据库同样是非常重要的一件事情。
如何更加快速的发现删库事件？
如何揪出恶意的登录请求？
如何过滤性能需要优化的慢查询？
。。。
RDS审计中心发布后，让问题变得简单。
监控及告警
RDS审计中心内置最常见的一些告警规则（实际排查过程中可结合实际情况自行调整对应的参数及SQL查询语句），参考RDS安全，具体告警设定参考设置告警，用户可以聚焦于发现及解决问题本身。废话不多说，我们直接看看一些常见的场景。
RDS慢SQL
当我们配置RDS慢SQL检测后，如果一定时间范围内触发了告警，我们将通过配置的相应渠道接收到告警消息，比如邮件，
基于告警信息，我们直接通过RDS审计中心的审计性能中心查看慢SQL列表Top50，快速找出该异常时间段内的慢SQL语句，此处仅为测试样例。
实际上，对于使用MySQL类关系型数据库，读操作是最多的，而读操作里的慢SQL也是最常见的问题，优化的空间及必要性都排在首位，大体可以分为三类：索引优化、SQL语句优化以及表优化，实际上也是一个相互关联的持续优化过程。
索引优化也是最常见的场景，我们来看一个简单的例子，如下，很显然执行了全表扫描，where查询条件的列没有加索引。
我们加上索引后，查询效果提升是非常显著的
关于索引优化，遵循一些基本规则：
- 经常需要作为where查询条件的列，建议增加索引，多个查询条件可以增加复合索引
- 最左前缀匹配原则
- 选择区分度尽可能高的列建索引
- 索引的列不能参与函数计算
- 如果可能通过扩展已有索引进行优化，则优先扩展索引，然后才是新建索引
关于SQL语句的优化，基本原则：
- 查询尽量用具体字段，不用*
- 一般join性能优于子查询，对于多表join，尽量用小表 join 大表
- 常用查询可以考虑开启缓存
- 尤其是对于查询数据量非常大的情况，加上limit
关于表的优化，一般来说表的字段尽可能用NOT NULL，字段长度固定越有利于查询，对于大表则需要结合业务进行水平或垂直拆分
总体来说，优化步骤如下：
- 首先利用好explain这个神器
- 了解查询语句涉及到的表结构及相关索引信息
- 结合具体业务场景思考可能的优化点
- 验证优化后的执行效果
- 重复以上步骤
RDS登录失败异常
当我们配置RDS登录失败次数过多告警后，如果一定时间范围内触发了告警，我们将通过配置的相应渠道接收到告警消息，比如邮件
基于告警信息，我们直接通过RDS审计中心的审计安全中心查看登录失败的IP统计，快速找出该异常时间段内频繁尝试登录失败的IP地址。
进一步地，我们可以点击错误最多的客户端列表框右上角，如下图，查看分析详情，基于告警的触发时间往前选择对应的时间间隔，定位具体IP地址，从而进一步评估是否将对应IP加入黑名单处理。
RDS删除数据异常
当我们配置RDS大批量数据删除告警，同样在收到告警消息后，如下图，通过RDS审计中心的审计安全中心，找到大批量删除事件Top50列表框，也可以进一步查看分析详情，选择告警触发时间段，选择原始日志，查看更多审计信息，快速定位对应时间段的异常删除操作记录，及时告警，避免有意、无意的删除动作，最大限度的止损。
RDS执行错误异常
当我们配置RDS SQL执行错误数过多告警，同样在收到告警消息后，如下图，通过RDS审计中心的审计安全中心，找到错误最多的客户端列表框，查看分析详情，选择告警触发时间段，快速定位对应时间段的错误SQL操作记录，该样例错误为查询不存在的列名"uid"。
RDS危险SQL操作
当我们配置RDS危险的SQL执行告警后，同样在收到告警消息后，如下图，通过RDS审计中心的审计安全中心，快速定位对应时间段的危险SQL操作记录，
总结
本文基于一些常见案例，介绍了基于RDS审计中心如何快速定位云上数据库问题，并给出了一些处理的建议，也仅仅是作为参考，希望能够帮助用户贴合自己的实际业务场景，更省时、省力、准确定位并解决问题。
对我们工作感兴趣的，可以通过如下方式了解更多，谢谢关注！
- SLS首页：https://www.aliyun.com/product/sls
- 知乎：https://zhuanlan.zhihu.com/aliyunlog
- 微信公众号：日志服务 or LogAnalytics
- 哔哩哔哩：https://space.bilibili.com/630680534
