sql優化方案:

1.添加索引,在條件參數,關聯參數上建立參數,

2.字段優化,需要什么字段查什么字段

3.模糊查詢盡量使用: select * from tableName a where a.name like ‘name%‘

避免使用 ‘%name%‘ 和 ‘%name‘;

3.利用explain 分析SQL

id

SELECT識別符。這是SELECT的查詢序列號

select_type

SELECT類型,可以為以下任何一種:

SIMPLE:簡單SELECT(不使用UNION或子查詢)

PRIMARY:最外面的SELECT

UNION:UNION中的第二個或后面的SELECT語句

DEPENDENT UNION:UNION中的第二個或后面的SELECT語句,取決于外面的查詢

UNION RESULT:UNION 的結果

SUBQUERY:子查詢中的第一個SELECT

DEPENDENT SUBQUERY:子查詢中的第一個SELECT,取決于外面的查詢

DERIVED:導出表的SELECT(FROM子句的子查詢)

table

輸出的行所引用的表

type

聯接類型。下面給出各種聯接類型,按照從最佳類型到最壞類型進行排序:

system:表僅有一行(=系統表)。這是const聯接類型的一個特例。

const:表最多有一個匹配行,它將在查詢開始時被讀取。因為僅有一行,在這行的列值可被優化器剩余部分認為是常數。const表很快,因為它們只讀取一次!

eq_ref:對于每個來自于前面的表的行組合,從該表中讀取一行。這可能是最好的聯接類型,除了const類型。

ref:對于每個來自于前面的表的行組合,所有有匹配索引值的行將從這張表中讀取。

ref_or_null:該聯接類型如同ref,但是添加了MySQL可以專門搜索包含NULL值的行。

index_merge:該聯接類型表示使用了索引合并優化方法。

unique_subquery:該類型替換了下面形式的IN子查詢的ref: value IN (SELECT primary_key FROM single_table WHERE some_expr) unique_subquery是一個索引查找函數,可以完全替換子查詢,效率更高。

index_subquery:該聯接類型類似于unique_subquery。可以替換IN子查詢,但只適合下列形式的子查詢中的非唯一索引: value IN (SELECT key_column FROM single_table WHERE some_expr)

range:只檢索給定范圍的行,使用一個索引來選擇行。

index:該聯接類型與ALL相同,除了只有索引樹被掃描。這通常比ALL快,因為索引文件通常比數據文件小。

ALL:對于每個來自于先前的表的行組合,進行完整的表掃描。

possible_keys

指出MySQL能使用哪個索引在該表中找到行

key

顯示MySQL實際決定使用的鍵(索引)。如果沒有選擇索引,鍵是NULL。

key_len

顯示MySQL決定使用的鍵長度。如果鍵是NULL,則長度為NULL。

ref

顯示使用哪個列或常數與key一起從表中選擇行。

rows

顯示MySQL認為它執行查詢時必須檢查的行數。多行之間的數據相乘可以估算要處理的行數。

filtered

顯示了通過條件過濾出的行數的百分比估計值。

Extra

該列包含MySQL解決查詢的詳細信息

Distinct:MySQL發現第1個匹配行后,停止為當前的行組合搜索更多的行。

Not exists:MySQL能夠對查詢進行LEFT JOIN優化,發現1個匹配LEFT JOIN標準的行后,不再為前面的的行組合在該表內檢查更多的行。

range checked for each record (index map: #):MySQL沒有發現好的可以使用的索引,但發現如果來自前面的表的列值已知,可能部分索引可以使用。

Using filesort:MySQL需要額外的一次傳遞,以找出如何按排序順序檢索行。

Using index:從只使用索引樹中的信息而不需要進一步搜索讀取實際的行來檢索表中的列信息。

Using temporary:為了解決查詢,MySQL需要創建一個臨時表來容納結果。

Using where:WHERE 子句用于限制哪一個行匹配下一個表或發送到客戶。

Using sort_union(...), Using union(...), Using intersect(...):這些函數說明如何為index_merge聯接類型合并索引掃描。

Using index for group-by:類似于訪問表的Using index方式,Using index for group-by表示MySQL發現了一個索引,可以用來查 詢GROUP BY或DISTINCT查詢的所有列,而不要額外搜索硬盤訪問實際的表。

4.經常增刪改的表建索引,也還是有問題的,解決辦法是刪除索引,重新建立索引!

案例:

select * from ( SELECT a.*, b. NAME AS owneridtypename,db. NAME AS logicdelstatusname FROM zc_bas_vehicle_owner a LEFT JOIN sys_dict b ON a.owneridtype = b. CODE AND b.pname = ‘idtype‘ AND b.pid != 0 LEFT JOIN sys_dict db ON a.logicdelstatus = db. CODE AND db.pid != 0 AND db.pname = ‘logicdelstatus‘) tab where 1=1

and id = #{ent.id }

and ownername = #{ent.ownername }

and ownerid = #{ent.ownerid }

and weixin = #{ent.weixin }

and logicdelstatus = #{ent.logicdelstatus }

治超項目數據查詢慢是多方面的:

1.SQL本身關聯了多張表

關聯了2次字典表

2.分頁SQL:

查詢兩次:

2.1 查詢分頁數據結果集查詢效率還可以

2.2 查詢總記錄數很慢

很慢的原因是查詢了所有數據然后再coun(1)

SQL: select count(1) from + ( 上面的SQL )+條件

優化方案1:

分開單表查詢,然后利用Java遍歷設置字典值

List> table_list = isBasVehicleOwnerMapper.table_list(page,ent);

List> dictList1 = publicMapper.getDictList(null, "idtype");

List> dictList2 = publicMapper.getDictList(null, "logicdelstatus");

for(Map map : table_list) {

map.put("owneridtypename", null);

map.put("logicdelstatusname", null);

for(Map map1: dictList1) {

if(String.valueOf(map.get("owneridtype")).equals(map1.get("code"))) {

map.put("owneridtypename", map1.get("name"));

break;

}

}

for(Map map2: dictList2) {

if(String.valueOf(map.get("logicdelstatus")).equals(map2.get("code"))) {

map.put("logicdelstatusname", map2.get("name"));

break;

}

}

}

優化方案2:

mybatis-plus 分頁插件不查詢總記錄數2.18版本(注意版本各個版本方法不一致)

page.setSearchCount(false);

自定義SQL查詢總記錄數設置

page.setTotal(total);

方案1和方案2實際對比:方案1只適合單表和字典表關聯查詢,多個表復雜查詢就不好操作了方案2查詢頁碼比較大的數據時候就很慢了,這個方案1沒有出現

總結

以上是生活随笔為你收集整理的mybatis与mysql调优_MySQL + mybatis的SQL优化方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。