注：本篇是《高性能Mysql》第三版的讀書筆記
基準測試
基準測試即性能測試，是我們判斷系統的正確性&負載量的一個得力助手。
基準測試可以評估在項目未來的負載下，需要什麼硬件，需要多大容量的網絡，以及其他相關資源。總之壓測是必然的。
基準測試一共有兩個測試策略。
1.針對整個系統的整體測試。包括web mysql 網絡 等等、所有的因素加到一起。
2. 單獨測試Mysql 執行sql比較不同的scheme或查詢的性能。
測試的指標分爲吞吐量和響應時間。
吞吐量指的是單位時間內執行的事務數。叫做TPS
併發性。web服務器的併發性指的是在任意時間有多少同時發生的併發請求QPS。 數據庫的併發可能打開了上千個連接，但只執行了數十個查詢。併發性基準測試需要關注的是正在工作中的併發操作，或者是同時工作中的線程數。(MySQL中的連接池我理解爲線程池)
可擴展性，給系統增加一倍的資源就能獲得兩倍的吞吐量、TPS
性能測試我就用過jmeter 可以起多個線程進行併發測試。
服務器性能剖析
性能優化是在固定的資源下能幹更多的事情了，讓資源利用率提升了。
一般對於一個接口/服務性能的排查過程可以在不同階段打日誌，先定位到整個服務/接口的問題出在哪，對應的慢查詢進行優化！
可以使用navicat explain 創建查詢計劃對sql進行分析。
想使用mysql查變量配置的值的命令：show variables;
show profiles; 可以查看消耗時間，在配置的時候要保證set profiling = 1 這樣纔會展示消耗時間，navicat是帶這個的。每次執行完都會有剖析，那個就是。狀態是status
還可以使用show profile for query (query_id) 來獲取制定查詢的操作的耗時。
show status
返回一下計數器，既有服務器級別的全局計數器，也有基於某個連接的會話級別的計數器。
一個問題
在排查慢sql的時候我們可能就先執行 explain 使用查詢計劃，看一下有沒有使用索引，有的時候發現使用索引了，但是爲啥還是那麼慢，我之前就有遇到過這個問題，這個一定要先從服務器出發，查看一下服務器的資源被啥佔用了，有沒有死鎖或者競爭。
這個特別顯著的特點就是：重啓的mysql服務，剛開始執行查詢並沒有問題，過一會在執行就賊慢，不用猶豫，絕壁是服務器的問題導致的。
show PROCESSLIST 來觀察線程的狀態。
在排查的時候可以使用GDB作爲堆棧跟蹤，這個會阻塞住進程。當然gdb更適合調試那些你自己寫的或者沒有影響的進程，不然可能會造成問題，所以mysql服務器不太適合使用。但是gdb對其他東西的調試絕對是個很不錯的選擇。