對于許多程序員而言，基本上不需要決定公司選擇哪種數(shù)據(jù)庫。當程序員加入公司時，公司早已經(jīng)確認了的大多數(shù)技術(shù)選擇，尤其是數(shù)據(jù)庫選擇，因為一旦選擇了數(shù)據(jù)庫，以后遷移的成本仍然很高，因此要求程序員在使用現(xiàn)有數(shù)據(jù)庫時，具有一定的避坑能力。那么程序員如何在數(shù)據(jù)庫中避坑的？下文總結(jié)了5點，幫助大家更好的應用數(shù)據(jù)庫。

程序員如何在數(shù)據(jù)庫中避坑的？

再好的數(shù)據(jù)庫，如果使用姿勢不對也是枉然，更何況很多程序員并不怎么懂數(shù)據(jù)庫。在數(shù)據(jù)庫使用中，我們常會碰到很多問題。

　　人為失誤

人為失誤一般分兩類，一種是DBA操作失誤，一種是程序員開人員程序里使用不當。DBA一般我們認為是數(shù)據(jù)庫管理的專家了，出錯的概率比較小，但是一旦出錯，危險是做大的。比如我們經(jīng)常調(diào)侃的“刪庫跑路”，雖然是依據(jù)調(diào)侃，但是我是真真的見到過兩次，生產(chǎn)環(huán)境出現(xiàn)一次，就會在你的工作生涯上記上“光輝”一筆，所以說DBA算是一個高危工作了吧。另一種是開發(fā)人員使用不當。常見的比如在使用大表時候，不考慮是否有索引，進行了全表掃描，導致整個數(shù)據(jù)庫被拖垮。

數(shù)據(jù)庫的訪問瓶頸

只要是數(shù)據(jù)庫，就會有并發(fā)量的限制。以前使用MySQL，我們經(jīng)常看到互聯(lián)網(wǎng)公司并發(fā)上萬的壓測。但是對于很多新型的MPP數(shù)據(jù)庫，他們的并發(fā)并不是你想的那樣，MPP一般由集群CPU物理核數(shù)有關(guān)。比如以前開發(fā)程序查詢的MySQL，遷移到GP，那么你的數(shù)據(jù)庫連接池要改一改了。特別是對于一些面向互聯(lián)網(wǎng)的網(wǎng)站，數(shù)據(jù)庫管理層也要做訪問策略，不然，一個外掛可能就會把你的庫搞死。

　　索引

我們都知道索引在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫中使用的很多，效果也很明顯。但是你要知道索引是拿存儲換時間的操作。曾遇到過開發(fā)人員動不動就讓建索引，搞的好像不要錢一樣。還有像Vertica這個數(shù)據(jù)庫就比較友好了，不需要建立索引，只需要在建表時候預排序分布即可提高查詢效率，同時列存儲的數(shù)據(jù)還是壓縮的，降低了存儲，還提高了查詢效率。

HA（高可用）

數(shù)據(jù)庫作為存儲查詢引擎的同時，支撐著大型網(wǎng)站的后臺服務，一定要考慮高可用。對于一些天然不支持高可用或者高可用不友好的選型一定要小心。再來安利一下Vertica，無Master MPP架構(gòu)，集群中只要不超過一半機器宕機，集群就處于可用狀態(tài)。

　　標準SQL

SQL就是針對數(shù)據(jù)庫查詢產(chǎn)生的語言。隨著新型數(shù)據(jù)庫的出現(xiàn)，很多數(shù)據(jù)庫不支持標準SQL或者支持很弱。比如HBase。這對于很多以前的開發(fā)人員還是有一定學習門檻的，還有就是后期如果出現(xiàn)業(yè)務遷移還是很困難的。

Oracle支持標準SQL，但是存儲過程并不是每個數(shù)據(jù)庫都有的，這也是阿里為何禁用存儲過程的吧，你無法想象一個上萬行存儲過程的遷移要耗費多少資源。對標準SQL的支持，降低了開發(fā)人員的使用門檻，也降低了以后業(yè)務遷移的風險。

以上就是關(guān)于程序員如何在數(shù)據(jù)庫中避坑的全部內(nèi)容介紹，想了解更多關(guān)于數(shù)據(jù)庫的信息，請繼續(xù)關(guān)注中培偉業(yè)。