access數(shù)據(jù)庫(kù)負(fù)載量有多大？會(huì)崩潰嗎？近日在群里有網(wǎng)友在討論access數(shù)據(jù)庫(kù)的負(fù)載量問(wèn)題，意見(jiàn)不一，那么我們?cè)撨x擇哪種數(shù)據(jù)庫(kù)呢？有的網(wǎng)友主推php+mysql，在做站的時(shí)候選擇mysql、sql等大型數(shù)據(jù)庫(kù)，為了就是有一個(gè)好的負(fù)載量，避免因?yàn)閿?shù)據(jù)量大而造成崩潰，那么我們的數(shù)據(jù)量究竟會(huì)有那么大嗎？在這里蛐蛐工作室認(rèn)為，對(duì)于一般的站點(diǎn)來(lái)說(shuō)主推access，因?yàn)閍ccess管理方便，操作容易，服務(wù)器配置簡(jiǎn)單。對(duì)于一般中小型網(wǎng)站來(lái)說(shuō)，選擇access是完全沒(méi)有問(wèn)題的。如果你只是建一個(gè)企業(yè)站或者個(gè)人博客來(lái)用access，那更是完全沒(méi)有問(wèn)題的，有的人說(shuō)Access數(shù)據(jù)庫(kù)最大可以達(dá)到2G，也有說(shuō)4G的，那么你知道2G是什么概念嗎？

我們拿一個(gè)1G的access數(shù)據(jù)庫(kù)和本博客的access為例，通過(guò)對(duì)blog_Article表中的數(shù)據(jù)復(fù)制粘貼到25萬(wàn)條記錄數(shù)時(shí)，數(shù)據(jù)庫(kù)達(dá)到998M，算下來(lái)，按每天十篇文章算，能夠運(yùn)營(yíng)68年，對(duì)于一個(gè)中小型網(wǎng)站來(lái)說(shuō)是足夠了，至于說(shuō)網(wǎng)站的訪問(wèn)量引起access查詢慢的問(wèn)題，我們可以考慮采用生成靜態(tài)頁(yè)面的方式來(lái)應(yīng)付訪問(wèn)量大的站點(diǎn)。

access記錄數(shù)達(dá)到25000條

access數(shù)據(jù)庫(kù)大小達(dá)到1G

下面是一篇從網(wǎng)上轉(zhuǎn)來(lái)的文章，有興趣的網(wǎng)友可以閱讀一下：

記得幾年前剛學(xué)程序的時(shí)候經(jīng)常聽(tīng)看網(wǎng)絡(luò)上留傳的文章說(shuō)ACCESS的極限是100M，超了性能就會(huì)直線下降，一直到現(xiàn)在都是這樣，可以很輕易的找出很多關(guān)于ACCESS的是非常差的數(shù)據(jù)庫(kù)的文章。

幾年前我學(xué)習(xí)用ASP做新聞系統(tǒng)由于ACCESS是最方便的數(shù)據(jù)庫(kù)（我認(rèn)為是最方便的），當(dāng)時(shí)用的就是ACCESS+ASP的組合，當(dāng)時(shí)心里想反正做了這個(gè)東西我的站訪問(wèn)量低對(duì)ACCESS應(yīng)該也可以滿足要求。（直到今天我還是用ACCESS+ASP的組合）

最近幾年給很多企業(yè)做了不少的網(wǎng)站，也全是ACCESS，不過(guò)做的過(guò)程中的思想就一個(gè)，ACCESS是性能低下的數(shù)據(jù)庫(kù)，不適合做高訪問(wèn)量的站來(lái)使用。這種思想一直延續(xù)到去年接了一個(gè)站點(diǎn)活。這個(gè)網(wǎng)站原先的結(jié)構(gòu)是ASP+SQL，屬于行業(yè)類(lèi)網(wǎng)站，每天訪問(wèn)量不是很高大約日/IP2000左右，瀏覽量1~2萬(wàn)次左右，但數(shù)據(jù)量很高，有超過(guò)15萬(wàn)條數(shù)據(jù)。這個(gè)客戶在我們公司做了百度和3721，那段時(shí)間他的站所在的服務(wù)器頻繁死機(jī)，最后服務(wù)器管理員確認(rèn)是他的網(wǎng)站有問(wèn)題，最終找到我希望我可以幫他解決問(wèn)題。我接手后先分析了他原先數(shù)據(jù)的結(jié)構(gòu)，發(fā)現(xiàn)很多字段都是多余的，也沒(méi)使用關(guān)系，甚至有的數(shù)據(jù)表連索引也沒(méi)有，總之問(wèn)題多多。后來(lái)我對(duì)數(shù)據(jù)庫(kù)數(shù)據(jù)和程序進(jìn)行了優(yōu)化處理經(jīng)過(guò)測(cè)試可以達(dá)到每天10萬(wàn)次以上不會(huì)出現(xiàn)服務(wù)器死掉的狀況。（開(kāi)了多個(gè)頁(yè)使用META連續(xù)刷新一天）值得注意的是這次我用的數(shù)據(jù)庫(kù)是ACCESS而不是原先的SQL。

至此我徹底對(duì)ACCESS性能底下的看法有了很大改觀，一至于我現(xiàn)在自己的一個(gè)小站也是用ACCESS，目前數(shù)據(jù)庫(kù)已經(jīng)600多M了，性能目前還不錯(cuò)，一般每天瀏覽量在20~30萬(wàn)次左右，服務(wù)器CPU占用在15%上下。

寫(xiě)到這里我并不是貶低SQL，事實(shí)上SQL的確比ACCESS強(qiáng)我不否認(rèn)。我認(rèn)為一個(gè)一個(gè)數(shù)據(jù)庫(kù)的好壞很大程度上取決于一個(gè)程序員有沒(méi)有真正了解數(shù)據(jù)用好數(shù)據(jù)庫(kù)，有沒(méi)有針對(duì)程序做好優(yōu)化，程序是否合理。

在這里我想問(wèn)問(wèn)非常熟悉ACCESS的朋友，ACESS到底能承受什么樣的極限參數(shù)才會(huì)性能?chē)?yán)重下降？如果是SQL又能承受多少？

數(shù)據(jù)庫(kù)量小，只是少量用戶訪問(wèn)時(shí)，access比sql要快得多，access沒(méi)有sql占資源多，但數(shù)據(jù)量多了，access就不能做復(fù)雜的查詢了，會(huì)出錯(cuò)！時(shí)間多了就會(huì)崩潰掉！

從上面可以看出，數(shù)據(jù)庫(kù)和訪問(wèn)量不大的站點(diǎn)采用access來(lái)做為數(shù)據(jù)庫(kù)是完全沒(méi)問(wèn)題的，歡迎在下面發(fā)表自己的意見(jiàn)。