問(wèn)答專(zhuān)欄Q & A COLUMN
在實(shí)際開(kāi)發(fā)中，絕大部分開(kāi)發(fā)人員應(yīng)該都沒(méi)有機(jī)會(huì)接觸到上億級(jí)別的數(shù)據(jù)，如果SQL Server中的數(shù)據(jù)量達(dá)到億級(jí)了，我們勢(shì)必要對(duì)數(shù)據(jù)庫(kù)服務(wù)器做一系列的優(yōu)化措施，否則難以支撐這個(gè)量級(jí)。
1、合理的索引
眾所周知，合理的索引可有效提升SELECT效率。但是，在大量寫(xiě)入操作時(shí)，索引是要維護(hù)的，會(huì)降低寫(xiě)入速度。所以要建立合理的索引，而不是索引數(shù)量越多越好。對(duì)于多余索引、低效索引都可以刪除掉。
2、分布式數(shù)據(jù)庫(kù)部署
我們可以按業(yè)務(wù)類(lèi)型將數(shù)據(jù)做垂直領(lǐng)域劃分，不同業(yè)務(wù)存儲(chǔ)在不同數(shù)據(jù)庫(kù)服務(wù)器上，通過(guò)分布式部署將業(yè)務(wù)分離，有效緩解了數(shù)據(jù)庫(kù)壓力。不過(guò)這種分布式部署對(duì)于后期業(yè)務(wù)整合和綜合查詢不是太友好，架構(gòu)如下圖示：
3、數(shù)據(jù)庫(kù)分區(qū)
默認(rèn)情況下，數(shù)據(jù)庫(kù)里一張表的數(shù)據(jù)都會(huì)存儲(chǔ)在一個(gè)地方，但采用分區(qū)后，這些數(shù)據(jù)會(huì)均衡存儲(chǔ)在不同地方，這樣做能提高SELECT查詢效率。一旦某個(gè)分區(qū)損壞后，也可以利用修復(fù)工具對(duì)單分區(qū)進(jìn)行修復(fù)。注意，數(shù)據(jù)庫(kù)分區(qū)只適用于海量數(shù)據(jù)前提下，數(shù)據(jù)量較少時(shí)不需要做，因?yàn)閿?shù)據(jù)庫(kù)分區(qū)也有一定的性能消耗。
4、數(shù)據(jù)庫(kù)分表
數(shù)據(jù)庫(kù)本身都是有性能瓶頸的，我們可以采取橫向擴(kuò)展方案來(lái)解決查詢效率問(wèn)題?？梢愿鶕?jù)業(yè)務(wù)需求，按一定規(guī)則（比如：時(shí)間）來(lái)對(duì)數(shù)據(jù)進(jìn)行分表存儲(chǔ)，這樣一個(gè)大的數(shù)據(jù)集被分割成很多小的數(shù)據(jù)集，每次查詢都在小的數(shù)據(jù)集合里查詢，性能會(huì)更高。
5、讀寫(xiě)分離
讀寫(xiě)分離顧名思義就是數(shù)據(jù)庫(kù)讀操作和寫(xiě)操作在不同數(shù)據(jù)庫(kù)上。因?yàn)閿?shù)據(jù)庫(kù)為了保證數(shù)據(jù)有效性，在寫(xiě)入數(shù)據(jù)時(shí)往往會(huì)進(jìn)行寫(xiě)鎖操作，很多情況下會(huì)影響讀操作的性能。我們寫(xiě)入數(shù)據(jù)時(shí)操作主庫(kù)，查詢數(shù)據(jù)時(shí)操作從庫(kù)，提高了數(shù)據(jù)并發(fā)性。
SQL Server提供了一個(gè)SQL Server Profile工具，通過(guò)它可以分析數(shù)據(jù)庫(kù)查詢效率。如下圖示：
以上就是我的觀點(diǎn)，對(duì)于這個(gè)問(wèn)題大家是怎么看待的呢？歡迎在下方評(píng)論區(qū)交流 ~ 我是科技領(lǐng)域創(chuàng)作者，十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗(yàn)，歡迎關(guān)注我了解更多科技知識(shí)！
評(píng)論0
加載中...
首先謝謝邀請(qǐng)
四億數(shù)據(jù)已經(jīng)是個(gè)很大的基數(shù)了。可以考慮是用nosql存儲(chǔ)。如果還使用SQL的化可以考慮分表。
評(píng)論0
加載中...0
回答0
回答0
回答0
回答2
回答0
回答0
回答0
回答0
回答0
回答
