sysbench --test=fileio --num-threads=16 --file-total-size=3G --file-test-mode=rndrw prepare
sysbench --test=fileio --num-threads=16 --file-total-size=3G --file-test-mode=rndrw run
sysbench --test=fileio --num-threads=16 --file-total-size=3G --file-test-mode=rndrw cleanup

3.OLTP测试
sysbench --test=oltp --mysql-table-engine=myisam --oltp-table-size=1000000 --mysql-socket=/tmp/mysql.sock --mysql-user=test --mysql-host=localhost --mysql-password=test prepare
通过这些测试之后差不过也能知道自己服务器的能力了， 如果发现服务器的性能不错， 但是依然不能满足用户的需求， 那么就只能是软件方面的问题了， 就需要定位到底是哪一块有问题
第二步， 观察mysql在某段时间的连接状态， 处理状态
如果硬件问题不大， 那么我们就需要观察mysql的状态了， 一般这个状态不是一时半会儿能搞定的， 都是需要写个脚本在后台记录mysql在某一个周期的压力值记录， 比如是一天， 一周为一个周期；
查看mysql的状态命令是show status;
这个命令返回好几百行的东西， 而我们只需要关注3行
1.Queries， 当前已经发生过的查询（可以用两个时间段的查询数量相减得到时间段内的查询数）
2.Threads_connected ，当前有多少个连接连上mysql
3. Threads_running， 当前有几个线程正在运行
通常是Threads_connected >= Threads_running, 因为连上mysql也不一定要工作， 可能阻塞， 挂起之类的
获取结果
1.我们写个脚本
每隔一秒去读取这三个数追加到mysql.status文件里面
2. 用ab工具模拟访问，用50个并发， 发送20000个请求（这个页面的每一次请求会多次访问mysql）， 这样就能使上面那个脚本得到结果了
ab -c 50 -n 2000 http://59.69.128.203/JudgeOnline/nyistoj/index.php/Problem/index
我们来查看这个mysql.status文件的内容
我们用上一行的第一个值减去下一行的第一个值就可以得到每一秒的访问mysql数量，差不多是1000+， 也可以看出基本上是有50个连接的， 平均用两个线程在处理请求；可以再次写一个脚本做一下处理
这样就得到每一秒的处理数量， 1000多一点儿， 貌似不咋好的感觉
结果分析
1. 访问mysql的频率很稳定（如下图）， 那就从mysql的其它部分优化， 比如表的结构， sql语句的优化， mysql的配置， 引擎的选择， 索引的优化等
2.mysql的访问频率呈周期性的变化（如下图）， 那么就是从峰值上优化；比如memcatch是否都是周期性失效， 那么就可以用随机方式让失效地更加均匀， 或者是让他在晚上3点左右失效， 这个时候的访问量不大， 到了第二天时memcatch的缓冲也基本上建立好了；或者是从业务角度优化， 比如12306的放票， 可以分省分时间段分批放票， 这样就避免了全国各地大家集体抢票带来的超高峰值； 也可以在高峰期的时候开启慢查询， processlist等工具分析到具体的sql语句；
三. 查看mysql进程的状态
如果需要知道mysql这个进程对处理sql语句的整体情况， 那么我们需要用到show processlist 这个工具，这个工具主要是能够记录下来每一条sql执行的过程；我们写一个脚本抓取status， 然后整体看看我们的mysql进程花的时间基本上都是在干什么；
show processlist\G