在Visual Studio 2010中有一個內置的選項允許開發者通過一個快速的右擊操作生成
單元測試。但是Visual Studio 2012和Visual Studio 2013預覽版都移除了這個功能，幸運的是現在它又回來了。Visual Studio ALM Rangers創建了一個新的擴展，該擴展恢復了Unit Test Generator 1.0版本中的大量功能。
團隊很快就注意到這并不是復活，而是由之前的工具所激發的替代品。該項目的目標是：
支持.NET MS-Test、NUnit和XUnit測試框架以及VB/C#測試代碼的生成
為某個特定的測試框架提供一個“參考實現”，告訴用戶該如何去做
關注項目和引用管理而不是代碼生成
通過對三種不同的測試框架(MS-Test、NUnit和XUnit)的支持，開發者能夠使用最適合于他們項目的框架。開發者還能夠通過這個工具定制要生成的項目，包括命名空間的名字、類、方法和方法體的文本。
如果使用默認設置那么會生成一個默認的類，該類中的測試方法通過Assert.Fail()設置為失敗，以便開發者能夠發現它們并使用有效的測試代碼替代默認生成的內容。
注意，按照設計生成器僅會為公共類中的公共方法生成方法存根。它并不會為私有類生成任何內容，也不會生成私有方法。借助于該工具對Visual Studio 2012/2013的支持以及項目周圍的便捷方法，團隊現在合并該工具并做好升級準備應該沒有任何困難。
Channel 9已經提供了一個簡要的說明，與此同時ALM Rangers之前也基于發布的候選版發布了一篇博客
文章作為教程。
說明：SCN（System Change Number 簡稱 SCN）是當
Oracle數據庫更新后，由DBMS自動維護去累積遞增的一個數字，可以理解成ORACLE數據庫的時間戳，從ORACLE 10G開始，提供了函數可以實現SCN和時間進行相互轉換；
用途：在進行數據庫的還原和利用數據庫的閃回功能時，進行SCN和時間的轉換就變的非常必要了；
操作方法：
1、通過dbms_flashback.get_system_change_number獲得系統當前的SCN值：
SQL> select dbms_flashback.get_system_change_number scn from dual;
SCN
-----------------
122037263
2、通過scn_to_timestamp函數可以將SCN轉換為時間戳:SQL> select scn_to_timestamp(122037263) scn from dual;
SCN
---------------------------------------------------------------------------
14-7月 -14 04.45.36.000000000 下午
3、還可以通過timestamp_to_scn可以將時間戳轉換為SCN:
SQL> select timestamp_to_scn(to_date('2014-07-13,13:25:59','yyyy-mm-dd,hh24:mi:ss')) scn from dual;
SCN
---------------------
121936647
對于一個剛開始
學習數據庫優化的新手DBA來說，當用戶反饋系統比較慢時，他會非常緊張，面對數據庫，他無從下手，不知道從哪里開始著手來優化數據庫，查找系統
存在的問題。
今天我們通過
操作系統命令TOP，來優化數據，我們如何把操作系統與數據庫關聯起來哪，我們主要是通過操作系統TOP命令找到最消耗資源OS PID進程。
通過OS PID與V$PROCESS動態性能試圖進行管理。我們知道V$PROCESS是被認為從操作系統到數據庫的入口，而進入數據庫內部，進程需要創建回話（SESSION）執行數據庫操作的
SQL語句，一般情況下，一個進程只會創建一個回話，但是在特殊的情況下，一個進程也可以創建多個數據庫回話。回話的信息是通過動態性能試圖V$SESSION來進行管理和體現的。
那么我們通過一個實驗來看一下，如何完成從操作系統命令到數據庫內部的操作，我們模擬一個出現故障的場景，我們通過操作系統命令TOP，進行觀察，找到操作系統進程占CPU資源比較高的進程。
1.首先我們建立一個測試表t1,向表中插入一些數據。 SQL>create table t1 as select * from emp;
SQL>insert into t1 as select * from t1;
SQL>/
SQL>/
SQL>/
SQL>/
使表T1大約有幾萬條記錄。
2.開3，4個會話,其中表t1有幾萬行的數據，同時運行，立刻查詢上面的語句
declare v1 emp.sal%type; begin for n in 1..100 loop for k in 1..100 loop select count(*) into v1 from t1; end loop; dbms_lock.sleep(1); end loop; end; / |
3.通過操作系統命令TOP找到消耗CPU資源的進程
top - 12:57:42 up 19 min, 2 users, load average: 1.18, 0.35, 0.23 Tasks: 132 total, 2 running, 130 sleeping, 0 stopped, 0 zombie Cpu(s): 20.5%us, 5.9%sy, 0.0%ni, 73.1%id, 0.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1034664k total, 883716k used, 150948k free, 125584k buffers Swap: 4120664k total, 0k used, 4120664k free, 609440k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5182 oracle 19 0 368m 50m 48m S 37.9 5.0 0:03.57 oracle 1 root 15 0 2160 652 564 S 0.0 0.1 0:02.30 init 2 root RT -5 0 0 0 S 0.0 0.0 0:00.05 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 4 root RT -5 0 0 0 S 0.0 0.0 0:00.04 migration/1 5 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1 6 root 10 -5 0 0 0 S 0.0 0.0 0:00.04 events/0 7 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/1 8 root 11 -5 0 0 0 S 0.0 0.0 0:00.01 khelper 9 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread 13 root 10 -5 0 0 0 S 0.0 0.0 0:00.10 kblockd/0 14 root 10 -5 0 0 0 S 0.0 0.0 0:00.02 kblockd/1 15 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid 179 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0 180 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/1 183 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 khubd 185 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod 252 root 18 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd 253 root 17 0 0 0 0 S 0.0 0.0 0:00.00 pdflush 254 root 15 0 0 0 0 S 0.0 0.0 0:00.03 pdflush |
4.我們看到進程PID等于5182，我們下面的一個腳本，關聯V$PROCESS試圖和V$SESSION試圖、V$SQLTEST試圖，可以找出這個進程正在執行的SQL語句，這里只需要一個“發動”條件，就是進程（PID）:
SQL>SELECT /*+ ORDERED */ sql_text FROM v$sqltext a WHERE (a.hash_value, a.address) IN (SELECT DECODE(sql_hash_value, 0, prev_hash_value, sql_hash_value), DECODE(sql_hash_value, 0, prev_sql_addr, sql_address) FROM v$session b WHERE b.paddr = (SELECT addr FROM v$process c WHERE c.spid = '&pid')) ORDER BY piece ASC; / |
提示輸入變量值。
Enter value for pid: 5182 old 9: (SELECT addr FROM v$process c WHERE c.spid = '&pid')) new 9: (SELECT addr FROM v$process c WHERE c.spid = '5182')) SQL_TEXT ---------------------------------------------------------------- declare v1 number; begin for n in 1..100 loop for k in 1..100 l oop select count(*) into v1 from t1; end loop; dbms_lock.sleep(1 ); end loop; end; |
注：這里我們使用了3個動態性能試圖，獲取到了執行的SQL語句。我們的邏輯是：
1）首先輸入一個PID，這個PID即是process id,也就是在TOP命令中看到的PID.
2）通過PID和v$process.spid相關，我們可以獲得process的詳細信息。
3）通過v$process.addr和v$session.paddr相關聯，可以獲取session的相關詳細信息。
4）再結合v$sqltest，即可獲得當前session正在執行的SQL語句。
總結：
1.首先我們通過操作系統命令TOP找到了PID.
2.我們結合3個試圖，就找打了當前正在瘋狂消耗CPU的罪魁禍首，那么下面的工作就是如何優化這個SQL，我們可以進一步通過
dbms_system包跟蹤改進程，或者通過AWR獲取該SQL的執行計劃。來改變SQL的執行計劃，達到優化的目的。
一般初學JavaScript的時候最頭痛的就是瀏覽器兼容問題。在Firefox下面好好的代碼放到IE就不能顯示了，又或者是在IE能正常顯示的代碼在firefox又報錯了。
如果你正初學JavaScript并有著一樣的處境的話建議你：初學JavaScript的時候無視DOM和BOM的兼容性，將更多的時間花在 了解語言本身（ECMAScript）。只在特定瀏覽器編寫代碼（Chrome/Firefox/Safari），實際
工作中使用成熟的 JavaScript框架（jQuery等）。放心，很少有公司會讓JS新手用原生JS做前端開發。
學習JS初期無視兼容問題有什么好處
2、減少挫敗感
3、花更多的時間學習ECMAScript
什么時候學習JS跨瀏覽器開發知識？而瀏覽器兼容問題留到什么時候解決呢？
當你能熟練使用JavaScript框架編寫可復用的代碼時（jQuery插件或前端控件），或當你準備自己開發一個JavaScript框架時。
其他一些JavaScript初學者建議
千萬不要拿JavaScript權威指南當入門書籍
應該用JavaScript高級程序設計（第三版）作為入門書籍
傳值和傳值、作用域知識必須理解
調試工具必須懂并多用，學會自己捕捉錯誤。（chrome developer tool/Firebug）
耐心再耐心，對每一個知識點深挖能學的更輕松。
以上就是一些分享希望若能幫助到初學JavaScript的你，如果覺得有誤導的地方敬請立即指出。
管理 VLAN 簡介：
S2100系列以太網交換機任何時刻只能有一個VLAN對應的VLAN接口可以配置IP地址，
該 VLAN 即為管理 VLAN。
如果要對以太網交換機進行遠程管理，必須配置交換機管理 VLAN接口的 IP地址。
當然，管理vlan可以是任何一個vlan。
如以下：創建管理 VLAN 20接口。
<H3C>system-view
Enter system view
, return to user view with Ctrl+Z.
[H3C]vlan 20
[H3C-Vlan20]quit
[H3C]management-vlan 20
[H3C]interface vlan-interface 20
管理 VLAN 20指定靜態 IP地址和掩碼。
#創建 VLAN 20,并將其指定為管理 VLAN，創建管理 VLAN 20的接口。
<H3C>system-view
Enter system view, return to user view with Ctrl+Z.
[H3C]vlan 20
[H3C-Vlan20]quit
[H3C]management-vlan 20
[H3C]interface vlan-interface 20
#為管理 VLAN 20接口指定 IP地址和掩碼。
[H3C-Vlan-interface20]ip address 192.168.0.55 255.255.255.0
最后需要配置默認網關，不然遠程無法訪問交換機。
進入系統視圖
system-view
進入管理VLAN接口視圖
interface vlan-interface 20
配置管理VLAN接口網關
ip gateway 192.168.0.1
既然是征伐，一味蠻干，只懂得身先士卒，是不夠的。
謀定而后動，還是有一定道理的。今日姑且小議一句話。“兵者詭道也”。
情景一：
為了項目進度，需要晚上加班測試。
如果你是個leader此時極有可能聽到team中各種聲音。
“怎么會加班呢？啥時候能回家啊？”
“今天能搞定嘛？不會通宵吧”
“這要搞到啥時候？我還有事呢”
……
分析：
誠然這些聲音多少包含消極的因素，然卻無可厚非。
正如我一貫主張，勞逸結合是最好的，但特殊情況是無可避免的。
現象：
我看到過一些領導，批評下屬“你們的夢想呢……”
也看到一些主管空喊口號“加油啊”
自然也看到過一些leader，身先士卒，但是只顧埋頭苦干。
點評：
第一種，大言不慚。
有什么理由批評人，本來就是加班的事情。
人都會疲憊都需要休息。
批評只會讓結果惡化。最多是口服心不服。
第二種，華而不實。
空喊口號久了，只能被冠上無能的稱號。
也會讓人鄙視leader，喊口號誰不會呢？
第三種，匹夫之勇。
一味埋頭苦干，人們礙于面子或許會跟著做。
然而消極情緒不能消除。
事倍功半。何況這又何嘗不是一種精神上的壓迫呢？
對策：
一言以蔽之“遠而示之近”和望梅止渴的典故有異曲同工之妙。
人因未知而恐懼，因恐而迷茫。此時重點是要激發斗志。
“明確告訴大家，我們九點就能下班，就能搞定。
希望就在眼前，馬上大家就能回家各種happy”
與此同時，和組內的同學一起做一點。
哪怕只是一點，也勝過自己埋半天。
即便你最后搞到了九點半，那多出來的半小時也是斗志昂揚的。
更何況積極狀態下2小時，能完成消極狀態下3小時的
工作。
注意：此方法，不可在短期內連續多次使用。最好還是規律作息。
注意：前提是自己對實際的任務量有較為清晰的把控。
情景二：
在績效考核，或職業等級評估晉升前期（一個月左右）
一些同學覺得自己已經完成績效計劃中的任務，所以工作懈怠。
一些同學覺得技術已經達到考核標準，不再虛心積累。 分析：
懼滿盈，則思江海下百川。
可是很多工作時間不太長的同學還沒有完全領悟這個道理。
績效的目標只是定在完成，考核的目標只是定在通過。
其實這需要leader引導的，也是人才培養的一部分。
現象：
見過一些leader也隨著大家一起松懈。
見過一些領導在那空放厥詞，大講是非論。
點評：
第一種，我只想建議一句話：先天下之憂而憂，后天下之樂而樂。
第二種，從來只是內因其變化
不能激發主觀能動性，只能徒增逆反心理。
對策：
一言以蔽之：“近而示之遠”
不用解釋要有啥更高的追求。
只找他一起回顧下半年前的績效目標，
績效這東西就像海綿擠擠總會有空隙。
只需要讓他知其實還沒有達到目標（盡管他已經無限接近）
做一次模擬等級評定。
他一來會感激你的關懷，二來你借此問一些偏冷門的問題。
總有不會的，目的就是讓他知道，他和自己心中的目標還有距離。
人之所以自滿是因為覺得自己距離目標已經無限接近。
我們與其費力改變目標，不如制造距離感。
一、軟件問題的定義與分類
1． 軟件問題的分類
軟件錯誤（software error）
軟件缺陷（software defect）
軟件故障（software faut）
軟件失效（software faiure）
定義：
（1）軟件錯誤：指在軟件生存周期內的不希望或不可接受的人為錯誤，其結果將導致軟件缺陷的產生。
關注點：屬于人為錯誤
（2）軟件缺陷：存在于軟件（程序、數據、文檔）之中的那些不希望或不可接受的偏差。
關注點：欠缺或不完備的地方
一般情況下，滿足以下五種情況中的一種，即可存在軟件缺陷。
① 軟件未達到產品說明書中標明的功能。
② 軟件出現了產品說明書中指明的不會出現的錯誤。
③ 軟件功能超出了產品說明書指明的范圍。
④ 軟件未達到產品說明書雖未指出但應達到的目標。
⑤
軟件測試人員認為軟件難以理解、不易使用、運行速度慢，和最終用戶認為不好使用。
（3）軟件故障：指在軟件運行過程中出現的不希望或不可接受的內部狀態，若此時無適當的措施（容錯或異常處理機制）加以及時處理，便產生軟件失效。
關注點：內部狀態
（4）軟件失效：指在軟件運行時產生的一種不希望或不可接受的外部行為結果。
關注點：外部行為結果
2． 軟件失效機理
軟件錯誤——>軟件缺陷——>軟件故障——>軟件失效
軟件錯誤是一種人為的錯誤，一個軟件錯誤必定產生一個或多個軟件缺陷
當一個軟件缺陷被激活時，便產生一個軟件故障。
同一個軟件缺陷在不同的條件下被激活，可能產生不同的軟件故障。
軟件故障若沒被及時的使用容錯加以處理，便不可避免的導致軟件失效。
同一個軟件故障在不同條件下可能產生不同的軟件失效。
3． 產生軟件錯誤、缺陷的原因
主要原因是開發的軟件與需求說明書、軟件設計說明書的不一致，以及在軟件的實現中，未能達到用戶潛在用戶需求的目標。
二、軟件錯誤的跟蹤與管理
1．缺陷與錯誤嚴重與優先級
（1） 嚴重級別
嚴重：系統崩潰、數據丟失、數據破壞。
較嚴重：操作性錯誤、錯誤結果、遺漏功能。
一般：小問題、錯別字。
建議：不影響使用的瑕疵或更好的實現。
（2） 優先級
最高優先級：立即修復，停止進一步測試。
次高優先級：在產品發布之前必須修復。
中等優先級：在產品發布之前應該修復。
最低等優先級：可能會修復，但是也能發布。
2．軟件錯誤的跟蹤管理
（1）錯誤（bug）信息的描述
①Bug記錄信息
測試軟件名稱
測試版本號
測試人名稱
測試事件
測試軟件和硬件配置環境
發現軟件錯誤的類型
錯誤的嚴重等級
詳細步驟
必要的附圖
測試注釋
②Bug的處理信息
處理者姓名
處理時間
處理步驟
錯誤記錄的當前狀態
3.軟件錯誤狀態的描述
① 新信息（New）：測試中新報告的軟件錯誤（Bug）。
② 打開（Open）：錯誤已經被確認并已經分配給相關開發人員處理。
③ 修正（Fixed）：錯誤已經由開發人員修正完成，等待測試人員驗證。
④ 拒絕（Decined）：高級測試人員或開發人員認為不是錯誤，拒絕修改Bug。
⑤ 延期（Deferred）：此錯誤不在當前版本中修復，而要到下一版本中修復。
⑥ 關閉（Cosed）：錯誤已經修復，并已經過驗證。
4.錯誤管理流程
步驟：
第一步：測試人員提交新的錯誤信息，并輸入到錯誤跟蹤管理系統錯誤信息數據庫中（如TD），錯誤狀態置為初始狀態“New”。
第二步：高級測試人員驗證錯誤并做相應處理。
① 如果確認是錯誤，分配給相應的開發人員，把錯誤狀態置為“Open”。
② 如果高級測試人員認為這個“New”狀態的“錯誤”不是錯誤，則拒絕修改，把錯誤狀態設置為“Decined”。
第三步：開發人員查詢狀態為“Open”的所有錯誤，并對錯誤做如下處理：
① 如果開發人員認為這個“Open”狀態的錯誤不是錯誤，則拒絕修改，把錯誤狀態設置為“Decined”。
② 如果是錯誤，則修復并把錯誤狀態設置為“Fixed”。
③ 如果是不能解決的錯誤，要留下文字說明并保持錯誤狀態為“Open”。
④ 如果需要延期解決的錯誤，要留下文字說明，把錯誤狀態設置為“Deferred”。
注意：對于不能解決的和延期解決的錯誤，不能由開發人員自己決定，一般需要某種會議（評審會）通過才能認可。
第四步：測試人員查詢狀態為“Fixed”的所有錯誤，驗證這些錯誤是否已經解決，并做如下處理：
① 如問題解決了，把錯誤狀態設置為“Cosed”。
② 如問題還沒解決，重新把錯誤狀態設置為“Open”。
5.錯誤流程管理原則
①為了保證錯誤處理的正確性，需要有測試經驗豐富的測試人員驗證發現的錯誤是否是真正的錯誤，書寫的測試步驟是否準確，可以重復。
②每次對錯誤的處理都要保留處理信息，包括處理姓名、時間、處理方法、處理意見、Bug狀態等。
③拒絕或延期處理錯誤不能由程序員單方面決定，應由項目經理、測試經理和設計經理共同決定。
④錯誤修復后必須由報告錯誤的測試人員驗證，確認已經修復后，才能關閉錯誤。
⑤加強測試人員與程序員之間的交流，對于“Deferred”狀態的錯誤，需要互相交流意見，避免真正的錯誤被遺漏。對于某些不能重復的錯誤，可以請測試人員補充詳細的測試步驟和方法，以及必要的測試用例。
因為要在命令行下運行一些
android的工具，所以配置一些環境變量會比較方便：
遇到問題：
java -jar re-sign.jar 出現提示android路徑沒有配置好：
需要配置如下：
配置ANDROID_HOME為android sdk的安卓目錄，例如：D:\android-sdk
在path下添加這兩個：
%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools;
重新開關一次命令窗口
因為
robotium要求被測應用和測試代碼要有一致的key,所以我們需要把下載到的apk，通過re-sign.jar來產生debug key的apk，這個重新生成的apk就會跟測試項目簽名一致了
re-sign.jar可以從這里下載到：
http://www.troido.de/re-sign.jar
下載完后，在命令行下 通過 java -jar re-sign.jar就會出現一個節目，然后將apk拖到這個節目，就會自動生成一個debug key的apk
產生新apk的過程中會彈出一個信息框，記得截下圖，因為里面有兩個信息我們等會的代碼中需要用到
然后打開模擬器（模擬器器一定要打開才能安裝成功），然后打開命令行
adb install mitalk_debug.apk(新生成apk的名稱)
安裝成功就可以再模擬器里看到該應用的圖標了
注意：
一、刪除之前 APK 文件的簽名
1、解壓apk 文件
2、刪除解壓出來文件夾中的 META-INF 目錄：META-INF 存放簽名后的CERT 和MANIFEST 文件，用于識別軟件的
簽名及版權。
3、刪除文件夾后重新把解壓出來的其它文件夾壓縮為zip 文件，然后直接把文件后綴改為apk
二、為 APK 重新生成簽名
1、將證書復制到與需要重新簽名的apk 文件相同的目錄下
2、jarsigner -keystore debug.keystore -storepass android -keypass android D:\Robotium\robotium\robotium\weixin_delet_rsa_sf.apk androiddebugkey
打開Eclipse，點擊File->New一個Android
Test Project,然后點擊下一步的時候選擇This project(因為我們沒有米聊應用的源碼)，然后選擇要在哪個android版本上測試
在該項目下創建一個包，com.tencent.test,在該包下創建LoginTest類，如下
package com.mitalk.test; import android.app.Activity; import android.test.ActivityInstrumentationTestCase2; import com.jayway.android.robotium.solo.Solo; @SuppressWarnings("rawtypes") public class LoginTest extends ActivityInstrumentationTestCase2 { public Solo solo; public Activity activity; private static Class<?> launchActivityClass; // 對應re-sign.jar生成出來的信息框里的兩個值 private static String mainActiviy = "com.tencent.mm.ui.LauncherUI"; private static String packageName = "com.tencent.mm"; static { try { launchActivityClass = Class.forName(mainActiviy); } catch (ClassNotFoundException e) { throw new RuntimeException(e); } } @SuppressWarnings("unchecked") public LoginTest() { super(packageName, launchActivityClass); } @Override protected void setUp() throws Exception { super.setUp(); this.activity = this.getActivity(); // this.solo = new Solo(getInstrumentation(), getActivity()); } public void testLoginWithIncorrentUsernameAndPassword() throws Exception { wait(5000); //待完成 } @Override public void tearDown() throws Exception { try { this.solo.finishOpenedActivities(); } catch (Throwable e) { e.printStackTrace(); } this.activity.finish(); super.tearDown(); } } |
每個
學習軟件開發的初級階段都是從會寫購物車開始的，同理購物車
測試用例的全局性和覆蓋度也是檢測每個測試工程師的標桿。
請根據如下功能圖設計 1. 加入購物車 2. 查看購物車 的測試用例：
加入購物車
一.軟件功能對比
二.成本考慮
三.滿足業務場景
四.平衡各種資源
一.是否滿足業務場景，各DB系統軟件功能對比
1.功能對比
oracle功能是大而全并且非常完善，無論是鎖定機制還是事物支持，無論是內置函數還是外部可擴展功能，無論OLTP和OLAP都能很好的支撐。
mysql作為開源數據的代表，得到了廣泛的應用，關系型數據庫的常用功能也全面覆蓋到了，但mysql的缺失大表的hash join功能，這讓他在OLAP發展受阻。
nosql主用用于K/V環境查詢的場景，在事務以及Join方面都未支持，能支持多維度復雜過濾的產品比較少。
從功能角度比較 oracle > mysql > nosql
2.性能強弱
2.1 write性能
Oracle需要記錄Redo Log且保證每次事務都fsync到物理磁盤以保證事務安全，屬于連續寫;數據的寫入大多是在內存中完成，后臺進程進行內存到磁盤的定期批量刷新，以隨機寫為主。MySQL InnoDB引擎與Oracle類似;MyISAM引擎無事務所以沒有事務日志到磁盤的fsync問題，但由于其表鎖的原因，并發較弱。從總體使用經驗來看 和Oracle相差不大。
NoSQL在數據存儲及日志記錄方面的架構及實現優化，使之在寫入性能方面較傳統數據庫有較大優勢。
總的來說write性能 NoSQL > Oracle = Mysql
2.2 簡單查詢
Oracle在高并發場景下，由于其在事務控制實現方面的優勢，以及多進程的機制，顯示出了相對明顯的優勢。
MySQL在并發數不是太高的前提下，如16，32個并發場景下，相對于Oracle沒有顯示出弱勢，甚至部分存儲引擎下還有一些優勢，但是隨著并發數 的增加，就逐步體現出了與Oracle的差距，這與其基于線程的機制也有一定關系。
NoSQL大部分時候的簡單查詢性能都不如前二者
所以簡單查詢的性能 Oracle > Mysql > Nosql
2.3 復雜查詢
Oracle統計信息涉及的方面非常多，優化器相對于MySQL來說也先進很多，再加上對Join方式的全面支持，無論是從功能還是性能角度來說，多表 Join都是Oracle的優勢所在。
MySQL其查詢優化器所能參考的統計信息相對較少，優化器深度也比Oracle少很多，所以在多表Join的時候出現執行計劃異常并不少見。此外，不 支持 Hash Join 的天生缺陷也讓其 Join 能力大打折扣。
NoSQL不支持Join，不具可比性，無疑是最弱的
索引復雜查詢性能 Oracle > Mysql > Nosql
3.擴展能力
Oracle由于極高的一致性要求，采用share Everything架構，造成架構上不少限制，使其擴展陳本較高
Mysql的Replication特性對一致性要求較弱，使其架構很靈活，但slave的延遲是個大問題。
Nosql大都支持分布式部署，具有非常好的scale out能力
所以擴展能力 Nosql > Mysql > Oracle
4.商業支持
NoSQL產品目前有商業支持的很少，MySQL的本地化商業支持選擇并不多，Oracle方面的商業支持無論是大型公司還是初創團隊，選擇性相對比較廣泛
所以在商業支持方面：Oracle > Mysql > Nosql
5.軟件可維護性
這一點一直是運維人最為關注的因素，畢竟任何一個軟件系統都是需要后期維護的。
NoSQL 產品由于發展時間相對較短，對于可維護性角度的支持相對要少很多，雖然大多提供了一些相應的小工具，但總體來說都還是過于簡單了些，所以這方面和相對成熟的MySQL以及Oracle相比較要弱。而Oracle為后期維護所做的
工作無疑是最為全面，無論是運行狀態的跟蹤，還是基礎的備份恢復等，都很完善。
所以在可維護性角度方面：Oracle > Mysql > Nosql
三.業務場景分析
1.數據一致性要求
雖然無論你什么時候去問任何一個業務方，都會告訴你他系統的數據是不能有任何一條丟失的，任何時候都需要實時反饋變化。但實際上是當你換一個提問方式，告訴他們如果在極端情況下（比如斷電）也要確保數據不會有任何丟失，會增加幾十上百萬的成本，那這個時候得到的回答可能就會完全不一樣了。所以我們在了解業務方對數據一致性要求的需求時候，一定要明確厲害關系，分清數據級別，并且做到最大化的信息透明，才能挖出最清晰的需求。對于數據一致性的保護，Oracle 無疑是做的最可靠的一個。
2.并發規模
并發規模會考驗我們的擴展能力，如果并發規模很大，那我們就需要很好的擴展能力以保證后續并發增長的需求。選用一個難以擴展的系統，會導致后續并發規模增長過程中無論是時間成本還是經濟成本都很高
3.邏輯復雜度
如果業務邏輯過于復雜，至少NoSQL肯定不是合適的選擇，至于MySQL還是Oracle，那就是考驗二者功能及性能的時候了。
4.總容量規模
我們的系統數據容量規模自然也會影響到軟件選型，規模非常大的，肯定要用分布式系統支持，至少也得分庫分表吧，這時候的擴展能力就會充分顯示出其優勢。
四.平衡各種資源做出最后選擇
通過軟件功能和成本對比，以及“場景分析”，我們已經為系統選型積累到相對充分的信息了，那是不是就可以比較明確的選擇出合適的系統了呢？
這時候我們可能會發現我們的數量規模很大，但是又希望能夠維護方便容易控制。這時候我們就面臨如下問題：數據量規模大選NoSQL更合適，便于維護又是Oracle的優勢，怎么辦？ 又或者如果我們有這樣一個場景：某交易系統，并發量很大，對于數據一致性要求很高，業務邏輯也并不簡單，怎么辦？Oracle可以為我們提供很好的數據保護，面對復雜邏輯的時候也能有最好的性能，但在擴展的時候會面臨成本壓力。MySQL可以提供較好的擴展方案，而且成本相對會較低，NoSQL無法解決復雜邏輯的業務場景。
類似問題可能會頻繁出現在我們的架構師面前，需要大家根據各種利弊進行權衡，做好平衡決策，在盡可能滿足業務需求的前提下，選擇一個更合適的系統。有些時候可能也不得不作出犧牲極少數業務需求來換取系統更大的發展，而不要為了保全某些極端場景的需求而影響整個選型。
總結
數據存儲軟件的多樣化趨勢勢不可當，不管是傳統龍頭的Oracle，還是開源典范的MySQL，以及NoSQL這一新秀，各有其特色，但同樣也都有其短板。沒有誰是萬能的，同樣也沒有哪一種架構能應對所有問題。
作為一個架構師，我們的選型工作需要做到下面幾點：
1. 在平時的工作中做好積累，以獲得上面的“系統功能對比”和“成本對比”中的信息。
2. 在面對具體業務需求的時候，充分挖掘最真實的需求，并將各種利弊信息透明化
3. 在最終決策的時候做好平衡，從需求實現，成本控制以及維護管理多個角度權衡利弊
4. 對新技術學習的渴求不能影響選型結果，同樣也不能對新技術的使用帶有恐懼。
Oracle，MySQL 以及 NoSQL，都只是一個軟件而已，實際使用效果更多的取決于使用者的能力。一個優秀的使用者能夠充分利用其優勢避開其軟肋，最終獲得最大化的價值。
二.成本考慮
1.軟件成本
這個沒有爭議：Oracle > Mysql = Nosql
2.運維成本與團隊管理水平
維護的服務器數量、耗電、自動化工具和人員配備數量
系統是否在團隊的可控范圍之內，出現性能、事故，團隊要有能力解決
3.人才環境
Oracle發展幾十年，具有充足的人才儲備，活躍的社區環境。
MySQL開源數據庫的王者，社區活躍，雖然人才總量常常供不應求，但總體還是處于良性狀態。
NoSQL新技術，產品眾多，社區活躍度遠不如前面二者，處于人才極度匱乏狀態