隨筆分類(157)

如果這個(gè)服務(wù)可以被其他非數(shù)據(jù)庫應(yīng)用代替（比如很多基于數(shù)據(jù)庫的計(jì)數(shù)器完全可以用WEB日志統(tǒng)計(jì)代替）最好將其禁用。非用數(shù)據(jù)庫不可嗎？雖然數(shù)據(jù)庫的確可以簡化很多應(yīng)用的結(jié)構(gòu)設(shè)計(jì)，但本身也是一個(gè)系統(tǒng)資源消耗比較大的應(yīng)用。在某些情況下文本，DBM比數(shù)據(jù)庫是更好的選擇，比如：很多應(yīng)用如果沒有很高的實(shí)時(shí)統(tǒng)計(jì)需求的話，完全可以先記錄到文件日志中，定期的導(dǎo)入到數(shù)據(jù)庫中做后續(xù)統(tǒng)計(jì)分析。如果還是需要記錄簡單的2維鍵－值對(duì)應(yīng)結(jié)構(gòu)的話可以使用類似于DBM的HEAP類型表。因?yàn)镠EAP表全部在內(nèi)存中存取，效率非常高，但服務(wù)器突然斷電時(shí)有可能出現(xiàn)數(shù)據(jù)丟失，所以非常適合存儲(chǔ)在線用戶信息，日志等臨時(shí)數(shù)據(jù)。即使需要使用數(shù)據(jù)庫的，應(yīng)用如果沒有太復(fù)雜的數(shù)據(jù)完整性需求的化，完全可以不使用那些支持外鍵的商業(yè)數(shù)據(jù)庫，比如MySQL。只有非常需要完整的商業(yè)邏輯和事務(wù)完整性的時(shí)候才需要Oracle這樣的大型數(shù)據(jù)庫。對(duì)于高負(fù)載應(yīng)用來說完全可以把日志文件，DBM，MySQL等輕量級(jí)方式做前端數(shù)據(jù)采集格式，然后用Oracle MSSQL DB2 Sybase等做數(shù)據(jù)庫倉庫以完成復(fù)雜的數(shù)據(jù)庫挖掘分析工作。

數(shù)據(jù)庫服務(wù)的主要瓶頸：單個(gè)服務(wù)的連接數(shù)。對(duì)于一個(gè)應(yīng)用來說，如果數(shù)據(jù)庫表結(jié)構(gòu)的設(shè)計(jì)能夠按照數(shù)據(jù)庫原理的范式來設(shè)計(jì)的話，并且已經(jīng)使用了最新版本的MySQL，并且按照比較優(yōu)化的方式運(yùn)行了，那么最后的主要瓶頸一般在于單個(gè)服務(wù)的連接數(shù)，即使一個(gè)數(shù)據(jù)庫可以支持并發(fā)500個(gè)連接，最好也不要把應(yīng)用用到這個(gè)地步，因?yàn)椴l(fā)連接數(shù)過多數(shù)據(jù)庫服務(wù)本身用于調(diào)度的線程的開銷也會(huì)非常大了。所以如果應(yīng)用允許的話：讓一臺(tái)機(jī)器多跑幾個(gè)MySQL服務(wù)分擔(dān)。將服務(wù)均衡的規(guī)劃到多個(gè)MySQL服務(wù)端口上：比如app_1 ==> 3301 app_2 ==> 3302...app_9 ==> 3309。一個(gè)1G內(nèi)存的機(jī)器跑上10個(gè)MySQL是很正常的。讓10個(gè)MySQLD承擔(dān)1000個(gè)并發(fā)連接效率要比讓2個(gè)MySQLD承擔(dān)1000個(gè)效率高的多。當(dāng)然，這樣也會(huì)帶來一些應(yīng)用編程上的復(fù)雜度；

使用單獨(dú)的數(shù)據(jù)庫服務(wù)器（不要讓數(shù)據(jù)庫和前臺(tái)WEB服務(wù)搶內(nèi)存），MySQL擁有更多的內(nèi)存就可能能有效的進(jìn)行結(jié)果集的緩存；在前面的啟動(dòng)腳本中有一個(gè)-O key_buffer=32M參數(shù)就是用于將缺省的8M索引緩存增加到32M（當(dāng)然對(duì)于）

應(yīng)用盡量使用PCONNECT和polling機(jī)制，用于節(jié)省MySQL服務(wù)建立連接的開銷，但也會(huì)造成MySQL并發(fā)鏈接數(shù)過多（每個(gè)HTTPD都會(huì)對(duì)應(yīng)一個(gè)MySQL線程）；

表的橫向拆分：讓最常被訪問的10%的數(shù)據(jù)放在一個(gè)小表里，90%的歷史數(shù)據(jù)放在一個(gè)歸檔表里（所謂：快慢表），數(shù)據(jù)中間通過定期“搬家”和定期刪除無效數(shù)據(jù)來節(jié)省，畢竟大部分應(yīng)用（比如論壇）訪問2個(gè)月前數(shù)據(jù)的幾率會(huì)非常少，而且價(jià)值也不是很高。這樣對(duì)于應(yīng)用來說總是在一個(gè)比較小的結(jié)果級(jí)中進(jìn)行數(shù)據(jù)選擇，比較有利于數(shù)據(jù)的緩存，不要指望MySQL中對(duì)單表記錄條數(shù)在10萬級(jí)以上還有比較高的效率。而且有時(shí)候數(shù)據(jù)沒有必要做那么精確，比如一個(gè)快表中查到了某個(gè)人發(fā)表的文章有60條結(jié)果，快表和慢表的比例是1:20，那么就可以簡單的估計(jì)這個(gè)人一共發(fā)表了1200篇。Google的搜索結(jié)果數(shù)也是一樣：對(duì)于很多上十萬的結(jié)果數(shù)，后面很多的數(shù)字都是通過一定的算法估計(jì)出來的。

數(shù)據(jù)庫字段設(shè)計(jì)：表的縱向拆分（過渡范化）：將所有的定長字段（char, int等）放在一個(gè)表里，所有的變長字段（varchar,text,blob等）放在另外一個(gè)表里，2個(gè)表之間通過主鍵關(guān)聯(lián)，這樣，定長字段表可以得到很大的優(yōu)化（這樣可以使用HEAP表類型，數(shù)據(jù)完全在內(nèi)存中存?。?，這里也說明另外一個(gè)原則，對(duì)于我們來說，盡量使用定長字段可以通過空間的損失換取訪問效率的提高。在MySQL4中也出現(xiàn)了支持外鍵和事務(wù)的InnoDB類型表，標(biāo)準(zhǔn)的MyISAM格式表和基于HASH結(jié)構(gòu)的HEAP內(nèi)存表，MySQL之所以支持多種表類型，實(shí)際上是針對(duì)不同應(yīng)用提供了不同的優(yōu)化方式；

仔細(xì)的檢查應(yīng)用的索引設(shè)計(jì)：可以在服務(wù)啟動(dòng)參數(shù)中加入 --log-slow-queries[=file]用于跟蹤分析應(yīng)用瓶頸，對(duì)于跟蹤服務(wù)瓶頸最簡單的方法就是用MySQL的status查看MySQL服務(wù)的運(yùn)行統(tǒng)計(jì)和show processlist來查看當(dāng)前服務(wù)中正在運(yùn)行的SQL，如果某個(gè)SQL經(jīng)常出現(xiàn)在PROCESS LIST中，一。有可能被查詢的此時(shí)非常多，二，里面有影響查詢的字段沒有索引，三，返回的結(jié)果數(shù)過多數(shù)據(jù)庫正在排序（SORTING）；所以做一個(gè)腳本：比如每2秒運(yùn)行以下show processlist;把結(jié)果輸出到文件中，看到底是什么查詢?cè)诔訡PU。

全文檢索：如果相應(yīng)字段沒有做全文索引的話，全文檢索將是一個(gè)非常消耗CPU的功能，因?yàn)槿臋z索是用不上一般數(shù)據(jù)庫的索引的，所以要進(jìn)行相應(yīng)字段記錄遍歷。關(guān)于全文索引可以參考一下基于Java的全文索引引擎lucene的介紹。

前臺(tái)應(yīng)用的記錄緩存：比如一個(gè)經(jīng)常使用數(shù)據(jù)庫認(rèn)證，如果需要有更新用戶最后登陸時(shí)間的操作，最好記錄更新后就把用戶放到一個(gè)緩存中（設(shè)置2個(gè)小時(shí)后過期），這樣如果用戶在2個(gè)小時(shí)內(nèi)再次使用到登陸，就直接從緩存里認(rèn)證，避免了過于頻繁的數(shù)據(jù)庫操作。

 查詢優(yōu)先的表應(yīng)該盡可能為where和order by字句中的字段加上索引，數(shù)據(jù)庫更新插入優(yōu)先的應(yīng)用索引越少越好。

避免使用視圖(viewport)與關(guān)聯(lián)。視圖viewport與關(guān)聯(lián)都是為了程序員處理相對(duì)復(fù)雜的數(shù)據(jù)管理提供方便的手段。萬物有其利，必有其弊。視圖和關(guān)聯(lián)提高了編程效率，都會(huì)較大地影響數(shù)據(jù)庫的訪問效率（事實(shí)上并不像一般資料說介紹的的那樣高效），因此如果是web應(yīng)用，則建議一般不要使用視圖與關(guān)聯(lián)。

將字符串(varchar)比較變成數(shù)字型(int)比較

每個(gè)系統(tǒng)都會(huì)有用戶管理，其中必然有 昵稱，密碼，郵件等的字符串類型數(shù)據(jù)比較的問題。在數(shù)據(jù)庫操作中，字符串比較的效率是相當(dāng)?shù)拖碌?。因此遇到字符串的比較，必須將其轉(zhuǎn)換為數(shù)字型比較。
具體做法是：在數(shù)據(jù)庫表中增加相應(yīng)的數(shù)字字段，比如 cNickname -> iNickNumber ，其中 iNickNumber 的數(shù)值為 cNickname 的 哈希值

數(shù)據(jù)庫表table的字段field不要太多

本以為無需說明，也是發(fā)現(xiàn)不少的朋友，為了省事，一股腦把所有的相關(guān)字段都放在一個(gè)表中間。這樣做的后果便是，程序?qū)懫饋砗唵瘟?，運(yùn)行效率下來了。
無論字段多少，有兩類字段是必須獨(dú)立出去的：一是進(jìn)程更新的字段，比如文章的點(diǎn)擊次數(shù)字段iShow，二是二進(jìn)制或者是text字段；

為每個(gè)數(shù)據(jù)庫表(table)設(shè)置 datetime 字段

在許多情況下，很多的表是不需要 datetime 字段用于保存時(shí)間的。本文的建議是你應(yīng)該為每個(gè)表都設(shè)置 datetime 字段，而且默認(rèn)值為 getdate()。
我們的經(jīng)驗(yàn)是，datetime 是實(shí)數(shù)，占用字節(jié)不多；在進(jìn)行系統(tǒng)維護(hù)，遠(yuǎn)程備份等環(huán)節(jié)都會(huì)發(fā)揮意想不到的效果。