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 ，當前有多少個連線連上mysql3. 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 這裡的Status狀態可能情況比較多， 不過我們主要是關注如下幾個狀態：