今天抽時間在整理一個關於MySQL和Oracle共同面臨的問題，但是它們有著不同的解決方案，就是經典的partial write問題，我也看到網上有很多DBA在糾結，在爭論，相比而言，Oracle這邊更沉默一些。我認真看了他們的討論，但是到目前為止沒有看到一個把兩方面都照顧到的解讀，而且這個問題可以繼續擴充套件開來，從儲存層面也可以有一些解讀，所以我決定做這個事情。至於文章最近應該會從社群中看到，對於內容，我還是抱著謹慎的態度，想讓幾位朋友審閱之後再說會比較好。如果你對此有一定的基礎，對此有濃厚的興趣，也可以私信聯絡我。

MySQL和Oracle有時候想想真是有意思，一個開源，一個商業，一個最流行，一個最有範，看起來勢不兩立，但是命運把他們又連線在一起。

早上走在路上，突然想起swingbench和sysbench這兩個工具。我竟然忍不住笑出來，都是Oracle員工寫的工具（確切的說，其中一個是前Oracle員工），竟然風格完全不同。sysbench在github上開源，從2016年開始持續發力，從sysbench作者的話說，他的很多需求都是CEO Peter建議他的，能不能做做這個，能不能實現那個，最後改進優化，終於做了較大的改進，直接到了1.0.3的版本，其實sysbench早期的路子和swingbench非常相似，也是一個站點，放置一個donate捐款的按鈕,而swingbench的情況相對要被動一些，因為你檢視FAQ就會看到，這是一個開源的軟體，如果出了問題，是不能提供支援的，用作者話說大體意思是，我也是一個全職工作者，有時候時間精力也會力不從心，見諒見諒。

如果你細細使用swingbench，會發現不少小問題，原本看起來完美的計劃結果發現會有很多不相容的問題。

比如swingbench在windows中支援精簡模式，文字模式和全圖形化模式,但是windows下的模板建立的資料和Linux是不相容的，也就是說，你通過oewizard字元介面建立了一批資料，想通過windows圖形介面做壓測，這個時候情況就比較尷尬，因為很可能會出現幾個錯誤，甚至是層出不窮的錯誤，直到你徹底放棄。

精簡模式的截圖如下，直接使用minibench即可。

文字模式在windows下非常便捷。直接charbench即可。

全圖形模式如下：

得到了這些圖，我們做壓測就有了可參考的標準了。

我開啟了150個使用者的壓測模式，很快我發現這個壓測的情況比我想象的壓力要大一些，150個使用者，竟然150個活躍會話。

STATUS CNT ---------------- ---------- ACTIVE 150 INACTIVE 27 ---------- sum 177

我做了如下的改動，說實話在這個配置下（網路配置，機器配置）我沒有看到顯著的效果，不過可以作為參考，在之前KDB的效能PK中還是能看到顯著效果的。

alter system set sga_target=15G; alter system set open_cursors=1500; alter system set session_cached_cursors=500 scope=spfile; alter system set commit_write='nowait'; alter system set audit_trail=none scope=spfile; alter system set filesystemio_options=setall scope=spfile;

至於redo，undo,temp的大小設定，這些都是基本的。

瓶頸主要在哪裡，很大一部分都是IO上不夠給力，下面是一個配置較好的伺服器，IO上採用PCIE-SSD,做了加壓測試，TPS翻了近30倍。

而CPU為什麼不是瓶頸呢，我們看看抓到的一個AWR報告，CPU基本都是空閒，跑不上去。

而IO為什麼是瓶頸呢，等待事件的平均等待時間是11毫秒，這個高了很多。

所以說通過這個大體能夠看出一些問題，做壓力測試就心中有數了。