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+樹節點只有索引，占位更少。在查詢的情況下硬盤指針移動更低
哈希表索引是怎麽工作的？
哈希表是另外壹種妳可能看到用作索引的數據結構-這些索引通常被稱為哈希索引。使用哈希索引的原因是，在尋找值時哈希表效率極高。所以，如果使用哈希索引，對於比較字符串是否相等的查詢能夠極快的檢索出的值。例如之前我們討論過的這個查詢(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.創建索引的註意事項
索引可以提高數據的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間，解決此問題就是分析應用程序的業務處理、數據使用，為經常被用作查詢條件、或者被要求排序的字段建立索引。索引是建立在數據庫表中的某些列的上面。因此，在創建索引的時候，應該仔細考慮在哪些列上可以創建索引，在哪些列上不能創建索引。
創建規則：
表的主鍵、外鍵必須有索引；
數據量超過300的表應該有索引；
經常與其他表進行連接的表，在連接字段上應該建立索引；
經常出現在Where子句中的字段，特別是大表的字段，應該建立索引；
索引應該建在選擇性高的字段上；
索引應該建在小字段上，對於大的文本字段甚至超長字段，不要建索引；
復合索引的建立需要進行仔細分析；盡量考慮用單字段索引代替
頻繁進行數據操作的表，不要建立太多的索引；
刪除無用的索引，避免對執行計劃造成負面影響；
創建索引需要註意的地方：
限制表上的索引數目。對壹個存在大量更新操作的表，所建索引的數目壹般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。
避免在取值朝壹個方向增長的字段（例如：日期類型的字段）上，建立索引；對復合索引，避免將這種類型的字段放置在最前面
對復合索引，按照字段在查詢條件中出現的頻度建立索引
刪除不再使用，或者很少被使用的索引。
4.MYSQL事務特性和實現原理
ACID表示原子性（atomicity）、壹致性（consistency）、隔離性（isolation）和持久性（durability）。壹個很好的事務處理系統，必須具備這些標準特性：
原子性（atomicity）
壹個事務必須被視為壹個不可分割的最小工作單元，整個事務中的所有操作要麽全部提交成功，要麽全部失敗回滾，對於壹個事務來說，不可能只執行其中的壹部分操作，這就是事務的原子性
是利用Innodb的undo log。undo log名為回滾日誌，是實現原子性的關鍵，當事務回滾時能夠撤銷所有已經成功執行的sql語句，他需要記錄妳要回滾的相應日誌信息。
壹致性（consistency）
數據庫總是從壹個壹致性的狀態轉換到另壹個壹致性的狀態。（在前面的例子中，壹致性確保了，即使在執行第三、四條語句之間時系統崩潰，支票賬戶中也不會損失200美元，因為事務最終沒有提交，所以事務中所做的修改也不會保存到數據庫中。）
數據庫通過原子性、隔離性、持久性來保證壹致性
隔離性（isolation）
通常來說，壹個事務所做的修改在最終提交以前，對其他事務是不可見的。（在前面的例子中，當執行完第三條語句、第四條語句還未開始時，此時有另外的壹個賬戶匯總程序開始運行，則其看到支票帳戶的余額並沒有被減去200美元。）
利用的是鎖和MVCC機制。MVCC,即多版本並發控制(Multi Version Concurrency Control),壹個行記錄數據有多個版本對快照數據，這些快照數據在undo log中。如果壹個事務讀取的行正在做DELELE或者UPDATE操作，讀取操作不會等行上的鎖釋放，而是讀取該行的快照版本。
持久性（durability）
壹旦事務提交，則其所做的修改會永久保存到數據庫。（此時即使系統崩潰，修改的數據也不會丟失。持久性是個有占模糊的概念，因為實際上持久性也分很多不同的級別。有些持久性策略能夠提供非常強的安全保障，而有些則未必，而且不可能有能做到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的優點:
性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。
豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操作。
原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並後的原子性執行。
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
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進行查找 .當最左側字段是常量引用時，索引就十分有效。