1.SQL走查

1.1.規範樣例

1.1.1.建索引一級bug

由各個小組先統計可能需要的索引列，然後討論統一新增索引

1.1.2.模糊匹配 一級bug

模糊匹配(like) ，不允許關鍵字前面模糊，特殊情況除外，定義如下原則：

l列表總資料量 在1萬 以內的 模糊查詢 可以支援 前後模糊匹配

l列表總資料量 大於1萬的，最多關鍵字在前面精確匹配，右邊模糊匹配

l單號查詢，走精確匹配

1.1.3.SQL類似子查詢邏輯 一級bug

建議抽離到java中單獨去查詢

子查詢列表集合非常大的，建議採用 exists查詢

1.1.4.多餘的查詢 一級bug

優化建議：SELECT COUNT(DISTINCT sku) FROM t_im_bill_asn_dtl WHERE asn_no = '123' AND real_a_qty > 0

原因：distinct底層也是採用 groupby, 因它不需要排序，所以採用的是鬆散索引掃描，掃描索引鍵的一部分

group by, 因要排序，所以掃描整個索引鍵

結論：同等條件下 distinct效率高些。當 disctinct無法實現時，採用group by.

1.1.5.Select * 一級bug

1.1.6.Join表數量大於3張表 一級bug

如果預測資料量大的時候，建議拆開處理(目前兩年時間來料+銷退 預計18萬資料)

1.1.7.用於統計時，Groupby 多欄位(超過3個)一級bug

Groupby 多欄位 除了分組排序以外，如果是統計資料 用了groupby 多個欄位，需要優化。

1.1.8.SQL where條件 儘量不用使用函式處理

Ø1.1.2事例中，採用了replace函式,對入參進行函式操作屬二級bug，建議將此操作放入java層面進行處理

Ø採用函式對錶中欄位進行操作後，再進行邏輯比較，屬一級bug，必須避免

1.1.9.SQL where條件硬編碼 二級bug

所有業務欄位查詢條件，建議都通過引數傳遞，而不是硬編碼寫死(魔法值)

1.1.10.Mapper.xml 二級bug

Mapper.xml配置sql檔案中，儘量採用標籤配置，例如 <where>

1.1.11.Select裡面採用類似concat函式 二級bug

建議將這的操作 放到java應用程式進行處理

1.1.12.可列舉的查詢欄位，建議放到條件最後 二級bug