1ã 首先登录DT，云数据库，通过bic子系统定位到生产上RDS的主实例ID，复制主实例的id到杜康上具体查看RDS的性能问题
2ã 杜康点击实例诊断，实例性能信息，筛选时间12-13 16:30-17:30 的性能信息
a)
磁盘空间、磁盘空间详情：这段时间的数据是一条直线，空间状态都很稳定，没有性能问题。
MySQL RDS磁盘占用包括日志文件（binlog文件、错误日志等），数据文件（数据、索引文件），和一些其他文件（ibdata，logfile_0,临时文件等）
造成 MySQL 实例空间使用率过高，主要有如下四种原因：
Binlog 文件占用高。
数据文件占用高。
临时文件占用高。
系统文件占用高。
对应解决方法：
1、定期删除binlog，假如当前dml造成大量的binlog，可以通过RDS控制台即使清理binlog
2、通过truncate或者drop及时清除不需要的表
3、终止对应的回话
4、ibdata中undo占用高可以进行undo分离，或者进行数据转移；增加redo log file的大小和组数
b)
IOPS：每秒读写的次数。现在是比较小的。在0-0.2之间。
如果IOPS比较高的话，有可能是以下原因：
1、实例内存满足不了缓存数据或排序等需要，导致产生大量的物理 IO。
2、查询执行效率低，扫描过多数据行。
解决方法：
1、查询是否有慢SQL，优化慢SQL，可以参考杜康的实例卡慢诊断的优化建议，或者登录DMS，通过诊断报告、优化来进行SQL优化
2、终止查询语句
3、通过show
processlist，或者DMS控制台、杜康等来kill查询回话id
c)
MySQL内存使用率：基本上是一条直线，没有变化。因为MySQL有innodb_buffer_pool，大约为物理内存的50%-80%，内存使用率高一些，相对的性能也会提高
d)
物理内存：直线保持基本无变化，物理内存就是实际的内存条的内存大小
e)
连接数：当前连接数在1500左右，后来增高至6000左右。但是活跃连接数一直在个位数，说明现在的空闲连接数过多。总连接数超过参考值2000。出现严重问题。
数据库的连接一般是使用长连接，可能是应用侧的连接池初始连接数设置过高，应用启动后建立多个到RDS的空闲连接
解决方法：
1、长连接建议启用连接池的复用连接功能。
2、对于交互式连接和非交互式连接，建议修改相应的wait_timeout和interactive_timeout参数。（空闲时间超过指定的时间后，RDS的连接会主动关闭）。通过DT，RDS控制台，性能优化，参数设置中修改。
3、kill当前的空闲会话。
f) 线程状态：线程数跟连接数是对应的。此时也是连接的总线程数远大于活跃的线程数。
g) 备库延迟：目前主备延迟(slave-lag)为0.
主备延迟产生的原因：
1ã 主库产生非常大的binlog
a)
主库上执行大量的dml语句
b)
主库上执行大事务
c)
主库上没有主键的全表扫描
2ã 主库上执行ddl语句，时间过长
3ã 备库上对myisam表长时间查询，阻塞主库的binlog同步语句
4ã 备库实例的规格配置低，磁盘IO比较低
查看方法:
1ã 首先查看备库的IOPS是否存在瓶颈
2ã 备库show
processlist查看是否存在大事务
3ã 主库的写入压力是否过高，dml语句是否过多
4ã 只读节点执行 show
slave status \G，判断是否有 Waiting for table metadata lock；同时在主库排查下是否有DDL 操作
5ã 只读节点执行 show
slave status \G，判断是否有 Waiting for table level lock; 同时通过 show full
processlist; 同时在主库检查下是否有长时间对 MyISAM 引擎表的查询
h) QPS/TPS：QPS比较高，在90000左右，最高到达110000
。每秒的事务数在10000以上。正常，业务量比较高
原因分析：
QPS比较高，每秒SQL的语句执行次数高，业务量上来，处于业务的高峰期，用户连接数增加，访问量增加。
如果QPS比较高，逻辑读不高，慢SQL也不是系统的瓶颈，QPS和cpu使用率的变化曲线吻合，这时候优化的余地就不高了，可以从实例规格、应用架构方面进行考虑。
如果QPS不高，查询执行效率低、执行时需要扫描大量表中数据、优化余地大，并且出现慢查询问题，QPS和CPU的变化曲线不吻合
如果QPS比较高，并且逻辑读也比较高，CPU的使用率增加，这时候可以优化优化相应的慢SQL，添加主实例的只读实例来缓解压力。
I ) cpu/mem的使用率：现在cpu的使用率在30%左右，不算高。内存的使用率基本平稳在30%左右，正常
CPU的使用率高的原因：
系统执行应用提交查询（包括数据修改操作）时需要大量的逻 辑读，（逻辑 IO，执行查询所需访问的表的数据行数），需要消耗大量的 CPU 资源以维护从存储系统读取到内存中的数据一致性。造成逻辑读高的原因，很可能是异常SQL，扫描的数据行数过多导致。
j) 慢SQL：慢SQL数量的变化曲线跟CPU的使用率的变化曲线吻合，在CPU使用率高的时候，慢SQL也跟着增加。可以通过杜康对产生的慢SQL进行优化。
K) 全表扫描次数：随着业务量的增加，全表扫描的次数也随之增加。Sql要尽量避免全表扫描
主实例问题与建议：
QPS升高，业务量高的情况下，产生一些慢查询SQL，并且空闲连接数太多
  1ã 连接数：连接数严重超过参考值，并且有过多的空闲线程。首先检查应用是否使用连接池，如果使用连接池，检查连接池的配置是否合理
  2ã 优化慢SQL
a)
select id , inst_id , code , name_cn , aic_register_name ,
postcode , administrative_division , province_code , city_code , status ,
business_unit , org_level , org_category , manage_level , parent_org_code ,
distribution_org_flag , legal_entity_flag , address , approve_create_date ,
source_org_create_date , major , org_phase , main_category , detail_category ,
business_function , core , corporation_flag , department_flag , company_code ,
company_name , common_service , branch_emp_relationship , branch_urban_type ,
branch_func_type , branch_invest_type , create_date , modify_date ,
create_user_id , gmt_created , modify_user_id , gmt_modified , is_deleted from
bic_base_org
优化建议：此类SQL没有where条件，一定要添加where条件并且有合适的索引。这样会造成全表扫描影响系统性能。如果一定要执行建议在业务低峰期执行
b)
select count ( *
) as cnt from ( select id , jdpt_employee_code , td_employee_code ,
td_employee_name , td_org_code , td_org_name , td_phone_number , td_id_number ,
td_employee_status , td_employee_role , create_user_id , gmt_created ,
modify_user_id , gmt_modified , is_deleted from bic_td_jdpt_employee_relation
where :1 = :2 and is_deleted = :3 )
优化建议：此类SQL扫描行与发送行的比666184，并且查询使用了聚合函数，没有使用where条件。影响服务器性能，SQL锁行过多，可能影响其他更新语句。关联列上添加索引，子查询返回的行数尽量少
个人总结：
针对RDS的问题：CPU占有率持续高、QPS持续高、逻辑读一直高，用户连接线程增加，活跃线程数增加。
一般情况下：有慢SQL的情况，首先优化慢SQL，针对慢SQL主要注意查询多少数据和返回多少数据，如果查询的数据跟反回的数据都比较大，而且执行时间秒级别特别长，很有可能是慢SQL；没有慢SQL，或者慢SQL不是性能主导原因的话，可以考虑实例的规格配置和实例的架构，比如增加主实例的规格配置，增加只读实例缓解主实例的压力等。