1. mysql讀寫分離原理是什麼
利用mysql proxy來實現的。
MySQL Proxy最強大的一項功能是實現「讀寫分離(Read/Write Splitting)」。基本的原理是讓主資料庫處理事務性查詢，而從資料庫處理SELECT查詢。資料庫復制被用來把事務性查詢導致的變更同步到集群中的從資料庫。當然，主伺服器也可以提供查詢服務。使用讀寫分離最大的作用無非是環境伺服器壓力。
2. Mysql的工作原理是什麼
Mysql工作原理圖
Mysql是由SQL介面，解析器，優化器，緩存，存儲引擎組成的。
mysql原理圖各個組件說明：
1. connectors
與其他編程語言中的sql語句進行交互，如php、java等。
2. Management Serveices & Utilities
系統管理和控制工具
3. Connection Pool (連接池)
管理緩沖用戶連接，線程處理等需要緩存的需求
4. SQL Interface (SQL介面)
接受用戶的SQL命令，並且返回用戶需要查詢的結果。比如select from就是調用SQL Interface
5. Parser（解析器）
SQL命令傳遞到解析器的時候會被解析器驗證和解析。
主要功能：
a .將SQL語句分解成數據結構，並將這個結構傳遞到後續步驟，後面SQL語句的傳遞和處理就是基於這個結構的
b. 如果在分解構成中遇到錯誤，那麼就說明這個sql語句是不合理的，語句將不會繼續執行下去
6. Optimizer (查詢優化器)
SQL語句在查詢之前會使用查詢優化器對查詢進行優化(產生多種執行計劃,最終資料庫會選擇最優化的方案去執行,盡快返會結果)他使用的是「選取-投影-聯接」策略進行查詢。
用一個例子就可以理解：select uid,name from user where gender = 1;
這個select查詢先根據where語句進行選取，而不是先將表全部查詢出來以後再進行gender過濾
這個select查詢先根據uid和name進行屬性投影，而不是將屬性全部取出以後再進行過濾
將這兩個查詢條件聯接起來生成最終查詢結果.
7. Cache和Buffer (查詢緩存)
如果查詢緩存有命中的查詢結果，查詢語句就可以直接去查詢緩存中取數據。
這個緩存機制是由一系列小緩存組成的。比如表緩存，記錄緩存，key緩存，許可權緩存等
8.Engine (存儲引擎)
存儲引擎是MySql中具體的與文件打交道的子系統。也是Mysql最具有特色的一個地方。
Mysql的存儲引擎是插件式的。它根據MySql AB公司提供的文件訪問層的一個抽象介面來定製一種文件訪問機制（這種訪問機制就叫存儲引擎）
SQL語句執行過程
資料庫通常不會被直接使用，而是由其他編程語言通過SQL語句調用mysql，由mysql處理並返回執行結果。那麼Mysql接受到SQL語句後，又是如何處理
首先程序的請求會通過mysql的connectors與其進行交互，請求到處後，會暫時存放在連接池（connection pool)中並由處理器（Management Serveices & Utilities）管理。當該請求從等待隊列進入到處理隊列，管理器會將該請求丟給SQL介面（SQL Interface）。SQL介面接收到請求後，它會將請求進行hash處理並與緩存中的結果進行對比，如果完全匹配則通過緩存直接返回處理結果；否則，需要完整的走一趟流程：
(1)由SQL介面丟給後面的解釋器（Parser），解釋器會判斷SQL語句正確與否，若正確則將其轉化為數據結構。
(2)解釋器處理完，便來到後面的優化器（Optimizer），它會產生多種執行計劃,最終資料庫會選擇最優化的方案去執行,盡快返會結果。
(3)確定最優執行計劃後，SQL語句此時便可以交由存儲引擎（Engine）處理，存儲引擎將會到後端的存儲設備中取得相應的數據，並原路返回給程序。
注意點
(1)如何緩存查詢數據
存儲引擎處理完數據，並將其返回給程序的同時，它還會將一份數據保留在緩存中，以便更快速的處理下一次相同的請求。具體情況是，mysql會將查詢的語句、執行結果等進行hash，並保留在cache中，等待下次查詢。
(2)buffer與cache的區別
從mysql原理圖可以看到，緩存那裡實際上有buffer和cache兩個，那它們之間的區別：簡單的說就是，buffer是寫緩存，cache是讀緩存。
(3)如何判斷緩存中是否已緩存需要的數據
這里可能有一個誤區，覺得處理SQL語句的時候，為了判斷是否已緩存查詢結果，會將整個流程走一遍，取得執行結果後再與需要的進行對比，看看是否命中，並以此說，既然不管緩存中有沒有緩存到查詢內容，都要整個流程走一遍，那緩存的優勢在哪？
其實並不是這樣，在第一次查詢後，mysql便將查詢語句以及查詢結果進行hash處理並保留在緩存中，SQL查詢到達之後，對其進行同樣的hash處理後，將兩個hash值進行對照，如果一樣，則命中，從緩存中返回查詢結果；否則，需要整個流程走一遍。
3. mysql資料庫的事務隔離級別有哪些
事務隔離級別的方法：
1.全局修改，修改mysql.ini配置文件，在最後加上
1 #可選參數有：READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE.
2 [mysqld]
3 transaction-isolation = REPEATABLE-READ
這里全局默認是REPEATABLE-READ,其實MySQL本來默認也是這個級別
2.對當前session修改，在登錄mysql客戶端後，執行命令：
set session transaction isolation level read uncommitted;
要記住mysql有一個autocommit參數，默認是on，他的作用是每一條單獨的查詢都是一個事務，並且自動開始，自動提交（執行完以後就自動結束了，如果你要適用select for update，而不手動調用 start transaction，這個for update的行鎖機制等於沒用，因為行鎖在自動提交後就釋放了），所以事務隔離級別和鎖機制即使你不顯式調用start transaction，這種機制在單獨的一條查詢語句中也是適用的，分析鎖的運作的時候一定要注意這一點
4. mysql資料庫事務是什麼，能簡單定義一下嗎
在創建表的時候create table xxxx ( ..........) engine innoDB; 後一句表示創建引擎類型為innoDB，它支持事務，
開啟一個事務： start transaction;
然後你寫你的sql語句，無論你寫多少，只要沒提交事務，這個事務就存在，有commit顯式提交，還有隱式提交，你覺得你寫的sql語句沒有問題時就，你就commit; 提交這個事務；如果前面你寫的sql語句出了問題，比如有條sql語句是批量改金幣什麼的，改多了。 Rollback;回滾，意思是回到你開啟事務時的狀態，就是說你開啟事務後的所有sql操作當作沒有發生，你重新來過。
注意：當一個事務commit,或者rollback就結束了
5. 資料庫老師會問哪些問題
1.MySQL 主鍵與索引的聯系與區別
主鍵是為了標識資料庫記錄唯一性，不允許記錄重復，且鍵值不能為空，主鍵也是一個特殊索引。
數據表中只允許有一個主鍵，但是可以有多個索引。
使用主鍵會資料庫會自動創建主索引，也可以在非主鍵上創建索引，方便查詢效率。
索引可以提高查詢速度，它就相當於字典的目錄，可以通過它很快查詢到想要的結果，而不需要進行全表掃描。
主鍵索引外索引的值可以為空。
主鍵也可以由多個欄位組成，組成復合主鍵，同時主鍵肯定也是唯一索引。
唯一索引則表示該索引值唯一，可以由一個或幾個欄位組成，一個表可以有多個唯一索引。
2.資料庫索引是怎麼回事？用的啥數據結構 為什麼B+樹比B樹更合適
一個索引是存儲的表中一個特定列的值數據結構（最常見的是B-Tree）。索引是在表的列上創建。所以，要記住的關鍵點是索引包含一個表中列的值，並且這些值存儲在一個數據結構中。請記住記住這一點：索引是一種數據結構 。
什麼樣的數據結構可以作為索引？
B-Tree 是最常用的用於索引的數據結構。因為它們是時間復雜度低， 查找、刪除、插入操作都可以可以在對數時間內完成。另外一個重要原因存儲在B-Tree中的數據是有序的。資料庫管理系統（RDBMS）通常決定索引應該用哪些數據結構。但是，在某些情況下，你在創建索引時可以指定索引要使用的數據結構。
當我們利用索引查詢的時候，不可能把整個索引全部載入到內存，只能逐一載入每個磁碟頁，磁碟頁對應索引樹的節點。那麼Mysql衡量查詢效率的標准就是磁碟IO次數。如果我們利用二叉樹作為索引結構，那麼磁碟的IO次數和索引樹的高度是相關的。
那麼為了提高查詢效率，就需要減少磁碟IO數。為了減少磁碟IO的次數，就需要盡量降低樹的高度，需要把原來「瘦高」的樹結構變的「矮胖」，樹的每層的分叉越多越好，因此B樹正好符合我們的要求，這也是B-樹的特徵之一。
B樹 B樹的節點為關鍵字和相應的數據（索引等）
B+樹 B+樹是B樹的一個變形，非葉子節點只保存索引，不保存實際的數據，數據都保存在葉子節點中，B+樹的葉子節點為鏈表，鏈表放數據，非葉子節點是索引。
對比：
B樹和B+樹同樣適用於高度越低，查詢越快。
B樹查找節點，B+樹只需要查詢所有節點（索引），B樹查詢索引和數據。雖然可能第一個就找到，但在極端情況下，需要全查詢索引和數據，不如B+樹穩定。
B+樹和B樹比，B+樹的硬碟空間更少，io的讀寫代價更低。因為B+樹節點只有索引，佔位更少。在查詢的情況下硬碟指針移動更低
表的主鍵、外鍵必須有索引；
數據量超過300的表應該有索引；
經常與其他表進行連接的表，在連接欄位上應該建立索引；
經常出現在Where子句中的欄位，特別是大表的欄位，應該建立索引；
索引應該建在選擇性高的欄位上；
索引應該建在小欄位上，對於大的文本欄位甚至超長欄位，不要建索引；
復合索引的建立需要進行仔細分析；盡量考慮用單欄位索引代替
頻繁進行數據操作的表，不要建立太多的索引；
刪除無用的索引，避免對執行計劃造成負面影響；
限製表上的索引數目。對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。
避免在取值朝一個方向增長的欄位（例如：日期類型的欄位）上，建立索引；對復合索引，避免將這種類型的欄位放置在最前面
對復合索引，按照欄位在查詢條件中出現的頻度建立索引
刪除不再使用，或者很少被使用的索引。
性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。
豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操作。
原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並後的原子性執行。
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，並發度最低。
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，並發度也最高。
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般
哈希表索引是怎麼工作的？
哈希表是另外一種你可能看到用作索引的數據結構-這些索引通常被稱為哈希索引。使用哈希索引的原因是，在尋找值時哈希表效率極高。所以，如果使用哈希索引，對於比較字元串是否相等的查詢能夠極快的檢索出的值。例如之前我們討論過的這個查詢(SELECT * FROM Employee WHERE Employee_Name = 『Jesus』) 就可以受益於創建在Employee_Name 列上的哈希索引。哈系索引的工作方式是將列的值作為索引的鍵值（key），和鍵值相對應實際的值（value）是指向該表中相應行的指針。因為哈希表基本上可以看作是關聯數組，一個典型的數據項就像「Jesus => 0x28939″，而0x28939是對內存中表中包含Jesus這一行的引用。在哈系索引的中查詢一個像「Jesus」這樣的值，並得到對應行的在內存中的引用，明顯要比掃描全表獲得值為「Jesus」的行的方式快很多。
哈希索引的缺點
哈希表是無順的數據結構，對於很多類型的查詢語句哈希索引都無能為力。舉例來說，假如你想要找出所有小於40歲的員工。你怎麼使用使用哈希索引進行查詢？這不可行，因為哈希表只適合查詢鍵值對-也就是說查詢相等的查詢（例：like 「WHERE name = 『Jesus』）。哈希表的鍵值映射也暗示其鍵的存儲是無序的。這就是為什麼哈希索引通常不是資料庫索引的默認數據結構-因為在作為索引的數據結構時，其不像B-Tree那麼靈活
3.創建索引的注意事項
索引可以提高數據的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間，解決此問題就是分析應用程序的業務處理、數據使用，為經常被用作查詢條件、或者被要求排序的欄位建立索引。索引是建立在資料庫表中的某些列的上面。因此，在創建索引的時候，應該仔細考慮在哪些列上可以創建索引，在哪些列上不能創建索引。
創建規則：
創建索引需要注意的地方：
4.MYSQL事務特性和實現原理
ACID表示原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（rability）。一個很好的事務處理系統，必須具備這些標准特性：
原子性（atomicity）
一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾，對於一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性
是利用Innodb的undo log。undo log名為回滾日誌，是實現原子性的關鍵，當事務回滾時能夠撤銷所有已經成功執行的sql語句，他需要記錄你要回滾的相應日誌信息。
一致性（consistency）
資料庫總是從一個一致性的狀態轉換到另一個一致性的狀態。（在前面的例子中，一致性確保了，即使在執行第三、四條語句之間時系統崩潰，支票賬戶中也不會損失200美元，因為事務最終沒有提交，所以事務中所做的修改也不會保存到資料庫中。）
資料庫通過原子性、隔離性、持久性來保證一致性
隔離性（isolation）
通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。（在前面的例子中，當執行完第三條語句、第四條語句還未開始時，此時有另外的一個賬戶匯總程序開始運行，則其看到支票帳戶的余額並沒有被減去200美元。）
利用的是鎖和MVCC機制。MVCC,即多版本並發控制(Multi Version Concurrency Control),一個行記錄數據有多個版本對快照數據，這些快照數據在undo log中。如果一個事務讀取的行正在做DELELE或者UPDATE操作，讀取操作不會等行上的鎖釋放，而是讀取該行的快照版本。
持久性（rability）
一旦事務提交，則其所做的修改會永久保存到資料庫。（此時即使系統崩潰，修改的數據也不會丟失。持久性是個有占模糊的概念，因為實際上持久性也分很多不同的級別。有些持久性策略能夠提供非常強的安全保障，而有些則未必，而且不可能有能做到100%的持久性保證的策略。）
是利用Innodb的redo log。當做數據修改的時候，不僅在內存中操作，還會在redo log中記錄這次操作。當事務提交的時候，會將redo log日誌進行刷盤(redo log一部分在內存中，一部分在磁碟上)。當資料庫宕機重啟的時候，會將redo log中的內容恢復到資料庫中，再根據undo log和binlog內容決定回滾數據還是提交數據。redo log體積小，刷盤快。redo log是一直往末尾進行追加，屬於順序IO。效率顯然比隨機IO來的快
5.redis的原理和優點
redis是一個key-value存儲系統.和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hashs（哈希類型）
這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的.
在此基礎上，redis支持各種不同方式的排序.與memcached一樣，為了保證效率，數據都是緩存在內存中.區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步.
Redis的優點:
6.Mysql中的鎖機制
Mysql用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。這些鎖統稱為悲觀鎖
MySQL的鎖機制比較簡單，其最 顯著的特點是不同的存儲引擎支持不同的鎖機制。比如，MyISAM和MEMORY存儲引擎採用的是表級鎖（table-level locking）；BDB存儲引擎採用的是頁面鎖（page-level locking），但也支持表級鎖；InnoDB存儲引擎既支持行級鎖（row-level locking），也支持表級鎖，但默認情況下是採用行級鎖。
從上述特點可見，很難籠統地說哪種鎖更好，只能就具體應用的特點來說哪種鎖更合適！僅從鎖的角度 來說：表級鎖更適合於以查詢為主，只有少量按索引條件更新數據的應用，如Web應用；而行級鎖則更適合於有大量按索引條件並發更新少量不同數據，同時又有 並發查詢的應用，如一些在線事務處理（OLTP）系統。
7.ABC聯合索引生效問題
對於復合索引：Mysql從左到右的使用索引中的欄位，一個查詢可以只使用索引中的一部份，但只能是最左側部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側欄位是常量引用時，索引就十分有效。
對於復合索引：Mysql從左到右的使用索引中的欄位，一個查詢可以只使用索引中的一部份，但只能是最左側部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側欄位是常量引用時，索引就十分有效。
6. MySQL資料庫存儲過程和事務的區別
事務是保證多個SQL語句的原子型的，也就是要麼一起完成，要麼一起不完成
存儲過程是把一批SQL語句預編譯後放在伺服器上，然後可以遠程調用
二者完全不是可對比的關系。
7. mysql有什麼好的特性
增加了一個線程事件處理層
支持auth-response改變
新增了timing infrastruture
新增了out-of-tree plugins build和pkg-config的支持
以及一些bug的修復
……
MySQL Proxy還支持嵌入性腳本語言Lua。這個代理可以用來分析、監控和變換（transform）通信數據，它支持非常廣泛的使用場景：
負載平衡和故障轉移處理
查詢分析和日誌
SQL宏（SQL macros）
查詢重寫（query rewriting）
執行shell命令
MySQL Proxy更強大的一項功能是實現「讀寫分離（Read/Write Splitting）」。基本的原理是讓主資料庫處理事務性查詢，而從資料庫處理SELECT查詢。資料庫復制被用來把事務性查詢導致的變更同步到集群中的從資料庫。