體系結構的概念
任何一套系統當中，每個部件都能起到一定的作用！
MySQL的體系結構
體系結構詳解
用戶端連接配接
支援接口：支援的用戶端連接配接，例如C、Java、PHP等語言來連接配接MySQL資料庫
第一層：網絡連接配接層
連接配接池：管理、緩沖使用者的連接配接，線程處理等需要緩存的需求。
例如：當用戶端發送一個請求連接配接，會從連接配接池中擷取一個連接配接進行使用。
第二層：核心服務層
管理服務和工具：系統的管理和控制工具，例如備份恢複、複制、叢集等。
SQL接口：接受SQL指令，并且傳回查詢結果。
查詢解析器：驗證和解析SQL指令，例如過濾條件、文法結構等。
查詢優化器：在執行查詢之前，使用預設的一套優化機制進行優化sql語句
緩存：如果緩存當中有想查詢的資料，則直接将緩存中的資料傳回。沒有的話再重新查詢！
第三層：存儲引擎層
插件式存儲引擎：管理和操作資料的一種機制，包括(存儲資料、如何更新、查詢資料等)
第四層：系統檔案層
檔案系統：配置檔案、資料檔案、日志檔案、錯誤檔案、二進制檔案等等的儲存
引擎的概念
生活中，引擎就是整個機器運作的核心，不同的引擎具備不同的功能。
MySQL存儲引擎的概念
MySQL資料庫使用不同的機制存取表檔案 , 機制的差别在于不同的存儲方式、索引技巧、鎖定水準以及廣泛的不同的功能和能力，在MySQL中 , 将這些不同的技術及配套的功能稱為存儲引擎
在關系型資料庫中資料的存儲是以表的形式存進行儲的，是以存儲引擎也可以稱為表類型（即存儲和操作此表的類型）。
Oracle , SqlServer等資料庫隻有一種存儲引擎 , 而MySQL針對不同的需求, 配置MySQL的不同的存儲引擎 , 就會讓資料庫采取了不同的處理資料的方式和擴充功能。
通過選擇不同的引擎 ,能夠擷取最佳的方案 , 也能夠獲得額外的速度或者功能，提高程式的整體效果。是以了解引擎的特性 , 才能貼合我們的需求 , 更好的發揮資料庫的性能。
MySQL支援的存儲引擎
MySQL5.7支援的引擎包括：InnoDB、MyISAM、MEMORY、Archive、Federate、CSV、BLACKHOLE等
其中較為常用的有三種：InnoDB、MyISAM、MEMORY
常用的存儲引擎
MyISAM存儲引擎
通路快,不支援事務和外鍵。表結構儲存在.frm檔案中，表資料儲存在.MYD檔案中，索引儲存在.MYI檔案中。
InnoDB存儲引擎(MySQL5.5版本後預設的存儲引擎)
支援事務 ,占用磁盤空間大 ,支援并發控制。表結構儲存在.frm檔案中，如果是共享表空間，資料和索引儲存在 innodb_data_home_dir 和 innodb_data_file_path定義的表空間中，可以是多個檔案。如果是多表空間存儲，每個表的資料和索引單獨儲存在 .ibd 中。
MEMORY存儲引擎
記憶體存儲 , 速度快 ,不安全 ,适合小量快速通路的資料。表結構儲存在.frm中。
特性對比
特性
MyISAM
InnoDB
MEMORY
存儲限制
有(平台對檔案系統大小的限制)
64TB
有(平台的記憶體限制)
事務安全
不支援
支援
鎖機制
表鎖
表鎖/行鎖
B+Tree索引
哈希索引
全文索引
叢集索引
資料索引
資料緩存
N/A
索引緩存
資料可壓縮
空間使用
低
高
記憶體使用
中等
批量插入速度
外鍵
查詢資料庫支援的引擎
查詢某個資料庫中所有資料表的引擎
查詢某個資料庫中某個資料表的引擎
建立資料表，指定存儲引擎
修改表的存儲引擎
MyISAM ：由于MyISAM不支援事務、不支援外鍵、支援全文檢索和表級鎖定，讀寫互相阻塞，讀取速度快，節約資源，是以如果應用是以查詢操作和插入操作為主，隻有很少的更新和删除操作，并且對事務的完整性、并發性要求不是很高，那麼選擇這個存儲引擎是非常合适的。
InnoDB : 是MySQL的預設存儲引擎， 由于InnoDB支援事務、支援外鍵、行級鎖定 ，支援所有輔助索引(5.5.5後不支援全文檢索)，高緩存，是以用于對事務的完整性有比較高的要求，在并發條件下要求資料的一緻性，讀寫頻繁的操作，那麼InnoDB存儲引擎是比較合适的選擇，比如BBS、計費系統、充值轉賬等
MEMORY：将所有資料儲存在RAM中，在需要快速定位記錄和其他類似資料環境下，可以提供更快的通路。MEMORY的缺陷就是對表的大小有限制，太大的表無法緩存在記憶體中，其次是要確定表的資料可以恢複，資料庫異常終止後表中的資料是可以恢複的。MEMORY表通常用于更新不太頻繁的小表，用以快速得到通路結果。
總結：針對不同的需求場景，來選擇最适合的存儲引擎即可！如果不确定、則使用資料庫預設的存儲引擎！
我們之前學習過集合，其中的ArrayList集合的特點之一就是有索引。那麼有索引會帶來哪些好處呢？
沒錯，查詢資料快！我們可以通過索引來快速查找到想要的資料。那麼對于我們的MySQL資料庫中的索引功能也是類似的！
MySQL資料庫中的索引：是幫助MySQL高效擷取資料的一種資料結構！是以，索引的本質就是資料結構。
在表資料之外，資料庫系統還維護着滿足特定查找算法的資料結構，這些資料結構以某種方式指向資料， 這樣就可以在這些資料結構上實作進階查找算法，這種資料結構就是索引。
一張資料表，用于儲存資料。 一個索引配置檔案，用于儲存索引，每個索引都去指向了某一個資料(表格示範)
舉例，無索引和有索引的查找原理
功能分類
普通索引： 最基本的索引，它沒有任何限制。
唯一索引：索引列的值必須唯一，但允許有空值。如果是組合索引，則列值組合必須唯一。
主鍵索引：一種特殊的唯一索引，不允許有空值。一般在建表時同時建立主鍵索引。
組合索引：顧名思義，就是将單列索引進行組合。
外鍵索引：隻有InnoDB引擎支援外鍵索引，用來保證資料的一緻性、完整性和實作級聯操作。
全文索引：快速比對全部文檔的方式。InnoDB引擎5.6版本後才支援全文索引。MEMORY引擎不支援。
結構分類
B+Tree索引 ：MySQL使用最頻繁的一個索引資料結構，是InnoDB和MyISAM存儲引擎預設的索引類型。
Hash索引 : MySQL中Memory存儲引擎預設支援的索引類型。
資料準備
建立索引
注意：如果一個表中有一列是主鍵，那麼就會預設為其建立主鍵索引！(主鍵列不需要單獨建立索引)
檢視索引
alter語句添加索引
删除索引
索引是在MySQL的存儲引擎中實作的，是以每種存儲引擎的索引不一定完全相同，也不是所有的引擎支援所有的索引類型。這裡我們主要介紹InnoDB引擎的實作的B+Tree索引。
B+Tree是一種樹型資料結構，是B-Tree的變種。通常使用在資料庫和作業系統中的檔案系統，特點是能夠保持資料穩定有序。我們逐漸的來了解一下。
系統從磁盤讀取資料到記憶體時是以磁盤塊（block）為基本機關的
位于同一個磁盤塊中的資料會被一次性讀取出來，而不是需要什麼取什麼。
InnoDB存儲引擎中有頁（Page）的概念，頁是其磁盤管理的最小機關。InnoDB存儲引擎中預設每個頁的大小為16KB。
InnoDB引擎将若幹個位址連接配接磁盤塊，以此來達到頁的大小16KB，在查詢資料時如果一個頁中的每條資料都能有助于定位資料記錄的位置，這将會減少磁盤I/O次數，提高查詢效率。
BTree結構的資料可以讓系統高效的找到資料所在的磁盤塊。為了描述BTree，首先定義一條記錄為一個二進制組[key, data] ，key為記錄的鍵值，對應表中的主鍵值，data為一行記錄中除主鍵外的資料。對于不同的記錄，key值互不相同。BTree中的每個節點根據實際情況可以包含大量的關鍵字資訊和分支，如下圖所示為一個3階的BTree：
根據圖中結構顯示，每個節點占用一個盤塊的磁盤空間，一個節點上有兩個升序排序的關鍵字和三個指向子樹根節點的指針，指針存儲的是子節點所在磁盤塊的位址。兩個關鍵詞劃分成的三個範圍域對應三個指針指向的子樹的資料的範圍域。以根節點為例，關鍵字為17和35，P1指針指向的子樹的資料範圍為小于17，P2指針指向的子樹的資料範圍為17~35，P3指針指向的子樹的資料範圍為大于35。
查找順序：
B+Tree是在BTree基礎上的一種優化，使其更适合實作外存儲索引結構，InnoDB存儲引擎就是用B+Tree實作其索引結構。
從上一節中的BTree結構圖中可以看到每個節點中不僅包含資料的key值，還有data值。而每一個頁的存儲空間是有限的，如果data資料較大時将會導緻每個節點（即一個頁）能存儲的key的數量很小，當存儲的資料量很大時同樣會導緻B-Tree的深度較大，增大查詢時的磁盤I/O次數，進而影響查詢效率。在B+Tree中，所有資料記錄節點都是按照鍵值大小順序存放在同一層的葉子節點上，而非葉子節點上隻存儲key值資訊，這樣可以大大加大每個節點存儲的key值數量，降低B+Tree的高度。
B+Tree相對于BTree差別：
非葉子節點隻存儲鍵值資訊。
所有葉子節點之間都有一個連接配接指針。
資料記錄都存放在葉子節點中。
将上一節中的BTree優化，由于B+Tree的非葉子節點隻存儲鍵值資訊，假設每個磁盤塊能存儲4個鍵值及指針資訊，則變成B+Tree後其結構如下圖所示：
通常在B+Tree上有兩個頭指針，一個指向根節點，另一個指向關鍵字最小的葉子節點，而且所有葉子節點（即資料節點）之間是一種鍊式環結構。是以可以對B+Tree進行兩種查找運算：
【有範圍】對于主鍵的範圍查找和分頁查找
【有順序】從根節點開始，進行随機查找
實際情況中每個節點可能不能填充滿，是以在資料庫中，B+Tree的高度一般都在24層。MySQL的InnoDB存儲引擎在設計時是将根節點常駐記憶體的，也就是說查找某一鍵值的行記錄時最多隻需要13次磁盤I/O操作。
索引的設計可以遵循一些已有的原則，建立索引的時候請盡量考慮符合這些原則，便于提升索引的使用效率，更高效的使用索引。
建立索引時的原則
對查詢頻次較高，且資料量比較大的表建立索引。
使用唯一索引，區分度越高，使用索引的效率越高。
索引字段的選擇，最佳候選列應當從where子句的條件中提取，如果where子句中的組合比較多，那麼應當挑選最常用、過濾效果最好的列的組合。
使用短索引，索引建立之後也是使用硬碟來存儲的，是以提升索引通路的I/O效率，也可以提升總體的通路效率。假如構成索引的字段總長度比較短，那麼在給定大小的存儲塊内可以存儲更多的索引值，相應的可以有效的提升MySQL通路索引的I/O效率。
索引可以有效的提升查詢資料的效率，但索引數量不是多多益善，索引越多，維護索引的代價自然也就水漲船高。對于插入、更新、删除等DML操作比較頻繁的表來說，索引過多，會引入相當高的維護代價，降低DML操作的效率，增加相應操作的時間消耗。另外索引過多的話，MySQL也會犯選擇困難病，雖然最終仍然會找到一個可用的索引，但無疑提高了選擇的代價。
聯合索引的特點
在mysql建立聯合索引時會遵循最左字首比對的原則，即最左優先，在檢索資料時從聯合索引的最左邊開始比對，
對列name列、address和列phone列建一個聯合索引
聯合索引index_three實際建立了(name)、(name,address)、(name,address,phone)三個索引。是以下面的三個SQL語句都可以命中索引。
上面三個查詢語句執行時會依照最左字首比對原則，檢索時分别會使用索引
進行資料比對。
索引的字段可以是任意順序的，如：
Mysql的優化器會幫助我們調整where條件中的順序，以比對我們建立的索引。
聯合索引中最左邊的列不包含在條件查詢中，是以根據上面的原則，下面的SQL語句就不會命中索引。
之前我們學習過多線程，多線程當中如果想保證資料的準确性是如何實作的呢？沒錯，通過同步實作。同步就相當于是加鎖。加了鎖以後有什麼好處呢？當一個線程真正在操作資料的時候，其他線程隻能等待。當一個線程執行完畢後，釋放鎖。其他線程才能進行操作！
那麼我們的MySQL資料庫中的鎖的功能也是類似的。在我們學習事務的時候，講解過事務的隔離性，可能會出現髒讀、不可重複讀、幻讀的問題，當時我們的解決方式是通過修改事務的隔離級别來控制，但是資料庫的隔離級别呢我們并不推薦修改。是以，鎖的作用也可以解決掉之前的問題！
鎖機制 : 資料庫為了保證資料的一緻性，而使用各種共享的資源在被并發通路時變得有序所設計的一種規則。
舉例，在電商網站購買商品時，商品表中隻存有1個商品，而此時又有兩個人同時購買，那麼誰能買到就是一個關鍵的問題。
這裡會用到事務進行一系列的操作：
先從商品表中取出物品的資料
然後插入訂單
付款後，再插入付款表資訊
更新商品表中商品的數量
以上過程中，使用鎖可以對商品數量資料資訊進行保護，實作隔離，即隻允許第一位使用者完成整套購買流程，而其他使用者隻能等待，這樣就解決了并發中的沖突問題。
在資料庫中，資料是一種供許多使用者共享通路的資源，如何保證資料并發通路的一緻性、有效性，是所有資料庫必須解決的一個問題，MySQL由于自身架構的特點，在不同的存儲引擎中，都設計了面對特定場景的鎖定機制，是以引擎的差别，導緻鎖機制也是有很大差别的。
按操作分類：
共享鎖：也叫讀鎖。針對同一份資料，多個事務讀取操作可以同時加鎖而不互相影響 ，但是不能修改資料記錄。
排他鎖：也叫寫鎖。目前的操作沒有完成前,會阻斷其他操作的讀取和寫入
按粒度分類：
表級鎖：操作時，會鎖定整個表。開銷小，加鎖快；不會出現死鎖；鎖定力度大，發生鎖沖突機率高，并發度最低。偏向于MyISAM存儲引擎！
行級鎖：操作時，會鎖定目前操作行。開銷大，加鎖慢；會出現死鎖；鎖定粒度小，發生鎖沖突的機率低，并發度高。偏向于InnoDB存儲引擎！
頁級鎖：鎖的粒度、發生沖突的機率和加鎖的開銷介于表鎖和行鎖之間，會出現死鎖，并發性能一般。
按使用方式分類：
悲觀鎖：每次查詢資料時都認為别人會修改，很悲觀，是以查詢時加鎖。
樂觀鎖：每次查詢資料時都認為别人不會修改，很樂觀，但是更新時會判斷一下在此期間别人有沒有去更新這個資料
不同存儲引擎支援的鎖
存儲引擎
表級鎖
行級鎖
頁級鎖
BDB
共享鎖
排他鎖
注意：鎖的相容性
共享鎖和共享鎖 相容
共享鎖和排他鎖 沖突
排他鎖和排他鎖 沖突
排他鎖和共享鎖 沖突
讀鎖
寫鎖
悲觀鎖的概念
就是很悲觀，它對于資料被外界修改的操作持保守态度，認為資料随時會修改。
整個資料進行中需要将資料加鎖。悲觀鎖一般都是依靠關系型資料庫提供的鎖機制。
我們之前所學的行鎖，表鎖不論是讀寫鎖都是悲觀鎖。
樂觀鎖的概念
就是很樂觀，每次自己操作資料的時候認為沒有人會來修改它，是以不去加鎖。
但是在更新的時候會去判斷在此期間資料有沒有被修改。
需要使用者自己去實作，不會發生并發搶占資源，隻有在送出操作的時候檢查是否違反資料完整性。
悲觀鎖和樂觀鎖使用前提
對于讀的操作遠多于寫的操作的時候，這時候一個更新操作加鎖會阻塞所有的讀取操作，降低了吞吐量。最後還要釋放鎖，鎖是需要一些開銷的，這時候可以選擇樂觀鎖。
如果是讀寫比例差距不是非常大或者系統沒有響應不及時，吞吐量瓶頸的問題，那就不要去使用樂觀鎖，它增加了複雜度，也帶來了業務額外的風險。這時候可以選擇悲觀鎖。
樂觀鎖的實作方式
版本号
給資料表中添加一個version列，每次更新後都将這個列的值加1。
讀取資料時，将版本号讀取出來，在執行更新的時候，比較版本号。
如果相同則執行更新，如果不相同，說明此條資料已經發生了變化。
使用者自行根據這個通知來決定怎麼處理，比如重新開始一遍，或者放棄本次更新。
時間戳
和版本号方式基本一樣，給資料表中添加一個列，名稱無所謂，資料類型需要是timestamp
每次更新後都将最新時間插入到此列。
讀取資料時，将時間讀取出來，在執行更新的時候，比較時間。
表鎖和行鎖
行鎖：鎖的粒度更細，加行鎖的性能損耗較大。并發處理能力較高。InnoDB引擎預設支援！
表鎖：鎖的粒度較粗，加表鎖的性能損耗較小。并發處理能力較低。InnoDB、MyISAM引擎支援！
InnoDB鎖優化建議
盡量通過帶索引的列來完成資料查詢，進而避免InnoDB無法加行鎖而更新為表鎖。
合理設計索引，索引要盡可能準确，盡可能的縮小鎖定範圍，避免造成不必要的鎖定。
盡可能減少基于範圍的資料檢索過濾條件。
盡量控制事務的大小，減少鎖定的資源量和鎖定時間長度。
在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖産生機率。
對于非常容易産生死鎖的業務部分，可以嘗試使用更新鎖定顆粒度，通過表級鎖定來減少死鎖的産生。
如今随着網際網路的發展，資料的量級也是成指數的增長，從GB到TB到PB。對資料的各種操作也是愈加的困難，傳統的關系型資料庫已經無法滿足快速查詢與插入資料的需求。一台資料庫伺服器已經無法滿足海量資料的存儲需求，是以由多台資料庫構成的資料庫叢集成了必然的方式。不過，為了保證資料的一緻性，查詢效率等，同時又要解決多台伺服器間的通信、負載均衡等問題。
MyCat是一款資料庫叢集軟體，是阿裡曾經開源的知名産品——Cobar，簡單的說，MyCAT就是：一個新穎的資料庫中間件産品支援MySQL叢集，提供高可用性資料分片叢集。你可以像使用mysql一樣使用mycat。對于開發人員來說根本感覺不到mycat的存在。MyCat不單單是支援MySQL，像常用的關系型資料庫Oracle、SqlServer都支援。
我們來說個例子，大海撈針和一個水瓶裡撈針，毋庸置疑水瓶裡一定能更快找到針，因為它需要檢索的範圍更小。資料庫叢集也是如此原理，我們可以将一個資料量為300G的資料庫資料平均拆分成3部分，每個資料庫中隻存儲100G資料，此時使用者搜尋，先經過我們中間代理層，中間代理層同時發出3個請求執行查詢，比如第1台傳回100條資料，耗時3秒，第2台傳回200條資料，耗時3秒，第3台傳回500條資料，耗時3秒，此時中間件隻需要在800條記錄中進行篩選，即可檢索出使用者要的結果，此時耗時其實一共隻有3秒，因為每台機器做運算的時候，都是同時執行。如果我們此時直接在300G的資料庫查詢，耗時10秒，那使用中間件進行叢集的效率就非常明顯
MyCat的實作流程和這個流程大緻相似。MyCat自身不存儲資料，但使用者每次連結資料庫的時候，直接連接配接MyCat即可.是以我們MyCat自身其實就是個邏輯資料庫，它自身還有表結構，表結構叫邏輯表。
官網：<code>http://www.mycat.io/</code>
下載下傳位址 : <code>http://dl.mycat.io/</code>
選擇1.6.7.1的版本，下載下傳到D盤，安裝包入下圖：
上傳：使用SecureCRT的SFTP指令，将檔案發送到Linux虛拟機root目錄下：
解壓：解壓mycat.tar.gz并檢視
授權：設定mycat權限
環境變量：配置環境變量
啟動mycat
檢視：檢測端口監聽狀況，Mycat的端口号是8066
連接配接：使用SQLYog連接配接Mycat
連接配接後顯示：
配置模型
克隆虛拟機
修改配置網卡
在第二個虛拟機中，生成全新mac位址
重新開機網絡
修改mysql配置檔案,更改uuid
在第二個伺服器上，修改mysql的uuid
啟動MySQL并檢視
主從複制的概念
為了使用Mycat進行讀寫分離，我們先要配置MySQL資料庫的主從複制。
從伺服器自動同步主伺服器的資料，進而達到資料一緻。
進而，我們可以寫操作時，隻操作主伺服器，而讀操作，就可以操作從伺服器了。
原理：主伺服器在處理資料時，生成binlog日志，通過對日志的備份，實作從伺服器的資料同步。
主伺服器的配置
在第一個伺服器上，編輯mysql配置檔案
登入mysql，建立使用者并授權
重新開機mysql服務，登入mysql服務
檢視主伺服器的配置
從伺服器的配置
在第二個伺服器上，編輯mysql配置檔案
登入mysql
重新開機mysql，重新登入，配置從節點
重新開機mysql，重新登入，開啟從節點
測試
sqlyog連接配接主伺服器
sqlyog連接配接從伺服器
啟動失敗的解決方案
讀寫分離的概念
寫操作隻寫入主伺服器，讀操作讀取從伺服器。
在主伺服器上修改server.xml
user标簽主要用于定義登入mycat的使用者和權限。如上面定義使用者名mycat和密碼123456，該使用者可以通路的schema的HEIMADB邏輯庫。
在主伺服器上修改schema.xml
配置詳解
schema标簽邏輯庫的概念和mysql資料庫中Datebase的概念相同，我們在查詢這兩個邏輯庫中的表的時候，需要切換到該邏輯庫下才可以查到所需要的表。
dataNode屬性：該屬性用于綁定邏輯庫到某個具體的database上。
dataNode标簽： dataNode标簽定義了mycat中的資料節點，也就是資料分片。一個dataNode标簽就是一個獨立的資料分片。
name屬性：定義資料節點的名字，這個名字需要是唯一的，我們需要在table标簽上應用這個名字，來建立表與分片對應的關系。
dataHost屬性：該屬性用于定義該分片屬于那個資料庫執行個體，屬性值是引用datahost标簽定義的name屬性。
database屬性：該屬性用于定義該分片屬于那個具體資料庫執行個體上的具體庫，因為這裡使用兩個緯度來定義分片，就是：執行個體+具體的庫。因為每個庫上建立的表和表結構是一樣的。是以這樣做就可以輕松的對表進行水準拆分。
dataHost标簽：該标簽在mycat邏輯庫中也是作為最底層的标簽存在，直接定義了具體的資料庫執行個體、讀寫分離配置和心跳語句。
balance屬性： 負載均衡類型
balance=0: 不開啟讀寫分離，所有讀操作都發送到目前可用的writeHost上。
balance=1: 全部的readHost與Stand by writeHost都參與select語句的負載均衡
balance=2: 所有的讀操作都随機在writeHost，readHost上分發。
balance=3: 所有的讀請求都随機配置設定到writeHost對應的readHost上執行，writeHost不負擔讀壓力。
switchType屬性：
-1：表示不自動切換。
1 ：預設值，表示自動切換
2：表示基于MySQL主從同步狀态決定是否切換，心跳語句： show slave status.
3:表示基于mysql galary cluster的切換機制，适合mycat1.4之上的版本，心跳語句show status like "%esrep%";
writeHost标簽，readHost标簽：這兩個标簽指定後端資料庫的相關配置給mycat，用于執行個體化後端連接配接池。唯一不同的是，writeHost指定寫執行個體、readHost指定讀執行個體，組合這些讀寫執行個體來滿足系統的要求。
host屬性：用于辨別不同的執行個體，對于writehost，一般使用M1；對于readhost一般使用S1.
url屬性：後端執行個體連接配接位址，如果使用native的dbDriver，則一般為address:port這種形式，用JDBC或其他的dbDriver，則需要特殊指定。當使用JDBC時則可以這麼寫：jdbc:mysql://localhost:3306/。
user屬性：後端存儲執行個體的使用者名。
password屬性：後端存儲執行個體的密碼
重新開機主伺服器的mycat
sqlyog連接配接mycat
分庫分表的概念
将龐大的資料進行拆分
水準拆分：根據表的資料邏輯關系，将同一表中的資料按照某種條件，拆分到多台資料庫伺服器上，也叫做橫向拆分。例如：一張1000萬的大表，按照一模一樣的結構，拆分成4個250萬的小表，分别儲存到4個資料庫中。
垂直拆分：根據業務的次元，将不同的表切分到不同的資料庫之上，也叫做縱向拆分。例如：所有的訂單都儲存到訂單庫中，所有的使用者都儲存到使用者庫中，同類型的表儲存在同一庫，不同的表分散在不同的庫中。
Mycat水準拆分
修改主伺服器的server.xml
0：本地檔案方式
在mycat/conf/sequence_conf.properties檔案中：
GLOBAL.MINDI=10000最小值
GLOBAL.MAXID=20000最大值，建議修改到9999999999
1：資料庫方式
分庫分表中保證全局主鍵自增唯一，但是需要執行mycat函數，配置sequence_db_conf.properties
2：時間戳方式
mycat實作的時間戳，建議varchar類型，要注意id的長度
修改主伺服器的sequence_conf.properties
修改主伺服器的schema.xml
table标簽定義了邏輯表，所有需要拆分的表都需要在這個标簽中定義。
rule屬性：拆分規則。mod-long是拆分規則之一，主鍵根據伺服器數量取模，在rule.xml中指定。如果是3個資料庫，那麼資料取模後，平均配置設定到三個庫中。
name屬性：定義邏輯表的表名，這個名字就如同在資料庫中執行create table指令指定的名字一樣，同一個schema标簽中定義的表名必須是唯一的。
dataNode屬性： 定義這個邏輯表所屬的dataNode，該屬性的值需要和dataNode标簽中name屬性的值互相對應。
修改主伺服器的rule.xml
mycat操作
主伺服器操作
從伺服器操作
Mycat垂直拆分
修改主伺服器的schema