【轉】使用MySQL處理百萬級以上數據時,不得不知道的幾個常識


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

   前言部分

   今天在公司做項目的時候,需要對涉及到幾百萬條數據的數據庫進行查詢,用最簡單的邏輯寫了一遍代碼,結果出來的結果不盡人意,查詢所有數據【幾百萬條應該是有了】,顯示到頁面大概450條數據的時候,用來差不多20多秒鍾,真的是太讓人抓狂了,不過暫時也沒有想出更好的業務邏輯代碼出來,下午處理的數據庫部分是將用戶分成了若干個表,按照時間分表了,比如一個用戶user201801,其余的表就是user201802,user201803,user201804,每一個表都有可能是一張大表,這樣子,下午遇到的需求問題是要查詢出某個時間段的滿足條件的用戶數目,很簡單清晰的一個需求問題,看起來好像沒什么問題,不過需要針對所有已經划分好月份的用戶表進行聯合查詢,期間涉及到的一些時間判斷邏輯寫起來還是要費一點時間的,不知道有沒有比較快捷方便的方法,可以很高效率的查詢出所有符合條件的所有數據呢,以后再慢慢琢磨一下了,今天基本的功能是實現了,就是效率感人啊。另外開發的時候,利用表名字也優化了部分代碼邏輯,雖然是以后多加進去一個表,就需要多加入一部分代碼進去,但是代碼邏輯還是很清晰的。不過還是做不到零注釋的地步。

   這是前言,然后去網上搜羅了一些處理百萬級數據的關於mysql的注意事項,感覺還挺有用的,就先轉載過來保存着,

   日后或許用的上。要是可以找到誰收集好所有處理大數據的數據庫優化資料就好了。不然還得自己慢慢積累了。

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

    經測試對一個包含400多萬條記錄的表執行一條件查詢,其查詢時間竟然高達40幾秒,相信這么高的查詢延時,

    任何用戶都會抓狂。因此如何提高sql語句查詢效率,顯得十分重要。以下是結合網上流傳比較廣泛的幾個查詢語句優化方法:

    首先,數據量大的時候,應盡量避免全表掃描,應考慮在 where及 order by 涉及的列上建立索引,建索引可以大大加快數據的檢索速度。但是,有些情況索引是不會起效的:

1、應盡量避免在 where子句中使用!=或<>操作符,否則將引擎放棄使用索引而進行全表掃描。

2、應盡量避免在 where子句中對字段進行 null值判斷,否則將導致引擎放棄使用索引而進行全表掃描,如:
     select id from t where num is null
     可以在num上設置默認值0,確保表中num列沒有null值,然后這樣查詢:
     select id from t where num=0

3、盡量避免在 where子句中使用 or來連接條件,否則將導致引擎放棄使用索引而進行全表掃描,如:
     select id from t where num=10 or num=20
     可以這樣查詢:
     select id from t where num=10
     union all
     select id from t where num=20

4、下面的查詢也將導致全表掃描:

    select id from t where name like ‘%abc%’

    若要提高效率,可以考慮全文檢索。

5、in和 not in也要慎用,否則會導致全表掃描,如:
     select id from t where num in(1,2,3)
     對於連續的數值,能用 between就不要用 in了:
     select id from t where num between 1 and 3

6、如果在 where子句中使用參數,也會導致全表掃描。因為SQL只有在運行時才會解析局部變量,但優化程序不能將訪問計划的選擇推遲到運行時;它必須在編譯時進行選擇。然而,如果在編譯時建立訪問計划,變量的值還是未知的,因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描:
     select id from t where num=@num
     可以改為強制查詢使用索引:
     select id from t with(index(索引名)) where num=@num

7、應盡量避免在 where子句中對字段進行表達式操作,這將導致引擎放棄使用索引而進行全表掃描。如:
     select id from t where num/2=100
     應改為:
     select id from t where num=100*2

8、應盡量避免在where子句中對字段進行函數操作,這將導致引擎放棄使用索引而進行全表掃描。如:
     select id from t where substring(name,1,3)=’abc’–name以abc開頭的id
     select id from t where datediff(day,createdate,’2005-11-30′)=0–’2005-11-30′生成的id
     應改為:
     select id from t where name like ‘abc%’
     select id from t where createdate>=’2005-11-30′ and createdate<’2005-12-1′

9、不要在 where子句中的“=”左邊進行函數、算術運算或其他表達式運算,否則系統將可能無法正確使用索引。

10、在使用索引字段作為條件時,如果該索引是復合索引,那么必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引,否則該索引將不會被使用,並且應盡可能的讓字段順序與索引順序相一致。

11、不要寫一些沒有意義的查詢,如需要生成一個空表結構:
     select col1,col2 into #t from t where 1=0
     這類代碼不會返回任何結果集,但是會消耗系統資源的,應改成這樣:
     create table #t(…)

12、很多時候用 exists代替 in是一個好的選擇:
     select num from a where num in(select num from b)
     用下面的語句替換:
     select num from a where exists(select 1 from b where num=a.num)

 

    建索引需要注意的地方:

1、並不是所有索引對查詢都有效,SQL是根據表中數據來進行查詢優化的,當索引列有大量數據重復時,SQL查詢可能不會去利用索引,如一表中有字段 sex,male、female幾乎各一半,那么即使在sex上建了索引也對查詢效率起不了作用。

2、索引並不是越多越好,索引固然可以提高相應的 select的效率,但同時也降低了 insert及 update的效率,因為 insert或 update時有可能會重建索引,所以怎樣建索引需要慎重考慮,視具體情況而定。一個表的索引數最好不要超過6個,若太多則應考慮一些不常使用到的列上建的索引是否有必要。

3、應盡可能的避免更新 clustered索引數據列,因為 clustered索引數據列的順序就是表記錄的物理存儲順序,一旦該列值改變將導致整個表記錄的順序的調整,會耗費相當大的資源。若應用系統需要頻繁更新 clustered索引數據列,那么需要考慮是否應將該索引建為clustered索引。

 

    其他需要注意的地方:

1、盡量使用數字型字段,若只含數值信息的字段盡量不要設計為字符型,這會降低查詢和連接的性能,並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符,而對於數字型而言只需要比較一次就夠了。

2、任何地方都不要使用 select * from t,用具體的字段列表代替“*”,不要返回用不到的任何字段。

3、盡量使用表變量來代替臨時表。如果表變量包含大量數據,請注意索引非常有限(只有主鍵索引)。

4、避免頻繁創建和刪除臨時表,以減少系統表資源的消耗。

5、臨時表並不是不可使用,適當地使用它們可以使某些例程更有效,例如,當需要重復引用大型表或常用表中的某個數據集時。但是,對於一次性事件,最好使用導出表。

6、在新建臨時表時,如果一次性插入數據量很大,那么可以使用 select into代替 create table,避免造成大量 log,以提高速度;如果數據量不大,為了緩和系統表的資源,應先create table,然后insert。

7、如果使用到了臨時表,在存儲過程的最后務必將所有的臨時表顯式刪除,先 truncate table,然后 drop table,這樣可以避免系統表的較長時間鎖定。

8、盡量避免使用游標,因為游標的效率較差,如果游標操作的數據超過1萬行,那么就應該考慮改寫。

9、使用基於游標的方法或臨時表方法之前,應先尋找基於集的解決方案來解決問題,基於集的方法通常更有效。

10、與臨時表一樣,游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法,尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括“合計”的例程通常要比使用游標執行的速度快。如果開發時間允許,基於游標的方法和基於集的方法都可以嘗試一下,看哪一種方法的效果更好。

11、在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON,在結束時設置 SET NOCOUNT OFF。無需在執行存儲過程和觸發器的每個語句后向客戶端發送 DONE_IN_PROC消息。

12、盡量避免向客戶端返回大數據量,若數據量過大,應該考慮相應需求是否合理。

13、盡量避免大事務操作,提高系統並發能力。

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM