今天抽时间在整理一个关于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毫秒，这个高了很多。
所以说通过这个大体能够看出一些问题，做压力测试就心中有数了。