这是昨天一台mysql库出现的问题，load比平时高了几倍，show processlist也有大量active的会话，数据库响应应用端请求较慢。

    查看innodb status row operations部份：

    因为mysql数据库服务器raid卡充放电，由write back模式变成write through，写IO性能下降，由于innodb内部采用共享线程的模式，写将innodb内部允许的最大并发线程数撑满，导致前端大量的select查询也无法进行，上图中看到有902个查询进入队列。

    与上图中的16 queries inside InnoDB刚好稳合。

    淘宝大多数应用场景都是读多写少，当时通过top看到iowait并不多，刚开始想到的一个解决办法：

      我们是否能也将innodb内部的线程进行分组，独立的写线程组，独立的读线程组?

    后来跟同事的讨论中，发现了更多的细节，当raid卡由write back模式，变成write though模式时，写已经将磁盘IO能力耗尽，把读线程独立出来，也不能解决这个问题，读也会很慢。请看下面的监控图示：

    磁盘利用率：

    在OS层面监控到的io响应时间：

    如果真要独立，那得把写线程控制在一个比较低的水平，分得越细，应对波动时，可共享的资源少了，也是一种坏处。对于底层存储系统，好像没有太大的必要这样做。

    但随着SSD，Fusion-io硬件的引入或使用，innodb io线程增加，innodb_thread_concurrency等参数的调整是一个必然。

    对于使用了raid卡的服务器，大家是怎么解决这个问题呢？