前言
如果你沒有看過之前的（一）或者沒有下載這份手冊的話，下面有鏈接，還是對照手冊食用畢竟好。
http://www.cnblogs.com/linkstar/p/6413402.html
（二）的地址在下面，是關於異常和日志的。
http://www.cnblogs.com/linkstar/p/6415788.html
手冊我特地在博客園文件中放了一份在線的僅供參考（因為好像發現最上面那個地址需要登錄。。。）
該說的我覺得（一）里面我都說完了，那么就直接進入正題吧。
Mysql規約
照例先講廢話：
mysql作為開源的數據庫，因為其大小和功能等一直被人們所喜歡，所以用的人比較多，學習時我們也經常使用，對於小型項目來說，mysql很多時候已經足夠用了，所以這里阿里給出的也是mysql的規范，對於其他的數據庫來說也是一樣的。但是，對於數據庫的表名，字段名，sql語句，這些的規范對於設計數據庫和開發來說是十分重要的，因為數據庫和代碼不同，代碼可以修改，但是數據庫的修改真的是“牽一發而動全身”，所以開發前還是仔細斟酌。
廢話完了。
在下面先講一個重點：MySQL中的數據庫名和表名和操作系統有關，在windows操作系統中，不區分大小寫，在unix ，linux操作系統中，是區分大小寫的。這個坑我是被踩過的，就是因為命名不規范的原因，有人在命名表的時候使用了大寫字母（實際產生的表的名字還是小寫），而且在sql語句中使用的也是大寫字母，因為開發是在windows平台，一切正常，因為大小寫不區分，所以執行的時候，大寫字母自動變成小寫，但是之后一到linux服務器上面，就炸炸炸！！！所以這就是為什么表的名字必須使用小寫和下划線的原因。
建表規約
1、很多人會奇怪為什么會有這一條，我補充一句，合適的數據類型可以在省空間的同時避免你很多的錯誤。再附贈一張mysql數據類型和java數據類型對應的表，這張表挺好用的，等到你用多了之后，自然就能熟練對應了。
6、float和double在使用時會出現精度丟失的情況，使用decimal不會，但是要注意的是decimal的范圍是你自己設置的，在平時的使用中盡量准確去估計你要使用的大小，（暫時還沒有decimal不夠用的情況）
9、自增id就不說了，唯一性約束，主要是說明一下gmt_create和gmt_modified字段，一開始看，我懵逼了，這是啥，也沒說明是什么，后面想想一個是創建時間，一個是修改時間，gmt是格林尼治標准時間….好吧，我也有點醉醉的。個人認為是這樣的，首先添加時間對於很多來說是需要的，對於很多業務來說很重要，而修改時間是為了后期萬一出現問題反查數據檢錯用的。目前修改時間在我的項目中用的並不多，添加時間倒是幾乎都有，之后會考慮加入修改時間，但是並非強制。
12、數據庫不寫注釋的人，一抓一大把，真的是，每次去維護一個舊的項目，就會發現不寫數據庫注釋的，你不寫數據庫注釋對於別人來說，那么對於字段名表名將一臉懵逼。所以要養成良好的習慣，注釋並非只有在代碼中寫的。
索引規約
千萬不要忽視索引的重要性，一個數據庫有沒有索引查詢的效率是非常不一樣的，因為很多時候我們剛開始學習數據庫的時候，可能索引只存在於課本或者視頻，實際中感覺好像沒用，其實主要原因是數據量小的時候你根本感覺不出沒有索引的查詢時有多么的慢，所以索引的重要性就要注意咯。
2、join，表連接是非常影響性能的，我曾經看到，一個設計非常不好的數據庫交到一個程序員手里，結果這個程序員是個真碼農，寫了一個11張表連接的查詢，結果可想而知，連在不大的數據情況下，打開頁面都要1分鍾。所以盡可能的連的少。
4、有人可能奇怪這一條，為什么左模糊或者全模糊都不行，那么右模糊是否可以呢？右模糊可以使用，為什么別的不行呢？因為別的效率真的很低，左模糊和全模糊的查詢效率在數據量大的時候很慢，比右模糊要慢的多。
$sql1 = "...... title like someTitle%" (花費0.001秒)
$sql2 = "...... title like %someTitle%" (花費0.8秒)
7、總結一句話，在寫sql的時候，盡可能的先將容易被篩選的條件和那些可以去除掉很多不需要數據的條件先寫（也就是第九條也提到的），使查詢加快。延遲關聯是也就是指，先加條件查詢掉那些條件之后再去關聯別的表去查詢全部的數據，而不是關聯之后再去查。
8、這條要求可能就比較嚴格了，作為我來說，暫時還沒有那么數據量大的級別的項目需要進行所有的sql的優化，我只是對於那些訪問量極高的，一個項目里面也就那么幾個極其重要的sql進行特定的優化，主要也是優化查詢的性能。對於sql性能優化來說，這種事情還是需要專業的DBA的，畢竟人家是吃這碗飯的，自己想到優化的點還是太少，網上有很多sql優化的講述，我這里就不多說了。
SQL規約
3、sum還有max等函數，當使用這些函數進行查詢的時候一定要注意，返回的可能是null，不過我的做法和手冊給出的不同，因為在我的想法中數據庫盡量是不能放邏輯代碼的（后面我也會說到），當遇到這種情況時，我會使用包裝類來接受數據庫返回的結果，因為普通的int是不能為null的，因為是基本類型，而包裝類Integer是可以為null，然后你只需要對這個對象進行判空即可，這樣邏輯就存在於java代碼中了。
6、很多學生，特別是學生，經常有疑問的就是，我在學校里面學習數據庫的時候，老師常常交我們外鍵是什么，表里面外鍵是哪個，但是開發中從來不會有人跟你說外鍵，為什么？原因就在這里，外鍵造成的影響，首先是使表的情況你不可控，有時你完全不知道數據變化會導致怎么樣的結果，還有就是影響數據庫的性能，數據庫每次都要管理你的外鍵，每次的插入還要去判斷外鍵，等等，很多性能都浪費了，很多的約束和保證都已經由索引來完成了。
7、我並不是非常認同這個觀點，至少我認為並發強制，原因是這樣的，存儲過程確實需要面對各種各樣的問題，但是並不能一棒子打死，在某些特殊的地方，舉個極端的例子，如果要運行的是1M的sql，而網絡帶寬還特別差，還要求你運行速度高，這樣的情況下就可以使用存儲過程，因為存儲過程的sql是存放在服務器上面的，不需要通過網絡進行傳輸，在網速很差的情況下也能有很高的速度，雖然這個例子可能有點極端，但是我想說明的就是這樣一個意思，即使我到現在為止只用過一次，但是並不能說永遠都不使用了。
10、表情使用utfmb4
ORM規約
1、只有懶惰的像豬的程序員才用select *
8、修改你需要的字段，不要的字段不要去修改
9、不要在類上面寫@Transactional，我見過很多人偷懶，直接在類上面寫@Transactional，這樣導致這個類的每一個方法都采用了事務，但是實際上，很多時候是不需要事務的。
需要使用事務的情況：一、多次修改不同的數據。二、多次刪除不同的數據。三、多種操作間存在關聯性，前面操作失敗會直接導致后面出現問題，且前面的操作不回滾會出現臟數據的情況。
事務是很影響執行時間的，所以要慎用，也要用的好。
總結和補充
這里還有幾點需要補充的，這里沒有提出觸發器的問題，這個也是很多人問過我的，我的回答是，觸發器不到萬不得已不要使用，因為這東西和外鍵是一樣一樣的，很多時候都是會讓你不可控制，而且維護起來非常難。還有就是數據庫一定要備份。有bug不怕，一旦數據出問題，而且數據庫恢復不出來的話，那就神也救不回來了。新聞也報道過很多次數據庫的意外，特別是游戲的。
總之對於數據庫，我們要學習的還有很多。我覺得手冊的總結也是對於開發來說的，對於DBA可能要求比這個要多的多。所以如果你是DBA的話可能要了解的更加深入才行哦。