一、對於運算邏輯，儘可能將要統計的各專案整合在一個查詢語句中計算，而不是用分組條件或分專案呼叫多個查詢語句，而後在程式碼裡計算結果。

二、查詢語句的優化，諸如不用"select *"、多表關聯查詢時新增別名於查詢欄位上、避免使用in、not in關鍵字、非去除重複時用union all替換union、先過濾後分組、排序等等。

三、在無法更改資料結構、不影響其它業務操作情況下，為查詢、統計項建立索引，這裡有一段關於建立索引的話：

建立索引的原則總結如下：(來自：http://club.topsage.com/thread-1584965-1-1.html)
    首先要判斷表的儲存資料量大小、高效能的操作要求（是頻繁增刪改操作還是頻繁的查詢操作）。對於要求頻繁增刪改操作的表，建立索引可能只會起到反作用。
  1． 對於只有幾十、幾百條記錄的表，建立索引的效果可能還不如逐行掃描來得快
  2． 對於只有幾個可能值的欄位，最常見的如性別等欄位，建立索引是無意義的
  3． 對於在查詢語句的WHERE子句中頻繁出現的欄位可以建立索引，但注意如果索引欄位上存在函式，該索引失效。如:WHERE SUBSTR(NAME,1)=’N’;NAME欄位上的索引不會起作用，改寫成WHERE NAME LIKE ‘N%’, NAME欄位上的索引才能生效。另外IS NULL和IS NOT NULL也會使索引失效
  4． 適量的冗餘欄位可以減小查詢的開銷，雖然這樣做不符合資料庫正規化的要求
  5． 建立在大資料型別欄位上的索引沒有意義，比如SQLSERVER的IMAGE,ORACLE的LOB

四、儘可能增大分配給資料庫伺服器的記憶體，sql語句的運算都是在記憶體中完成的，如果分配的記憶體過小，對於大量資料的運算雖不會導致記憶體溢位，但是運算速度會非常的慢。

-------------------------------------------------------------------------------------------------------------------------

    1:索引，我們最先想到的就是建立索引，建立索引可以成倍的提升查詢的效率，節省時間。但是如果資料量太過於巨大的時候，這個時候單純的建立索引是無濟於事的，我們知道假如特別是在大資料量中統計查詢，就拿1000W資料來說吧，如果使用count函式的話，最少要50-100秒以上，當然如果你的

　　單純的建立索引是無濟於事的。我們可以在建立索引的時候給索引加個屬性，compress,這個屬性可以將所建立的索引進行一個良好的歸類，這樣的話，查詢速度會提升5-10倍，或者更高。但是唯一的缺點是，壓縮索引只能手動建立，對於那些KEY是無法進行壓縮的，因為KEY（主鍵）是自動建立的索引，compress必選的屬性，一般預設是不建立。所以在建立壓縮索引的時候，可以找其他的關鍵欄位進行壓縮，比如工單表裡面的流水號

　　2:儘量少的使用那些函式，比如 IS NUll;IS NOT NULL,IN;NOT IN等這樣的匹配函式，可以使用符號程式進行操作

　　3:儘量少使用子查詢，如果你寫個類，裡面模仿子查詢的效果，你就會發現，簡直在要命，我們可以使用聯合查詢，或者是外連線查詢，這樣速度會比子查詢快很多。

　　4:在使用索引的時候，注意如下：

　　Where子句中有"!="將使索引失效

　　select account_name from test where amount != 0  （不使用）

　　select account_name from test where amount > 0  （使用）

　　Where條件中對欄位增加處理函式將不使用該列的索引

　　select * from emp where to_char（hire_date,'yyyymmdd'）='20080411' （不使用）

　　select * from emp where hire_date = to_char（'20080411','yyyymmdd'） （使用）

　　避免在索引列上使用IS NULL和 IS NOT NULL

　　select * from emp where dept_code is not null  （不使用）

　　select * from emp where dept_code > 0  （使用）

　　萬用字元% 的使用

　　select * from emp where name like '%A'  （不使用索引）

　　select * from emp where name like 'A%'  （使用索引）

---------------------------------------------------------------------------------------

    http://www.2cto.com/database/201411/348519.html

(1).優化索引

通過新增索引後，查詢的效率得到極大的提升，常用查詢的查詢時間從原來的幾十秒下降到幾秒。

建立以下兩個單列索引

ALTERTABLE population , ADD INDEX fk_city(city)  ,ADD INDEX fk_birthday(birthday);

也可以建立以下兩個組合索引

建立組合索引

ALTERTABLE  population  ADD INDEX fk_index1(city,birthday),ADD INDEX fk_index2(birthday,city);

(2).使用中間表
     雖然索引優化可以將查詢時間大大減少，但如果資料量達到一定量時，有些情況下索引到的資料達到幾百萬時，查詢仍然會很慢，因此索引優化 無法從根本上解決問題。現在表中的資料量越來越大，平均每個月要增加一兩百萬的資料，索引的優化方法只是暫時的，只能解決小資料量的查詢問題，隨著資料量的快速增長，索引帶來的效能優化很容易達到極限，要尋找其他的解決方案。

 我們根據業務需求的特點，建立中間表population_statistics，將表population中的統計資料存放到中間表population_statistics中，查詢時 直接從中間表population_statistics中查詢。注意，在對錶population進行增、刪、改時，必須同時更新population_statistics中的資料，否則會出現資料不一致的錯誤！

-------------------------------------------------------------------------------

主表A 20多W條資料，內連線了檢視B兩次，檢視B有20多W條資料，然後又左連線了一個40多W條資料的表，總的查詢再group by了一下，被by的欄位有十幾個，select中有一些欄位做了一些sum計算，還select了一些其它欄位，where有一些動態生成的查詢條件，對應一個搜尋頁面，搜尋條件根據使用者選擇生成，我做索引前查詢需要5分鐘，做了之後也要100多秒，原來所有的查詢是寫在一個儲存過程來呼叫的，動態生成的查詢條件也寫在過程裡，呼叫一個大檢視來查詢我前面講的這些，我把查詢條件直接寫到視圖裡的話，可以縮短到50多秒，看來還是寫進去比較好啊，但再也沒辦法再縮短了，要命的是，查詢條件還有一些是數值比較的，是通過一些欄位的計算再與其比較的，如果在where後面寫一些欄位的運算再比較，無疑效率很低，也用不上索引，有沒有比較好的辦法再優化一下。