因?yàn)橹饕芾頂?shù)據(jù)庫平臺(tái)，所以和公司各個(gè)部門的相關(guān)技術(shù)人員都打過不少交道，然后從日常溝通中，了解到不少技術(shù)人員對(duì)數(shù)據(jù)庫的觀念，有正確的，有錯(cuò)誤的，今天就列一些常見的錯(cuò)誤觀念：

1，發(fā)現(xiàn)鎖表嚴(yán)重情況，會(huì)立刻想到改用Innodb,好像Innodb的行級(jí)鎖之后，就不會(huì)表鎖了，持這種觀念的開發(fā)人員不在少數(shù)，其實(shí)他們不知道在做排序或是where條件復(fù)雜的情況下，一樣會(huì)產(chǎn)生表鎖。

2， 發(fā)現(xiàn)磁盤IO過大，會(huì)立刻想到分表，(這個(gè)方向是好的)，但是一問，結(jié)果是分幾千張表，認(rèn)為這樣之后，磁盤IO壓力就會(huì)下降，其實(shí)分表并不能解決磁盤IO,結(jié)合分庫+分表，然后分擔(dān)到不同的物理機(jī)器，這樣才能真正做到拆分，降低磁盤IO。

3, 大部分應(yīng)用開發(fā)人員都會(huì)對(duì)表名定義的很通俗，如user,其實(shí)這樣做不好，因?yàn)樵谶M(jìn)行抓包分析時(shí)候，這種沒有特征的表名會(huì)導(dǎo)致故障排查變難。

4， 大部分應(yīng)用開發(fā)人員不喜歡定時(shí)清理歷史數(shù)據(jù)，只管存，不管清，導(dǎo)致項(xiàng)目數(shù)據(jù)量達(dá)到一定程度，再跑清理程序時(shí)候會(huì)比較影響服務(wù)。

5， 有些應(yīng)用開發(fā)人員缺乏對(duì)表數(shù)據(jù)字段的控制，一個(gè)表放100多個(gè)字段，超級(jí)恐怖。

6，還有的應(yīng)用開發(fā)人員干脆把表定義的超級(jí)多mediutext,拿數(shù)據(jù)庫當(dāng)存儲(chǔ)用了，而且是冷熱數(shù)據(jù)都放一起，搞得偶很無語。

7，應(yīng)用開發(fā)人員經(jīng)常會(huì)跑一些奇怪的join,嵌套子查詢的SQL,但是卻不去explain一下到底會(huì)有多大的掃描集，我見過有跑到上億掃描集的。

8，對(duì)MySQL的觸發(fā)器過于依賴，但是不考慮如果在誤操作之后的恢復(fù)操作，會(huì)產(chǎn)生業(yè)務(wù)邏輯的混亂。

9，很多技術(shù)開發(fā)人員一聽重要如收費(fèi)相關(guān)的項(xiàng)目，就是想要用Innodb的事務(wù)機(jī)制做保障，其實(shí)真沒必要，我管的項(xiàng)目中收費(fèi)讀書和英超收費(fèi)頻道都是用myisam的，跑了快2年了，至今沒發(fā)現(xiàn)有用戶要告公司收費(fèi)不準(zhǔn)的問題。

10，很多開發(fā)人員喜歡在SQL語句使用Now()這樣的語句，其實(shí)應(yīng)該盡量讓PHP程序去獲得時(shí)間。因?yàn)楫?dāng)你通過binlog進(jìn)行誤操作恢復(fù)時(shí)候，你就能體會(huì)我說的意思了。

【編輯推薦】

1. InnoDB還是MyISAM 再談MySQL存儲(chǔ)引擎的選擇
2. 詳解MySQL三項(xiàng)實(shí)用開發(fā)知識(shí)
3. 使用DB2必須了解的幾個(gè)知識(shí)點(diǎn)