DBA SQL Review

DBA SQL Review

Schema  REview的注意事項

SQL review的注意事項

線上Schema 分析優化技巧

DBA Review 工作内容

表字段、索引設計優化

字段類型（針對業務、故障等類型去确定字段）

注釋标準度

分區表限制

SQL編寫規範

DML編寫規範

子查詢限制

函數使用

優化的目的：

為開發人員提出更高的建議

Schema  REview的目标

功能實作為主

保證節省資源

平衡業務技術各個方面，做好取舍

讓資料庫幹自身擅長的工作

不在在DB裡進行操作

減少複雜操作

字段數量

建議不超過20-50個

做好資料評估

 建議純int不超過1000萬，含有char的不要超過800萬

 非核心表另議

可以考慮反範式設計

适合的備援設計，減少join

核心表盡可能精簡

日志表可進行水準分表

注意引擎差別 Innodb & Tokudb

Tokudb  減少update操作  （更新資料 表會變得很大）

字段設計

主鍵 innodb表是以主鍵排序存儲IOT盡量使用短，自增的列做索引，複制結構中row

格式中，如果表有主鍵可以加速複制。

INT 無符号自增列  可以考慮BIG int

可用uuid_short()代替uuid 轉成bigint 存儲

注意潛在風險

tinyint 做大表主鍵可能導緻mysql  crashed

類型轉型導緻查詢效率很低

mysql在開發上面的特點

（1）每個query 隻能用到一個core（處理層）

（2）沒有執行的緩存

（3）mysql預設情況下，随着連接配接數的增加。性能會下降   (基于連接配接數的壓力測試)

（4）校驗式嵌套處理  沒有hashjoin

在主從複制結構中從庫對主鍵的選擇

（1）會選擇主鍵

（2）會選擇有效的索引

（3）全表掃描

針對高速寫入的環境的主鍵設計

字元集問題

Emoji表情 表示用utf8mb4

将字元轉數字存儲

利用int 存儲ip 而非char(15)

INET_ATON() &INET_NTOA()

将日期轉換成數字

from_unixtime()

unix_timestamp()

null與 not null有什麼坑？

C1 vchar(16)default null    不建議

C1 vchar(16)default not  null   不建議

C1 vchar(16)default not null default ''  建議  

schema  Review

工具：

利用pt-mysql-summar 指定DB分析

利用pt-duplicate-key-checker 指定DB 檢視重複索引、重複主鍵 官方手冊

功能環境記錄全量慢日志用于分析

SQL Review注意事項

SQL Review 總則

避免線上系統出現大操作

全面使用索引

優化join

去除無意義邏輯

注重檢視where條件

除了select 語句，沒有where條件的可以直接去掉

where條件字段 差別度高字段，注意建索引

like不要出現以%開頭的查詢

對于出現子查詢的sql，要确定上線的mysql版本，利用explain确認

避免使用sslect *,fa友善調整字段清單，還可以減少不必要的I/O

insert 要對字段寫入

整個SQL要用explain确認

去除無意義的操作

很多SQL是生成的。如ibatis,Hibernate 生成的類的SQL

其他架構生成的SQL

複雜類的SQL中無意義邏輯去除

不必要的括号也可以去除

控制最多三層join建議2個以下

小表驅動大表

字典 常用表 其他表排序

控制join後面where條件選擇的的行數，盡量在1000行以下

使用union all 代替union

減少臨時表出現

避免線上大的操作

分批多次操作

大事務拆分成多個事務區分間操作

頻繁的查詢考慮适當的緩存

對于text,blob字段。适當進行拆分

本文轉自 tianya1993 51CTO部落格，原文連結：http://blog.51cto.com/dreamlinux/1840749，如需轉載請自行聯系原作者