在千萬級別的資料表中以乙個無索引的列作為查詢條件，結果可想而知，大部分情況下肯定是非常耗時。這無疑造成的結果就是，這樣的慢sql查詢，輕則只是影響使用它的介面，重則在使用者請求量大的情況下佔滿我們的資料庫資源，造成生產環境業務的不能操作。所以對於大資料量的查詢，我們需要建立適合的索引來優化查詢。
一般情況下，我們都會根據業務需求以及結合經驗給相應的列建立合適的索引，大部分情況下都會滿足我們目前的需求。然而隨著業務的發展以及資料量的增長，我們即便看似都盡量使用到了有索引的列作為查詢條件，但是最後sql的查詢效能還是不理想。原因可能我們還是不夠了解執行乙個sq所要經歷的過程，這導致我們忽略了或者沒有想到還有其他的解決方案。這個時候我們不妨換個思路，先分析這個sql的執行計畫以及執行過程中資源的使用的情況，比如：
結合這以上兩種方式，具體分析我們的sql耗時在**，然後對症下藥重新編寫我們的sql；其中我們最意想不到的就是，在乙個sql中合理地利用乙個子查詢可以達到我們意向不到結果。下面是我在改造報名單中涉及「扁鵲簡訊需求」的功能時，乙個分組統計sql做了子查詢和沒有子查詢的查詢耗時情況對比，如下圖所示：
以上資料，我是在生產環境的查詢庫進行試驗的，真實性可靠。無子查詢的sql的耗時受外界因素影響比較大，可能當時網路頻寬好，那麼耗時比較低，但是大部分情況下耗時長是居多。而有子查詢的sql整體耗時趨於穩定，查詢耗時也是遠低於無子查詢sql的耗時。由此可見合理的子查詢可以幫助我們的sql效能提高乙個量級，其實最根本的原因還是充分利用了主鍵索引的效果。因此利用子查詢優化sql正好解決了我改造「扁鵲簡訊需求」而走es不支援深度查詢，走bd耗時長的困擾。
目前暫定這個方案，因為儘管利用子查詢減少了不少時間，但是對於乙個sql的執行時間來說，耗時還是太長了，已經是個慢sql了。但是選擇深夜去執行，而且每天執行一次，那麼結果應該還是可接受的。
SQL優化 使用關聯查詢代替子查詢
sql優化 使用關聯查詢代替子查詢 測試例子 子查詢 selecta.select workflowname from workflowbase whereid workflowid workflowname from zping.com a where a.operator 402882ed111...
查詢優化 SQL優化
查詢優化注意點 代表查詢速度比較 1 所有查詢必須注意 的使用必要性 cout 1 cout 2 字段 主鍵索引 字段 普通索引 字段 沒有索引 3 乙個字段 多個字段 欄位多越慢 4 大於10000和大於10001的區別 後者大於前者 5 列沒別名 列 有別名6 兩個條件，where時應該將符合資...
SQL優化 秒級優化，hint讓IN子查詢當驅動表
python大資料與sql優化筆 qq群 771686295 在sql優化中，乙個比較重要的一點就是驅動表的選擇，hash join和nest loop來說驅動表的選擇是至關重要的。對於nest loop說最好是小表作為驅動表，與大表的連線鍵上減少索引，並且保證索引的選擇性比較好。對於hash jo...