SQLite 是一個(gè)類似Access 的輕量級(jí)數(shù)據(jù)庫系統(tǒng)，但是更小、更快、容量更大，并發(fā)更高。為什么說SQLite 最適合中小站點(diǎn)網(wǎng)站制作呢？并不是說其他數(shù)據(jù)庫不好， Oracle、MySQL、SQLServer 也都是非常優(yōu)秀的DBS，只不過他們?cè)O(shè)計(jì)目標(biāo)不同，特性不同，所以只有更適用某個(gè)應(yīng)用場(chǎng)景，沒有絕對(duì)的好壞之分。

SQLite 數(shù)據(jù)庫的優(yōu)勢(shì)

1. 真正開源的小型嵌入式數(shù)據(jù)庫，支持事務(wù)、觸發(fā)器器。

2. 性能至少優(yōu)于MySql 4.1.0 。

3. 目前已被幾乎所有的高級(jí)程序開發(fā)語言支持。

4. 由于可以自定義數(shù)據(jù)庫函數(shù)，尤其在php 的擴(kuò)展中可支持全部php 函數(shù)，其性能可以說是無上限的。

5. 有很多用PHP 開發(fā)的管理工具，與PhpMyAdmin 的界面很相似，比如常見的：SQLiteManager。

明月作為一個(gè)運(yùn)維人員，搭建、運(yùn)營(yíng)和管理過很多中小型站點(diǎn)，也總結(jié)出了一個(gè)大概的“中小型站點(diǎn)特點(diǎn)”出來：

中小型站點(diǎn)的特點(diǎn)

1. 數(shù)據(jù)量不超過10 萬

2. 日頁面訪問量不超過10 萬

3. 一部分網(wǎng)站全部生成靜態(tài)頁面，一部分網(wǎng)站實(shí)時(shí)查詢數(shù)據(jù)庫動(dòng)態(tài)訪問。

4. 站長(zhǎng)不懂技術(shù)，不懂得復(fù)雜的數(shù)據(jù)庫維護(hù)，只會(huì)用FTP 管理網(wǎng)站。

5. 個(gè)人站點(diǎn)基本上是一個(gè)人管理，一般情況下只有一個(gè)人在訪問后臺(tái)，沒有并發(fā)。

6. 對(duì)數(shù)據(jù)庫來說是讀多寫少，只有在站長(zhǎng)訪問后臺(tái)的時(shí)候才會(huì)寫入。

7. 多運(yùn)行于虛擬主機(jī)又或者輕量應(yīng)用云服務(wù)器，大部分PHP 主機(jī)均同時(shí)支持MySQL，小部分PHP 主機(jī)需要單獨(dú)購買MySQL，而輕量應(yīng)用云服務(wù)器更是有CPU 基準(zhǔn)限制等等。

8. 多數(shù)中小站點(diǎn)的HTTP 服務(wù)與MySQL 部署在同一服務(wù)器上。

綜上所述可見中小型站點(diǎn)的性能需求是很小的，基于這個(gè)最大的特點(diǎn)來看，使用SQLite 數(shù)據(jù)庫顯得更加的契合，對(duì)于后期管理維護(hù)也是超級(jí)的簡(jiǎn)單和高效。

1. SQLite 在中小型站點(diǎn)下的突出表現(xiàn)

2. 與MySQL 相比，它更徹底的免費(fèi)，并且沒有任何使用上的限制。

3. 非常小巧，PHP5 以上版本中無需任何配置即可支持SQLite。

4. 無需單獨(dú)購買數(shù)據(jù)庫服務(wù)，無服務(wù)器進(jìn)程，配置成本為零。

5. 整個(gè)數(shù)據(jù)庫存儲(chǔ)在一個(gè)單個(gè)的文件中，數(shù)據(jù)導(dǎo)入導(dǎo)出備份恢復(fù)都是復(fù)制文件，維護(hù)難度為零。

讀速度快，在數(shù)據(jù)量不是很大的情況下速度較快，更重要的是：省掉了一次數(shù)據(jù)庫遠(yuǎn)程鏈接沒有復(fù)雜的權(quán)限驗(yàn)證，打開就能操作。

選擇SQLite 后成本的降低幾乎是必然的，技術(shù)上的支持和兼容更是毫無壓力，后期維護(hù)備份幾乎是無腦操作即可，整體的性能表現(xiàn)也完美的契合了硬件配置。當(dāng)然SQLite 的缺點(diǎn)也是不可避免的，但是在中小型站點(diǎn)上能很好的規(guī)避：

1. 并發(fā)低動(dòng)態(tài)訪問時(shí)當(dāng)訪問量不超過10 萬PV 的時(shí)候，SQLite 超過Access 的并發(fā)能力已經(jīng)綽綽有余；生成靜態(tài)頁后更無需考慮數(shù)據(jù)庫的并發(fā)問題。

2. 在大數(shù)據(jù)量的情況下表現(xiàn)較差但是中小站點(diǎn)一般情況下數(shù)據(jù)量不超過10 萬，而SQlite 在100 萬數(shù)據(jù)量之下表現(xiàn)還不錯(cuò)，因?yàn)槭〉袅藢?duì)數(shù)據(jù)庫服務(wù)器的遠(yuǎn)程連接甚至?xí)臁?/p>

3. 寫入較慢默認(rèn)配置下的SQlite 的寫入速度比MySQL 慢了很多，但是CMS 應(yīng)用場(chǎng)景的寫入操作較少。在插入新文章的時(shí)候基本感受不到慢。集中的寫數(shù)據(jù)庫操作只有在安裝的時(shí)候會(huì)出現(xiàn)，不過只出現(xiàn)一次，可以忽略。

4. 為已有的表加索引較慢但是在中小站點(diǎn)CMS 中不會(huì)有這樣的需求，可以忽略。

5. 無法將MySQL 部署到與前端機(jī)不同的服務(wù)器上，但是中小站點(diǎn)也沒有分開部署的需求。

對(duì)于中小型站點(diǎn)來說MySQL 這類數(shù)據(jù)庫確實(shí)非常先進(jìn)，但說實(shí)話都是“大材小用”、“殺雞焉用牛刀”了，甚至可以毫不夸張的說大部分中小型站點(diǎn)需求僅僅用到了MySQL 這類數(shù)據(jù)庫10%的功能而已，還得為了適配MySQL 在硬件上做出取舍（比如：內(nèi)存低于2G 是無法使用MySQL 高版本的）徒增成本而已，與其這樣為啥不簡(jiǎn)單的選擇SQLite 這類輕量的數(shù)據(jù)庫來使用呢？