最近業主要求要把系統從電信云遷移到區里面的政數云，遷移前電信云是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,解決問題。
