系統中要求對HIS數據進行效益統計，因為HIS數據是需要第三方提供接口導入的，不清楚數據量大小，所以視圖以業務為主未對其做性能優化（當時編寫試圖時就是幾條簡單的測試數據）
如今在項目接口實施完成后查看視圖執行效率，發現執行了很久很久，具體執行時間忘記了，書寫不規范，性能兩行淚
（HIS系統就提供了近三千萬條數據）
發現不僅僅浪費了大量時間，還占用了大量內存空間
我首先就是想到了建索引，速度上快了些
然后查看視圖代碼，縮減代碼量及關注執行時間
因為視圖業務較復雜，涉及的表較多
首先對嵌套查詢的語句單獨測試，並優化
eg. 將一個原本用left join連接的操作進行優化（這幾張表數據量很小，最多的四萬條，最小的幾百條）
很普通的左外鏈接，看一下現在的性能，如此簡單的表連接加上了計算列后耗費了三十多秒😂，這個不能忍
主要開銷集中在計算上
而且注意看這個箭頭很粗，表明數據量很大，在這里產生了四千四百萬的數據，占用了1.7GB空間，對內存的消耗挺嚴重的
根據以上的結果，對於這段SQL，有兩點可以優化
1、消除左外鏈接
2、計算列計算之前盡可能減少數據量
准備優化
我們先看看內連接和左外鏈接的定義
內連接：內聯接使用比較運算符根據每個表共有的列的值匹配兩個表中的行。例如，檢索 students和courses表中學生標識號相同的所有行。
左外聯接：左外聯接的結果集包括 LEFT OUTER子句中指定的左表的所有行，而不僅僅是聯接列所匹配的行。如果左表的某行在右表中沒有匹配行，則在相關聯的結果集行中右表的所有選擇列表列均為空值。
從定義來看內連接的效率要高一些，所以要盡可能的消除左外鏈接
select子句中包含了很多計算列，這讓CPU開銷不小，所以我打算分開計算列，來達到計算時數據量較小的可能，代碼優化后如下
優化后執行速度😱，被驚訝到了
瞬間有動力繼續優化了，雖然剛才優化的是最簡單的一部分，如圖🙃
