最近业主要求要把系统从电信云迁移到区里面的政数云，迁移前电信云是8核16G的配置，迁移后政数云是32核32G的配置，按理说迁移后性能应该非常好，结果老是系统崩溃，查找原因是MySQL占用CPU过高，占用率达到了1800%。于是进行了一系列的问题排查解决。
1、因要快速解决问题，不能影响客户使用，第一想到是存储可能是因为存到外挂的数据盘上，数据盘不是固态的，性能不足，于是把存储及mysql关联的全部改成系统盘。事后观察还是CPU过高。
2、于是优化SQL,把常用业务功能里面的SQL拉出来排查，发现之前的这条SQL大概1秒能出来，现在4-10秒才出来，于是EXPLAIN查看具体情况，其中查到定位到一个子查询是慢的原因，大概是如下这样
select e,count(e) from t where a=xx and b=xx and c=xx and d=xx group by e
对a、b、c、d建了联合索引，e是主键索引
explain后
Using temporary表示由于排序没有走索引，于是加了order by null,再看还是Using temporary，分析using index condition应该是走的联合索引，那Using temporary应该是后面group by引起的，那就是e字段有问题，e字段是主键，也没有走主键索引。于是把联合索引修改成a、b、c、d、e,再次explain后
查询速度立马到了1秒。但后面还是CPU过高。于是考虑mysql配置。
3、修改MYSQL配置如下
innodb_buffer_pool_size = 8000M
innodb_buffer_pool_chunk_size= 8000M
innodb_buffer_pool_instances=8
tmp_table_size = 1024M
max_heap_table_size = 1024M
wait_timeout = 90
interactive_timeout = 90
max_connections = 500
观察高峰期后，还是CPU过高，导致系统崩溃。
4、查看读写系统性能
安装iotop和IOStat的检测工具包：
#yum -y install sysstat
#yum -y install iotop
对比迁移前后对比，发现kb_read差距挺大。
对比后发现读写能力不足，于是查看云空间回执表，如下：
分布式存储按理解应该没有多大问题，也没有表示怀疑。于是带着疑问问供应商，为啥现有的系统性能不如以前，发现给我们的磁盘存储是分布式存储，但同是也是共享存储，意思是这个区域所有的政务系统都是共用这块存储，可能涉及查询业务比较多，所以读的能力差，而写的能力还可以。因为此系统用户比较大，而且调优慢SQL耗时较大，也是个巨大的工程，于是提出改变，改用FC-SAN,解决问题。
