總是在災難發生後，才想起容災的重要性。
總是在吃過虧後，才記得曾經有人提醒過。
一，核心軍規
不在數據庫做計算，cpu計算務必移至業務層控制單表數據量，單表記錄控制在千萬級控制列數量，字段數控制在20以內平衡範式與冗餘，為提高效率可以犧牲範式設計，冗餘數據拒絕3B(big)，大sql，大事務，大批量二，字段類軍規
用好數值類型tinyint(1Byte)smallint(2Byte)mediumint(3Byte)int(4Byte)bigint(8Byte)bad case：int(1)/int(11)有些字符轉化為數字用int而不是char(15)存儲ip優先使用enum或set例如：`sex` enum (‘F’, ‘M’)避免使用NULL字段NULL字段很難查詢優化NULL字段的索引需要額外空間NULL字段的複合索引無效bad case：`name` char(32) default null`age` int not nullgood case：`age` int not null default 0不在數據庫裡存圖片三，索引類軍規
謹慎合理使用索引改善查詢、減慢更新索引一定不是越多越好（能不加就不加，要加的一定得加）覆蓋記錄條數過多不適合建索引，例如“性別”字符字段必須建前綴索引不在索引做列運算bad case：select id where age +1 = 10;innodb主鍵合理使用自增列主鍵建立聚簇索引主鍵不應該被修改字符串不應該做主鍵如果不指定主鍵，innodb會使用唯一且非空值索引代替不用外鍵，請由程序保證約束四，sql類軍規
sql語句儘可能簡單一條sql只能在一個cpu運算大語句拆小語句，減少鎖時間一條大sql可以堵死整個庫簡單的事務事務時間儘可能短bad case：上傳圖片事務避免使用觸發器，用戶自定義函數，請由程序取而代之不用select *消耗cpu，io，內存，帶寬這種程序不具有擴展性OR改寫為IN()OR改寫為UNION畫外音：最新的mysql內核已經進行了相關優化
limit高效分頁limit越大，效率越低select id from t limit 10000, 10;應該改為 =>select id from t where id > 10000 limit 10;使用union all替代union，union有去重開銷儘量不用連接join務必請使用“同類型”進行比較，否則可能全表掃面打散批量更新使用新能分析工具show profile;mysqlsla;mysqldumpslow;explain;show slow log;show processlist;show query_response_time(percona)