• 資料庫結構的設計優化
  • 1.資料庫結構的設計
  • 2.針對大型的資料量提前進行分庫和分表
  • 3.分庫分錶帶來的問題
  • 4.表結構設計注意的問題
• 查詢優化
  • 1.查詢語句的注意事項
  • 2.應儘量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描
  • 3.建立索引注意事項
  • 4.使用聚集索引和非聚集索引
• 讀寫分離
  • 1.什麼是讀寫分離?
  • 2.資料庫分組架構解決什麼問題?
• 使用快取
  • 1.為什麼使用快取?
  • 2.具體使用

資料庫結構的設計優化

1.資料庫結構的設計

#1. 如果不能設計一個合理的資料庫模型
	不僅會增加客戶端和伺服器段程式的程式設計和維護的難度 而且將會影響系統實際執行的效能。所以，在一個
  系統開始實施之前，完備的資料庫模型的設計是必須的
  
#2. 在一個系統分析、設計階段，因為資料量較小，負荷較低 我們往往只注意到功能的實現，而很難注意
到效能的薄弱之處，等到系統投入實際執行一段時間後，才發現系統的效能在降低，這時再來考慮提高系統
效能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。

#3.在考慮整個系統的流程的時候，必須要考慮，在高併發大資料量的訪問情況下，我們的系統會不會出現極端的情況。 
	例如:對外統計系統在7月16日出現的資料異常的情況，併發大資料量的的訪問造成，資料庫的響應時間不
    能跟上資料重新整理的速度造成。具體情況是:在日期臨界時(00:00:00)，判斷資料庫中是否有當前日期
      的記錄，沒有則插入 一條當前日期的記錄。在低併發訪問的情況下，不會發生問題，但是當日期臨
      界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則資料庫裡會被插入多條
      當前日期的記錄，從而造成資料錯誤。
  
#4.資料庫的模型確定下來之後，我們有必要做一個系統內資料流向圖，分析可能出現的瓶頸
 

2.針對大型的資料量提前進行分庫和分表

#分庫分表儘量在資料庫設計初期敲定方案，否則後期會極大增加程式碼複雜性而且不易更改 

#索引適合應對百萬級別的資料量，千萬級別資料量使用的好，勉強也能湊合，但如果是上億級別的資料量，
索引就無能為力了，因為單索引檔案可能就已經上百兆或者更多了，那麼，輪到我們的分表分割槽登場了

#分庫分表的前提條件是在執行查詢語句之前，已經知道需要查詢的資料可能會落在哪一個分庫和哪一個分表中。

# 提前判斷資料的總大小，根據量選擇適用的模式，分庫分表，或者時序性資料庫

3.分庫分錶帶來的問題

#分庫分錶帶來的問題 
	1、事務一致性問題 
  2、跨節點關聯查詢 join 問題
		切分之前，系統中很多列表和詳情頁所需的資料可以通過sql join來完成。而切分之後，資料可能分
    布在不同的節 點上，此時join帶來的問題就比較麻煩了，考慮到效能，儘量避免使用join查詢
 

4.表結構設計注意的問題

1.能夠用數字型別的欄位儘量選擇數字型別而不用字串型別的(電話號碼) 
	#這會降低查詢和連線的效能，並會增加儲存開銷。這是因為引擎在處理查詢和連線會逐個比較字串中每一個字元，而對於數字型而言只需要比較一次就夠了。
  
2.對於不可變字元型別char和可變字元型別varchar，在設計欄位的時候可以靈活選擇char查詢快，但是耗儲存空間，例如使用者名稱、密碼等長度變化不大的欄位可以選擇CHAR，varchar查詢相對慢一些但是節省儲存空間,例如對於評論等長度變化大的欄位可以選擇VARCHAR。

3. 儘可能不要使用NULL值 因為建表的時候，如果不對建立的值設定預設值，MySQL都會設定預設為 NULL
NOT IN、!=等負向條件查詢在有NULL值的情況下返回永遠為空結果，查詢容易出錯 NULL列需要一個額外位元組作為判斷是否為NULL的標誌位 MySQL難以優化對可為NULL的列的查詢

4.最好不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和資料恢復。對外統計系統對映關係丟失 

5.資料行的長度不要超過8020位元組，如果超過這個長度在物理頁中這條資料會佔用兩行從而造成儲存碎片，降低查詢效率 

6.欄位的長度在最大限度的滿足可能的需要的前提下，應該儘可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗
 

查詢優化

1.查詢語句的注意事項

1.儘量使用簡單的查詢，避免使用錶鏈接,請儘量避免全表掃描，包括但不限於: where子句條件橫真或為空
2.使用LIKE
3.使用不等操作符(<>、!=)
4.查詢含義is null的列
5.在非索引列上使用or
6.多條件查詢時，請把簡單查詢條件或索引列查詢置於前面,
7.儘量指定需要查詢的列，不要偷懶使用select * 如果不指定，一方面會返回多餘的資料，佔用寬頻等 另一方面MySQL執行查詢的時候，沒有欄位時會先去查詢表結構有哪些欄位大寫的查詢關鍵字比小寫快一點點 使用子查詢會建立臨時表，會比連結(JOIN)和聯合(UNION)稍慢 
8.在索引欄位上查詢儘量不要使用資料庫函式，不便於快取查詢結果 
9.當只要一行資料時，請使用LIMIT 1，如果資料過多，請適當設定LIMIT，分頁查詢 千萬不要 ORDER BY RAND()，效能極低

2.應儘量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描

select id from t where num is null 
	可以在num上設定預設值0，確保表中num列沒有null值
	然後這樣查詢: select id from t where num=0

3.建立索引注意事項

# 建立時注意
	1.一般來說，每張表都需要有一個主鍵id欄位
	2.常用於查詢的欄位應該設定索引
	3.varchar型別的欄位，在建立索引的時候，最好指定長度 
  4.查詢有多個條件時，優先使用具有索引的條件
  5.像LIKE條件這樣的模糊搜尋對於欄位索引是無效的，需要另外建立關鍵詞索引來解決 
  6.請儘量不要在資料庫層面約束表和表之間的關係，這些表之間的依賴應該在程式碼層面去解決

4.使用聚集索引和非聚集索引

讀寫分離

1.什麼是讀寫分離?

	其實就是將資料庫分為了主從庫，一個主庫用於寫資料，多個從庫完成讀資料的操作，主從庫之間通過某種機制進行資料的同步，是一種常見的資料庫架構。
一個組從同步叢集，通常被稱為是一個“分組”。

2.資料庫分組架構解決什麼問題?

 	大多數網際網路業務，往往讀多寫少，這時候，資料庫的讀會首先稱為資料庫的瓶頸，這時，如果我們希望能夠線性的提升資料庫的讀效能，消除讀寫鎖衝突從而提升資料庫的寫效能，那麼就可以使用“分組架構”(讀寫分離架構)。 
#讀寫分離是用來解決資料庫的讀效能瓶頸的

使用快取

1.為什麼使用快取?

	快取，也是網際網路中常常使用到的一種架構方式,讀寫分離是通過多個讀庫，分攤了資料庫讀的壓力， 而儲存則是通過快取的使用，減少了資料庫讀的壓力。他們沒有誰替代誰的說法，但是，如果在快取的讀寫分離進行二選一時，還是應該首先考慮快取。
  
#為什麼呢?
快取的使用成本要比從庫少非常多; 快取的開發比較容易，大部分的讀操作都可以先去快取，找不到的再滲透到資料庫。 當然，如果我們已經運用了快取，但是讀依舊還是瓶頸時，就可以選擇“讀寫分離”架構了。簡單來說，我們可以將讀寫分離看做是快取都解決不了時的一種解決方案。

2.具體使用

#使用redis等快取，還有本地檔案快取等，可以極大地減少資料庫查詢次數。快取這個東西，一定要分析自己系統的資料特點，適當選擇。
  對於一些常用的資料，比如配置資訊等，可以放在快取中
  可以在本地快取資料庫的表結構
  快取的資料一定要注意及時更新，還有設定有效期
  增加快取務必會增加系統複雜性，一定要注意權衡