最近寫了乙個查詢語句，為了做這個查詢建立了一些view，最終的view中包含了另外兩個view。這個sql的查詢要傳入乙個條件語句，最後發現這個sql語句會隨著資料量的增加而越來越耗時。即使為所有可以建立索引的地方都已經建立了索引也沒有用。
用explain解釋之後發現這個語句在執行其中的子查詢時是查詢了全表的。也就是說條件語句的傳入不會影響到子查詢，子查詢並不會去使用索引。直接使用普通的sql查詢，條件傳入到子查詢中，這時子查詢就使用了索引，速度明顯快了很多，最後執行這個sql只需要200ms左右，而且不會根據資料量的增加而增加。因為沒有必要使用view了，所以也就不用寫這麼複雜的sql了，於是就把這個sql**，這樣可以快的更多。
本來用view是想用hibernate的時候可以方便，不過看來view沒有那麼靈活，只能改用native sql了。這個時候也許使用mybatis就好的多了，或者自己寫個動態sql生成的程式。
sql優化的一些想法
1. 資料量大的話，能建索引的地方盡量建索引
2. 除了建立索引之外還要看索引有沒有用到，這個時候可能就要通過sql語句分析，explain之類的工具了
3. 除了用索引之外還有什麼能提高sql效能的地方，目前看到的只有想辦法給sql**了，或者優化表結構，盡量少的join太多的表
記一次簡單的sql優化
統計報警點位所屬裝置的裝置報警總數top100的裝置的報警總數 需要先找出所有裝置的報警次數，按照報警次數進行排序，取前100，然後再對前100的裝置的報警次數進行統計 將報警次數top100的裝置找出來，再對整個資料進行乙個inner join，再疊加乙個count。可以計算出 select co...
一次Sql語句的優化實戰之旅
資料量很大,優化前差不多2分鐘,優化後1s.低效sql select col1,col2,col3 from table where id in 1,2,3,4,5 高效sql select col1,col2,col3 from table where id 1 union allselect c...
記一次SQL優化
問題發生在關聯主表a 4w資料量 和副表b 4w資料量 關聯欄位都是openid 當時用的是 left join 直接跑sql，卡死 伺服器也是差 優化1 改left join 為join，兩者區別就是left join查詢時已主表為依據，該是幾條就幾條 就算副表沒有關聯的資料 join如果副表沒有...