mysql
阿里云RDS MySQL迁移到同地域同规格的RDS MySQL之后，性能明显不如迁移前的性能。最开始业务只是用户侧感觉系统卡顿，但服务器方面性能没有任何异常，故把问题指向数据库。以下是对这个问题的分析及处理。
排查步骤查看内存、CPU使用情况
发现cpu使用率极高，经常出现”尖刺“
排查慢SQL
对业务sql进行分析，使用explain 查看sql执行计划
code1
可以看到 key这一列是空，但是从理论上这个值不应该为null,因为该表的ID列存在一个索引
使用show index from tablename 查看这张表索引情况
code2
可以发现索引的Cardinality值为0，这代表这这个索引是无效的。也就是说执行器在执行的时候不会使用这个索引。这个值越趋近1代表选择性越高，那么在执行语句时，使用该索引的可能性将变高。
使用 analyze 重新计算该值
code3
不确定库中还有其他表统计信息缺失，使用以下语句查询缺少统计信息的表,，然后再统一执行 analyze
code4
更新统计信息后，业务sql恢复正常。使用analyze不会同步到备库，故需要重搭备库。造成该现象原因：在进行dts操作过程中，源库进行了HA切换，导致某些表的统计信息还未进行持久化，姑迁到新库的索引统计信息为0，进而导致业务sql不走索引，最后导致cpu增高。
CPU使用率还是比较高，时常出现“尖刺”
查看业务中的慢sql对慢sql进行分析
code5
同时查看一下实例的cpu及物理读写（和内存相关），若读写较高，则调整 innodb_buffer_pool_size 参数，建议为内存的3/4
cpu依旧偶尔存在“尖刺”
查看表碎片率
code6
若业务表碎片率较高的话，则使用optimize table 优化一下表
-----------------------------------------------
欢迎各位伙伴在评论、留言指出不足之处。
联系方式：mr_xuansu@163.com
更多内容请关注微信公众号：萱蘓的运维日常
