mysql效能優化的目的
如何合理的設計資料庫？
什麼樣的資料庫設計才能給後期dba優化提供基石？
資料庫設計與程式設計的差異？
資料庫設計早期優化
1. 關係明確（理清表之間的關係，可以通過冗餘的方式提高效率）
2. 節省空間（根據業務經驗，設定字段長短）
3. 提高效率
資料庫表開發流程
原型=>逐步完善（表的設計也是如此）
資料庫種類
1. 層級資料庫（登錄檔） 如：windows作業系統的核心就是乙個登錄檔，由於配置項比較多，採用層級關係的資料儲存
2. 關係型資料庫 如：mysql
3. 時序資料庫
4. 圖資料庫 如：最短路徑，地理資訊
5. key-value資料庫 如：redis
6. 物件資料庫
7. bigtable資料庫
檔案系統和資料庫系統之間的區別
(1)檔案系統用檔案將資料長期儲存在外存上，資料庫系統用資料庫統一儲存資料;
(2)檔案系統中的程式和資料有一定的聯絡，資料庫系統中的程式和資料分離;
(3)檔案系統用作業系統中的訪問方法對資料進行管理，資料庫系統用dbms統一管理和控制資料;
(4)檔案系統實現以檔案為單位的資料共享，資料庫系統實現以記錄和字段為單位的資料共享。
優化設計第一步
想要在表設計中節省空間，就必須精通各種資料型別的特點（能用在什麼業務上）、長度等。
int型別只增主鍵字段=>4位元組=>每個位元組8位=>32位，在cpu載入一條指令的時候，4位元組是和cpu暫存器的運算有關，如：64位，由於直接的系統一般都是32位的，所以在運算4位元組的資料是剛好的，效率最高，而現今我們系統基本都是64位的時候，其實沒有更好的利用好cpu運算，所以在設計表字段建議，使用8位元組的主鍵bigint，而不是直接使用int來做主鍵。
uuid做主鍵，字元型別做主鍵，在cpu的載入是需要消耗更多的運算過程
char(10) 不管該欄位是否儲存資料，都佔10個字元的儲存空間
char(10) 同時存在乙個坑，就是儲存abc資料後改資料庫欄位的值為「abc 7個空格 」，在精準查詢（where）就必須帶上後面的7個空格
varchar 不存的時候不佔空間，存多長資料就佔多少空間
優化設計第二步
如何合理的設計出符合三正規化資料庫表?
1nf：列不可分。每一列都是不可分割的基本資料項，如這樣的設計就不合理，姓名（王五，wangwu）
2nf：1nf的基礎上面，非主屬性完全依賴於主關鍵字，如學生姓名（非主屬性）就是依賴於學號（主屬性）的。
3nf：屬性不依賴於其它非主屬性 , 消除傳遞依賴，如這樣的設計就不合理，學號做主鍵，學生課程表（學號=課程），當學號修改，對應的課程表也需要修改，這就是屬於傳遞依賴
bcnf：符合3nf，每個表中只有乙個候選鍵
4nf：沒有多值依賴
由於學號不能做主鍵，那用什麼做主鍵？首先就有這樣的規則：不要用業務規則來做主鍵，主鍵就應該和業務無關。
如經常用的的order_no（業務訂單號），即使是唯一的，也不建議做主鍵的，容易產生傳遞依賴的問題，這樣就不符合第三正規化了。
優化設計第三步
資料庫優化策略
1、選擇小的資料型別
2、單獨設計主鍵，並考慮分布式擴充套件
3、外來鍵設計
（重要，我們之前開發都是直接使用的弱外來鍵來設定主外來鍵關係，而實際專案中，如果要是刪除了主鍵對應的記錄後，外來鍵表中的記錄是沒有刪除的，這樣對於資料庫的資料是很容易混亂的，不便於維護，那我要是使用的是強外來鍵的方式，這樣直接刪除主鍵記錄，沒有刪除外來鍵表中的記錄，這樣是要報錯的，這樣容易找到**上的問題，外來鍵的設計能對於資料完整性有乙個好的約束，當你開發的系統已經完全不會出現資料不完整的問題的時候，你可以考慮使用弱外來鍵來關聯表操作，也同時會省去外來鍵消耗，具體的設定外來鍵方法查考部落格：外來鍵及其約束理解）
4、索引設計
（對於業務上的字段，那些需要字段需要建立索引？）
5、關聯關係表設計，多對一，多對多
6、讀寫頻繁的資訊，與不頻繁的資訊分開
（如在設計支付系統的時候，會同時存在訂單表和訂單記錄表，訂單表讀寫頻繁，而訂單記錄表就管理人員用，讀寫一般）
7、配置表，日誌表，定時任務表等
8、彙總表設計
（多表關聯查詢會很慢，還容易卡死的情況，可以考慮在業務上彙總，記錄到彙總表）
優化設計第四步
經過業務的沉澱，積累出一些設計思路或抽取出多專案的共同點，減少開發成本
1、通用型設計
例：人員，部門，角色
2、特別設計
附件，日誌，配置，監控等
3、儲存設計
型別劃分便於分割槽
4、一些附加字段
建立日期，修改日期，排序
5、流水表
類似於日誌，但由業務處理結果組成，帳戶變動或業務處理的中間值
在設計資料庫的時候應當落實如下的原則
（一）降低對資料庫功能的依賴（如在業務上使用了mysql特性，且這個特性是只有mysql存在的，對以後的資料庫遷移會帶來很大的麻煩）
（二）定義實體關係的原則
牽涉到的實體 識別出關係所涉及的所有實體。
所有權 考慮乙個實體「擁有」另乙個實體的情況。
基數 考量乙個實體的例項和另乙個實體例項關聯的數量。
（三）列意味著唯一的值
如果表示座標（0,0），應該使用兩列表示，而不是將「0,0」放在1個列中。
（四）列的順序，可讀性問題
（五）定義主鍵和外來鍵
資料表必須定義主鍵和外來鍵（如果有外來鍵）。
（六）選擇鍵
（七）是否允許null
任何值和null拼接後都為null。
所有與null進行的數學操作都返回null。
引入null後，邏輯不易處理。
（八）規範化——正規化
1nf包含分隔符類字元的字串資料。
名字尾端有數字的屬性。
沒有定義鍵或鍵定義不好的表。
2nf多個屬性有同樣的字首。
重複的資料組。
彙總的資料，所引用的資料在乙個完全不同的實體中。
bcnf- 「每個鍵必須唯一標識實體，每個非鍵熟悉必須描述實體。」
4nf三元關係（實體:實體:實體）。
潛伏的多值屬性。（如多個手機號。）
臨時資料或歷史值。（需要將歷史資料的主體提出，否則將存在大量冗餘。）
（九）選擇資料型別
（十）優化並行
設計db時就應該考慮到對並行進行優化，比如，timestamp型別。
命名規則
表名規則
1、要用字首，但不要用無意義的字首
2、下劃線分隔
3、全小寫
列名規則
2、下劃線分隔
3、全小寫
不管是表名設計還是列名設計，都不要使用拼音來命名，過一段時間就完全不記得了，就用英文，即使英語不好設計的時候也建議設定為英文。
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...
Mysql效能檢測及優化
本文參考 一.mysql優化思路 1.週期性的故障 1 訪問高峰或快取崩潰 增加快取，並修改快取失效策略，失效時間分散 2.通過show processlist 或者 開啟慢查詢日誌，獲取有問題的sql profiling 和 explain 分析sql語句 1 sql語句等待時間長 對伺服器引數優...
mysql索引及效能優化
索引就是資料結構，通過這種資料結構可以大大提高mysql的查詢效率當表中的資料量越來越大時，索引對於效能的影響愈發重要。索引優化應該是對查詢效能優化最有效的手段了。索引能夠輕易將查詢效能提高好幾個數量級。有了索引相當於我們給資料庫的資料加了目錄一樣，可以快速的找到資料，如果不適用索引則需要一點一點去...