2017-07-25 14:15:43
前言：mysql從5.0和5.1版本開始引入了很多高階特性，例如分割槽、觸發器等，這對有其他關係型資料庫使用
背景的使用者來說可能並不陌生。這些新特性吸引了很多使用者開始使用mysql。不過，這些特性的效能到底如何，
還需要使用者真正使用過才能知道。
1.1分割槽表
對使用者來說，分割槽表是乙個獨立的邏輯表，但是底層由多個物理子表組成。實現分割槽的**實際上是對一組
底層表的控制代碼物件（handler object）的封裝。
對分割槽表的請求，都會通過控制代碼物件轉化成對儲存引擎的介面呼叫。
所以分割槽對於sql層來說是乙個完全封裝底層實現的黑盒子，對應用是透明的，但是從底層的檔案系統來看就很容易發現，每乙個分割槽表都有乙個使用#分隔命名的表檔案。
mysql實現分割槽表的方式——對底層表的封裝——意味著索引也是按照分割槽的子表定義的，而沒有全域性索引。
（問：全域性索引是什麼？ 答：）這和oracle不同，在oracle中可以更加靈活地定義索引和表是否進行分割槽。
mysql在建立表時使用partithon by 字句定義每個分割槽存放的資料。在執行查詢的時候，優化器會根據分割槽定義
過濾哪些沒有我們需要資料的分割槽。這樣查詢就無需掃瞄所有分割槽——只需要查詢包含需要資料的分割槽就可以了。
分割槽的乙個主要目的是將資料按照乙個較粗的力度分在不同的表中。這樣做可以將相關的資料放在一起。另外，如果
像一次批量刪除整個分割槽的資料也會變得很方便。
在下面的場景中，分割槽可以起到非常大的作用：
a.表非常大以至於無法全部都放在記憶體中，或者只在表的最後部分有熱點資料，其他均是歷史資料。
b.分割槽表的資料更容易維護。例如，像批量刪除大量資料可以使用清楚整個分割槽的方式。另外，還可以對乙個獨立分割槽進行優化、檢查、修復等操作。
c.分割槽表的資料可以分布在不同的物理裝置上，從而高效的利用多個硬體裝置。
d.可以使用分割槽表來避免某些特殊的瓶頸，例如innodb的單個索引的互斥訪問、ext3檔案系統的inode鎖競爭等。
e.如果需要，還可以備份和恢復隊獨立分割槽，這在非常大的資料集的場景下效果非常好。
mysql的分割槽實現非常複雜，這裡專注在分割槽效能方面，如果想跟多了解，建議閱讀mysql官方手冊「分割槽」一節
可以通過使用show variables命令來確定mysql是否支援分割槽
分割槽本身也有一些限制，下面是其中比較重要的幾點：
a.乙個表最多只能有1024個分割槽。
b.在mysql5.1中，分割槽表示式必須是整數，或者是返回整數的表示式。在mysql5.5中某些場景中可以直接
使用列來分割槽。
c.如果分割槽欄位中有主鍵或者唯一索引的列，那麼所有主鍵列和唯一索引列都必須包含進來
d.分割槽表中無法使用外來鍵約束。（外來鍵：）
1.1.1分割槽表的原理
分割槽表由多個相關的底層表實現，這些底層表也是由控制代碼物件表示，所以我們也可以直接訪問各個分割槽。
儲存引擎管理分割槽的各個底層和管理普通表一樣（所有的底層表必須使用相同的儲存引擎），分割槽表的
索引只是在各個底層表上各自加上乙個完全相同的索引，從儲存引擎的角度來看，底層表和乙個普通表沒有
任何不同，儲存引擎也無需知道這是乙個普通表還是乙個分割槽表的一部分。
高效能Mysql 事務特性及實戰
事務的作用我就不再提及了，相信看到這篇文章的基本上都會知道事務的概念。本篇文章首先會介紹一下事務的特性 四種隔離級別以及對應的實戰測試,希望幫讀者加深事務的理解。隔離級別 髒讀可能 不可重複讀 幻讀ru yesyes yesrc noyes yesrr nono yesserialize nonon...
mysql離散查詢 如何寫出高效能的MySQL查詢
想寫這樣一篇文章很久了，但始終沒有下手。最近幫同事看了幾個查詢，而且自己也在考慮乙個索引系統的問題，所以今天就把這個寫了。介紹一下mysql的索引機制，還有一些mysql查詢的優化策略。鄙人才疏學淺，很可能說的不對，請路過的各位大俠批評指正，獻醜了。首先，說說mysql的索引儲存方式。mysql的索...
高效能mysql 樹 高效能mysql精要
1 explain 中 extra using index 表示覆蓋索引，sql優化中最好能使用覆蓋索引，否則 二級索引 需要回表查詢。所謂覆蓋索引，是指要查詢的列正好是索引，而條件也是這個索引之一 2 where 語句中 條件等於主鍵的 在核心索引層完成，條件等於非索引的，在服務層完成 3 讀索引...