事情的起因是，我們的一個項目經理需要對一個資料庫的信息進行查詢，SQL 人家都會寫的。（語句已經經過處理欄位名，和原有的語句不同）語句並不複雜， mysql 5.7.23
select c.APP,c.CON,c.ACT,c.term,
(select sum(AMORTIZEAMT)
from tb_amortize t1
where t1.CAM= c.CON and t1.SAP_PO_IND='F') 待攤銷,
(select sum(AMORTIZEAMT)
from tb_amortize t2
where t2.CA= c.CONTRACTNO and t2.SAP_PO_IND='T') 已攤銷
from tb_sync_contract c
where 1=1 and c.ACT>='2020-06-01' and c.ACT<='2020-06-30' ;
查詢計劃在下面，基本上半小時是沒法給出數據，主要的原因是一張表的數據量有點大；
我們對於這樣的表進行了SQL 查詢的改寫，但結果一般
1 方法，驅動表的位置的變換
我們將小的表放到了驅動表的位置，大表放到了下面
結果並沒有好轉
2 方法，嘗試通過再次減小驅動表的方式來加速查詢
select a.AP,a.CONTR,a.ACTIVEDATE,a.term,sum(b.AMORTIZEAMT) as 『以』
from (select APPL,CONTR,ACTI,term from tb_sync_ct foe index (idx_activedate) where ACTI>='2020-06-01' and ACTI<='2020-06-05') as a
inner join tb_am as b on a.CONTRA = b.CAMA and b.SAP_PO='T';
3 方法，將合同表的數據直接導入到新的表中，基本是不到4萬條數據，但和2000萬的表進行查詢，速度還是很慢
select a.APP,a.CONT,a.ACTIE,sum(b.AMOT) as 『以』
from tb_sync_con_s as a
inner join tb_amo as b on a.CONTRA = b.CAM
where b.SP_P='T';
常用的方法都不奏效的情況下，我們問了顧問邏輯，主要的邏輯其實就是將每個月的一堆的記錄（幾萬條），和另一個表的2000多萬的記錄進行一個計算，其中關係是 一對多的關係。
所以即使在有索引的情況下，將常用的方式方法都使用的情況下，對這樣的OLAP的操作 MYSQL 還是「肌無力」。
後面我們轉換了思路，MYSQL 本身在 JOIN 方面的性能差，但對於單條記錄的計算還是很快的，我們不行就通過中間表的方式，將合併的計算變為單條記錄，加 中間表 + 在次計算的方式來進行。
解決的方案也很簡單, 其實就是通過解耦和單獨輪休的方式,將問題解決,
主要是通過兩個中間表的方式,實際上也可以用一個中間表的方式來計算.
通過這個事情,其實可以很明顯的看出一個問題,為什麼MYSQL在網際網路企業用的風生水起,一到傳統企業,業務邏輯計算複雜的企業就玩不轉了.
1 MYSQL 本身的機理使然,這點就不重複的,業內都知道是怎麼回事
2 業務邏輯的問題
3 傳統企業缺乏 IT 方面的整合型的人才
大多數成熟的網際網路企業都有DEVOPS 這個工作的職位,DEVOPS 可不光是解決系統層級的問題, 業務方面的問題,如上數據方面的操作也是需要DEVOPS來完成的. 傳統型的企業原先基本上使用的是商業性的資料庫,所以這方面本來是沒有需求的, 但隨著MYSQL的大量使用, 分庫分表後的數據融合, 數據的聚合計算,等等也都充滿了需求, 所以傳統型企業如果想用好MYSQL DEVOPS的介入那是不可缺的存在.
如上的需求,可以做一個界面,將這些操作自動化化,需要的人員僅僅輸入相關的變量參數,就可以直接將結果獲得,可惜大多數傳統企業,在最初並不知道這些問題,可能會導致對MYSQL的誤解.
不過話說回來,DBA 不會PYTHON 估計在這年月也快說不過去了