一個(gè)成熟的數(shù)據(jù)庫架構(gòu)并不是一開始設(shè)計(jì)就具備高可用、高伸縮等特性的，它是隨著用戶量的增加，基礎(chǔ)架構(gòu)才逐漸完善。這篇博文主要談MySQL數(shù)據(jù)庫發(fā)展周期中所面臨的問題及優(yōu)化方案，暫且拋開前端應(yīng)用不說，大致分為以下五個(gè)階段：

1、數(shù)據(jù)庫表設(shè)計(jì)

項(xiàng)目立項(xiàng)后，開發(fā)部根據(jù)產(chǎn)品部需求開發(fā)項(xiàng)目，開發(fā)工程師工作其中一部分就是對(duì)表結(jié)構(gòu)設(shè)計(jì)。對(duì)于數(shù)據(jù)庫來說，這點(diǎn)很重要，如果設(shè)計(jì)不當(dāng)，會(huì)直接影響訪問速度和用戶體驗(yàn)。影響的因素很多，比如慢查詢、低效的查詢語句、沒有適當(dāng)建立索引、數(shù)據(jù)庫堵塞（死鎖）等。當(dāng)然，有測試工程師的團(tuán)隊(duì)，會(huì)做壓力測試，找bug。對(duì)于沒有測試工程師的團(tuán)隊(duì)來說，大多數(shù)開發(fā)工程師初期不會(huì)太多考慮數(shù)據(jù)庫設(shè)計(jì)是否合理，而是盡快完成功能實(shí)現(xiàn)和交付，等項(xiàng)目有一定訪問量后，隱藏的問題就會(huì)暴露，這時(shí)再去修改就不是這么容易的事了。

2、數(shù)據(jù)庫部署

該運(yùn)維工程師出場了，項(xiàng)目初期訪問量不會(huì)很大，所以單臺(tái)部署足以應(yīng)對(duì)在1500左右的QPS（每秒查詢率）。考慮到高可用性，可采用MySQL主從復(fù)制+Keepalived做雙擊熱備，常見集群軟件有Keepalived、Heartbeat。

雙機(jī)熱備博文：http://lizhenliang.blog.51cto.com/7876557/1362313

3、數(shù)據(jù)庫性能優(yōu)化

如果將MySQL部署到普通的X86服務(wù)器上，在不經(jīng)過任何優(yōu)化情況下，MySQL理論值正常可以處理2000左右QPS，經(jīng)過優(yōu)化后，有可能會(huì)提升到2500左右QPS，否則，訪問量當(dāng)達(dá)到1500左右并發(fā)連接時(shí)，數(shù)據(jù)庫處理性能就會(huì)變慢，而且硬件資源還很富裕，這時(shí)就該考慮軟件問題了。那么怎樣讓數(shù)據(jù)庫最大化發(fā)揮性能呢？一方面可以單臺(tái)運(yùn)行多個(gè)MySQL實(shí)例讓服務(wù)器性能發(fā)揮到最大化，另一方面是對(duì)數(shù)據(jù)庫進(jìn)行優(yōu)化，往往操作系統(tǒng)和數(shù)據(jù)庫默認(rèn)配置都比較保守，會(huì)對(duì)數(shù)據(jù)庫發(fā)揮有一定限制，可對(duì)這些配置進(jìn)行適當(dāng)?shù)恼{(diào)整，盡可能的處理更多連接數(shù)。

具體優(yōu)化有以下三個(gè)層面：

3.1 數(shù)據(jù)庫配置優(yōu)化

MySQL常用有兩種存儲(chǔ)引擎，一個(gè)是MyISAM，不支持事務(wù)處理，讀性能處理快，表級(jí)別鎖。另一個(gè)是InnoDB，支持事務(wù)處理（ACID），設(shè)計(jì)目標(biāo)是為處理大容量數(shù)據(jù)發(fā)揮最大化性能，行級(jí)別鎖。

表鎖：開銷小，鎖定粒度大，發(fā)生死鎖概率高，相對(duì)并發(fā)也低。
行鎖：開銷大，鎖定粒度小，發(fā)生死鎖概率低，相對(duì)并發(fā)也高。
為什么會(huì)出現(xiàn)表鎖和行鎖呢？主要是為了保證數(shù)據(jù)的完整性，舉個(gè)例子，一個(gè)用戶在操作一張表，其他用戶也想操作這張表，那么就要等第一個(gè)用戶操作完，其他用戶才能操作，表鎖和行鎖就是這個(gè)作用。否則多個(gè)用戶同時(shí)操作一張表，肯定會(huì)數(shù)據(jù)產(chǎn)生沖突或者異常。

根據(jù)以上看來，使用InnoDB存儲(chǔ)引擎是最好的選擇，也是MySQL5.5以后版本中默認(rèn)存儲(chǔ)引擎。每個(gè)存儲(chǔ)引擎相關(guān)聯(lián)參數(shù)比較多，以下列出主要影響數(shù)據(jù)庫性能的參數(shù)。