如題，近期做新作乙個專案，有個cr是讓對sql語句進行優化，提高執行效率。
具體的sql這裡就不寫了，因為不是本文要寫的重點。這裡用select * from dual來代替《這裡認為是sql1》。
本以為是對這個sql進行優化就可以了，但是經過了兩天修改，一無所獲。
後來無奈只能請教同事，才發現問題並不在此。
因為在這句sql執行過後，下面的**間接的使用了sql1執行的結果集。
並且對這個結果集合中的某些字段重新查詢：
例如下面的sql就對結果集合中的invoicetype這個字段進行判斷，並使用了這個findsysparaname（）方法（這個方法裡面是乙個sql查詢《這裡可以認為是sql2》）得到結果，並重新寫入到第一條sql的結果集合中。
tmp[1]= !stringutils.isempty(obj.getinvoicetype()) ? obj.getinvoicetype()+" "+findnamefacadeimpl.findsysparaname("vd", "invoice_type", obj.getinvoicetype()) : "";
舉個例子：
select name from people;
select age from employee where name=name 那麼我們將兩個sql結合在一起：
select name ,age from people left join employee on employee .name=people.name 最終程式完成優化。
就將這麼多吧，其實就是一開始進入了乙個sql優化所帶來的乙個誤區。這裡就總結出乙個經驗教訓，以後如果出現很多自己沒有把握解決的問題，盡早的請教同事或者他人，從而不至於在誤區裡面徘徊不前。
mysql優化誤區 資料庫效能優化的誤區
常見的資料庫系統優化中的一些觀點 系統效能出現問題進行優化，一定要深入了解資料庫內部引數 等待事件 latch 緩衝池 trace檔案 查詢 優化引擎等底層細節。這種觀點往往出自資料庫 高手 這部分人以了解資料庫底層實現細節而感到非常驕傲。但是從優化角度講資料庫的等待事件 latch等指標高等等都只...
氣泡排序的優化與誤區
氣泡排序 bubble sort 是一種簡單的排序演算法。它重複地走訪過要排序的數列，一次比較兩個元素，如果他們的順序錯誤就把他們交換過來。走訪數列的工作是重複地進行直到沒有再需要交換，也就是說該數列已經排序完成。這個演算法的名字由來是因為越小的元素會經由交換慢慢 浮 到數列的頂端。氣泡排序演算法的...
SQL的一些誤區
資料庫 oracle11g無索引的情況下,一樣速度 有索引字段可以為空的情況下,count 列 更快 有索引欄位不可以為空的情況下,兩個一樣快 count 列 的時候,列的偏移量決定效能,列越靠後,訪問的開銷越大.由於count 的演算法與列的偏移量無關,所以count 最快,count 最後列最慢...