可能對於大多數人對於超長的sql優化，可能看sql去理解邏輯都要花很長時間，尤其在幫別人優化的過程中，在不理解業務的情況下更是無從下手，其實對於超長sql的優化，其實並沒有想象中的那麼難，對於那些超長sql，我們只需要明白，其中有特殊的操作，比如在sql中有沒有檢視，有沒有子查詢，有沒有標量查詢，這些都是一些要考慮的問題，這只是觀察，並不需要我們去理解真正sql想表達的含義。當我們看完sql以後，接下來是去分析執行計畫，通過我們觀察的sql我們，可以想象到在執行計畫中，如果有檢視在執行計畫中會發生什麼，如果有只查詢在執行計畫中回發生什麼，這些都是要能夠想象到的。然後再根據返回的行數來確認，巢狀迴圈是否能用，考慮到這這麼多因素以後，我認為優化長sql就不會那麼難了。
今天跟大家分享乙個超長sql，但是具體內容我本能貼出來，我只能貼部分執行計畫。sql的大概是兩個表做hash，即id=2 和id=10 做關聯。id=10為乙個檢視
從執行計畫可以看出，所以的時間都是花在id=10的檢視中，而且id=1的檢視最終返回一行結果，這個明顯的可以讓他走巢狀迴圈嘛，其實可以走巢狀迴圈為什麼oracle沒有選擇走呢，按常規來說oracle在於檢視做關聯的時候缺省會把謂詞推入的，但是在這裡沒有。這裡可能有兩個原因乙個id=10檢視的原因，乙個是謂詞推入的開關關掉了。在檢視設定以後是開關關掉了，開啟開關了20s就把這個sql給跑完了。所以sql也就有話了。
sql2005還原超長sql指令碼，還原超大指令碼檔案
從外網把資料庫用匯出指令碼的方式匯出來了，280m的樣子，導是匯出來了，但是在本機執行sql指令碼的時候，直接就是out of memory，之前執行60m的指令碼沒出過這問題，直接雙擊開啟.sql指令碼檔案，然後執行就完了，現在主要是這檔案太大了，280m，就報錯了，後面不停的google，終於找...
sql2005還原超長sql指令碼，還原超大指令碼檔案
原文 sql2005還原超長sql指令碼，還原超大指令碼檔案 從外網把資料庫用匯出指令碼的方式匯出來了，280m的樣子，導是匯出來了，但是在本機執行sql指令碼的時候，直接就是out of memory，之前執行60m的指令碼沒出過這問題，直接雙擊開啟.sql指令碼檔案，然後執行就完了，現在主要是這...
談談自己對sql優化的理解
合理的使用快取來減少對資料庫的查詢。如利用mybatis的一級快取，來減少相同sql的查詢。不使用select from 得查詢，加大資料庫的壓力，使用什麼字段，返回什麼字段。避免使用not in 或 不等於的查詢，因為會查詢全表。我們自己寫的sql很清楚知道，返回的資料有多少。當我們只需要有乙個結...