?不要過度設計，每個系統(tǒng)都會有些表的字段從來沒有值，可能是當時預留字段，但是現(xiàn)在看來，很多預留字段都是浪費的，建議還是真正需要時再添加不遲

?無論是做數(shù)據(jù)結構設計還是sql的編寫，都應該控制復雜度，復雜的sql會導致數(shù)據(jù)庫load的沖高，當PV上來時，系統(tǒng)響應變慢，然后系統(tǒng)請求堆積，嚴重的最后會導致整個系統(tǒng)完全無法提供服務，所以每個開發(fā)童鞋寫sql時需要優(yōu)先考慮性能問題，讓每條sql盡量簡單，都能走到對的索引，通過應用程序去解決復雜的sql邏輯查詢

?不要把所有數(shù)據(jù)都丟到數(shù)據(jù)庫，特別是數(shù)據(jù)量大的日志型數(shù)據(jù)可以通過日志輸出，通過elk／flume+storm等方式拉取到es中進行查詢跟蹤，如果硬是要保存到數(shù)據(jù)庫，那只需要保存異常數(shù)據(jù)即可。用戶行為數(shù)據(jù)可以發(fā)送消息出去，由其他應用來監(jiān)聽消息并且保存到Redis／MongDB中，比如登陸相關數(shù)據(jù)，投資行為等數(shù)據(jù)，如果這些數(shù)據(jù)需要用來做業(yè)務流控，如現(xiàn)在登錄次數(shù)等業(yè)務場景，可以使用redis的數(shù)據(jù)過期機制來實現(xiàn)

?不要給用戶太大的空間進行數(shù)據(jù)的輸入，盡量提供選擇框讓用戶選擇，防止臟數(shù)據(jù)的產(chǎn)生，關鍵字段要設置為必填，否則會給數(shù)據(jù)分析時的數(shù)據(jù)清洗帶來麻煩

?設計好表的UK，可以避免數(shù)據(jù)的重復，也可以給接口的冪等性提供支持

?對于數(shù)據(jù)量大的業(yè)務處理建議使用異步化的方式來實現(xiàn)，通過發(fā)送消息的方式進行數(shù)據(jù)分片，然后可以對數(shù)據(jù)進行分布式處理，提高數(shù)據(jù)處理速度

?對于大表，首先考慮數(shù)據(jù)庫的優(yōu)化，然后再考慮讀寫分離，是否可以做分區(qū)表，數(shù)據(jù)歸檔來提升性能，最后才去考慮進行分表分庫的設計，分表分庫無論對于系統(tǒng)本身的設計開發(fā)很難的把握，同時對于數(shù)據(jù)的使用者也是增加了復雜度

?對于緩存數(shù)據(jù)的使用，盡量不要緩存用戶唯度的數(shù)據(jù)，這種類型的數(shù)據(jù)不但給緩存服務器帶來壓力，更主要是緩存的命中率低，所以對于緩存的使用也是設計的關注點，不要因為某個緩存數(shù)據(jù)的暴增而拖垮整個緩存服務器

?隨著數(shù)據(jù)量的積累，有些數(shù)據(jù)過了其的生命周期，也就是說這些數(shù)據(jù)變成了冷數(shù)據(jù)，沒有系統(tǒng)需要再使用它了，那么我們就要定時的去做一些數(shù)據(jù)的歸檔，騰出數(shù)據(jù)庫資源給熱數(shù)據(jù)來使用

?涉及數(shù)據(jù)量大的更新，如某個表新增的非空字段等，建議分批進行更新。分批不但為了數(shù)據(jù)庫的穩(wěn)定，防止引起數(shù)據(jù)庫的死鎖，同時也防止ETL工具拉取大量的更新數(shù)據(jù)，因為很多報表需要依賴ETL同步完成數(shù)據(jù)，如果ETL同時超時的話，很多定時報表會運行失敗，有可能需要手工再次運行報表任務，所以進行大數(shù)據(jù)量更新時，一定要通知DBA和數(shù)據(jù)團隊進行跟蹤關注。

?監(jiān)控是最后的守護者，可以及時的發(fā)現(xiàn)系統(tǒng)的性能問題，對于數(shù)據(jù)庫來說，

?DBA可以通過數(shù)據(jù)庫的監(jiān)控工具來實時的對數(shù)據(jù)庫進行監(jiān)控，對于核心表的數(shù)據(jù)量增長趨勢，核心表相關的sql查詢性能都需要進行跟蹤。但是提前發(fā)現(xiàn)sql的性能問題，進行合適的預防則是開發(fā)團隊需要關注的。這就需要監(jiān)控中心對sql的運行時間和次數(shù)等指標進行跟蹤和匯總,如果當前沒有監(jiān)控中心，也可以使用DruidDatasource的statFilter功能進行跟蹤，開發(fā)團隊需要定時的去關注sql運行時間，運行次數(shù)等指標，隨著業(yè)務量的增長，之前高性能的sql可能會變慢，高頻sql絕對不能出現(xiàn)在long sql的列表中，需要及時改造。還有就是緩存服務器的監(jiān)控也是需要關注的。