SQL最佳化：

標籤：索引   temp   nes   app   時間   尋找   select   nbsp   計算   

今日給人尋找資料，時間關係，寫個比較粗暴的SQL語句：

 

#2s587ms
#直接將所有表關聯，比較粗暴

select go.businessId,dd.dict_namefrom fn_xte.gte_order go,fn_config.t_dictionary_type dt,fn_config.t_dictionary_dict dd

where go.appId = dt.app_id and dt.data_key = dd.dict_type and dict_code = go.xingZhenQuYu and dt.data_key_name = ‘XING_ZHENG_QU_YU‘ 

此條語句對三個表進行關聯，遞迴層次較深，產生的計算量就會很大，平均為X^3層級。然後根據where語句對關聯的結果集進行篩選。耗時操作主要是在from子句中的三個表的聯合操作。

所以用子查詢對其進行最佳化為：

#487ms
#首先fn_xte.gte_order,fn_config.t_dictionary_type進行聯合，fn_config.t_dictionary_type在後，作為驅動表，根據app_Id,在fn_xte.gte_orde進行查詢，利用索引
select temp.businessId,dd.dict_name
from fn_config.t_dictionary_dict dd,(select go.businessId,go.xingZhenQuYu,dt.data_key
  from fn_xte.gte_order go,fn_config.t_dictionary_type dt
     where dt.app_id = go.appId and dt.data_key_name = ‘XING_ZHENG_QU_YU‘) as temp
where dd.dict_type = temp.data_key and dd.dict_code = temp.xingZhenQuYu; 

 

進一步最佳化是關於from，where子句的執行順序的，這裡尚有疑問，待論證：

#405ms
#首先是fn_config.t_dictionary_type dt,fn_xte.gte_order go的聯合，fn_xte.gte_order go在後作為驅動，其欄位appId有索引，此處我認為索引並未有作用
#因為是根據appId查詢其他表的，然而結果卻表明時間消耗少了，
#可能原因是，表fn_config.t_dictionary_type由於資料太少，沖淡了fn_xte.gte_order索引帶來的好處
explain select temp.businessId,dd.dict_name
from (select go.businessId,go.xingZhenQuYu,dt.data_key
 from fn_config.t_dictionary_type dt,fn_xte.gte_order go
      where dt.data_key_name = ‘XING_ZHENG_QU_YU‘ and dt.app_id = go.appId) as temp,fn_config.t_dictionary_dict dd
where dd.dict_code = temp.xingZhenQuYu and dd.dict_type = temp.data_key;

 

SQL最佳化：