總是在災難發生後，才想起容災的重要性。
總是在吃過虧後，才記得曾經有人提醒過。
一，核心軍規
- 不在數據庫做計算，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 null
- good 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)
分享到:
閱讀更多 架構師的修煉之路 的文章
