隨筆分類(157)

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

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

使用單獨的數據庫服務器（不要讓數據庫和前臺WEB服務搶內存），MySQL擁有更多的內存就可能能有效的進行結果集的緩存；在前面的啟動腳本中有一個-O key_buffer=32M參數就是用于將缺省的8M索引緩存增加到32M（當然對于）

應用盡量使用PCONNECT和polling機制，用于節省MySQL服務建立連接的開銷，但也會造成MySQL并發鏈接數過多（每個HTTPD都會對應一個MySQL線程）；

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

數據庫字段設計：表的縱向拆分（過渡范化）：將所有的定長字段（char, int等）放在一個表里，所有的變長字段（varchar,text,blob等）放在另外一個表里，2個表之間通過主鍵關聯，這樣，定長字段表可以得到很大的優化（這樣可以使用HEAP表類型，數據完全在內存中存取），這里也說明另外一個原則，對于我們來說，盡量使用定長字段可以通過空間的損失換取訪問效率的提高。在MySQL4中也出現了支持外鍵和事務的InnoDB類型表，標準的MyISAM格式表和基于HASH結構的HEAP內存表，MySQL之所以支持多種表類型，實際上是針對不同應用提供了不同的優化方式；

仔細的檢查應用的索引設計：可以在服務啟動參數中加入 --log-slow-queries[=file]用于跟蹤分析應用瓶頸，對于跟蹤服務瓶頸最簡單的方法就是用MySQL的status查看MySQL服務的運行統計和show processlist來查看當前服務中正在運行的SQL，如果某個SQL經常出現在PROCESS LIST中，一。有可能被查詢的此時非常多，二，里面有影響查詢的字段沒有索引，三，返回的結果數過多數據庫正在排序（SORTING）；所以做一個腳本：比如每2秒運行以下show processlist;把結果輸出到文件中，看到底是什么查詢在吃CPU。

全文檢索：如果相應字段沒有做全文索引的話，全文檢索將是一個非常消耗CPU的功能，因為全文檢索是用不上一般數據庫的索引的，所以要進行相應字段記錄遍歷。關于全文索引可以參考一下基于Java的全文索引引擎lucene的介紹。

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

 查詢優先的表應該盡可能為where和order by字句中的字段加上索引，數據庫更新插入優先的應用索引越少越好。

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

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

每個系統都會有用戶管理，其中必然有 昵稱，密碼，郵件等的字符串類型數據比較的問題。在數據庫操作中，字符串比較的效率是相當低下的。因此遇到字符串的比較，必須將其轉換為數字型比較。
具體做法是：在數據庫表中增加相應的數字字段，比如 cNickname -> iNickNumber ，其中 iNickNumber 的數值為 cNickname 的 哈希值

數據庫表table的字段field不要太多

本以為無需說明，也是發現不少的朋友，為了省事，一股腦把所有的相關字段都放在一個表中間。這樣做的后果便是，程序寫起來簡單了，運行效率下來了。
無論字段多少，有兩類字段是必須獨立出去的：一是進程更新的字段，比如文章的點擊次數字段iShow，二是二進制或者是text字段；

為每個數據庫表(table)設置 datetime 字段

在許多情況下，很多的表是不需要 datetime 字段用于保存時間的。本文的建議是你應該為每個表都設置 datetime 字段，而且默認值為 getdate()。
我們的經驗是，datetime 是實數，占用字節不多；在進行系統維護，遠程備份等環節都會發揮意想不到的效果。