談?wù)勔恢北婚_發(fā)者們過于在乎的性能問題

【本文轉(zhuǎn)自博客園 作者：十三燕 原文鏈接：https://www.cnblogs.com/13yan/p/3539938.html】
軟件開發(fā)者最初為了做出某種功能而努力著。

　　當(dāng)有一天，開發(fā)者們掌握了開發(fā)的門道，實(shí)現(xiàn)功能已經(jīng)家常便飯了。

　　于是人們開始考慮更多問題，性能就是一個(gè)問題。

　　通常2-4年工作經(jīng)驗(yàn)的開發(fā)者會很糾結(jié)這個(gè)問題，但由于基礎(chǔ)參差不齊，對性能的理解也大不相同。

　　那些年也許我們過于在乎性能問題了。

　　誤區(qū)一：O/RM工具影響性能

　　發(fā)現(xiàn)很多人喜歡拿O/RM工具討論性能，害怕引入ORM工具以后帶來損失性能的問題，

　　不過據(jù)我所知目前一些主流的ORM工具性能都半斤八兩，ORM工具之間的比較不是性能問題，而是使用習(xí)慣的問題。

　　ORM與原生ADO.NET比較，肯定會損失一定的性能，但是帶來了提高開發(fā)效率的優(yōu)勢。

　　據(jù)我所知，很多同行做著的OA、ERP什么的系統(tǒng)用戶數(shù)量都不多，

　　過于計(jì)較性能問題，那就是拿5%不到的特殊情況，拒絕大多數(shù)情況提高開發(fā)效率。

　　沒有人說用了ORM就一定要每個(gè)地方都用ORM到底。

　　誤區(qū)二：存儲過程可提高性能

　　采用存儲過程本身沒有什么問題，過于頻繁地用存儲過程，調(diào)試就會比較煩。

　　1、程序里加斷點(diǎn)，然后變量復(fù)制到存儲過程里加斷點(diǎn)調(diào)試。

　　2、過于依賴存儲過程，數(shù)據(jù)庫里包含業(yè)務(wù)邏輯，業(yè)務(wù)邏輯就分散在程序與數(shù)據(jù)庫，代碼可讀性損失。

　　3、調(diào)用存儲過程的確讓很多SQL語句變成了一個(gè)存儲過程名和參數(shù)，減少了網(wǎng)絡(luò)傳輸，但很多情況下不需要這點(diǎn)性能。

　　4、業(yè)務(wù)邏輯都寫在存儲過程里了，用面向?qū)ο笳Z言的話就當(dāng)做面向過程語言用了，對開發(fā)功能復(fù)雜的項(xiàng)目比較不利。

　　誤區(qū)三：大數(shù)據(jù)性能問題

　　只要接觸到幾百萬或者幾千萬就認(rèn)為是大數(shù)據(jù)，有些人甚至以為MSSQLSERVER數(shù)據(jù)庫碰到千萬級的就得掛了。

　　其實(shí)不然，如果每個(gè)月以百萬級的數(shù)據(jù)增長，那么對查詢而言這些都是小數(shù)據(jù)，利用分區(qū)與查詢約束還是比較容易解決的。

　　而用同樣的方法，MSSQLSERVER也能處理超越千萬級的數(shù)據(jù)。

　　數(shù)據(jù)庫真正的性能問題在哪里?

　　真正的性能問題從宏觀上講我認(rèn)為是數(shù)據(jù)庫設(shè)計(jì)問題，微觀上則是SQL調(diào)優(yōu)。

　　總結(jié)

　　不該以性能為理由拒絕ORM工具，也不該濫用存儲過程。

　　關(guān)注性能從設(shè)計(jì)階段開始，不可過于糾結(jié)性能問題而損失開發(fā)效率。