1、insert時如果數據重復如何用update？
INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1;
2、一張表，里面有 ID 自增主鍵，當 insert 了 17 條記錄之后，刪除了第 15,16,17 條記錄，
再把 Mysql 重啟，再 insert 一條記錄，這條記錄的 ID 是 18 還是 15 ？
(1)如果表的類型是 MyISAM，那么是 18 因為 MyISAM 表會把自增主鍵的最大 ID 記錄到數據文件里，重啟 MySQL 自增主鍵的最大ID 也不會丟失 （2）如果表的類型是 InnoDB，那么是 15 InnoDB 表只是把自增主鍵的最大 ID 記錄到內存中，所以重啟數據庫或者是對表進行OPTIMIZE 操作，都會導致最大 ID 丟失
3 、[SELECT *] 和[SELECT 全部字段]的 2 種寫法有何優缺點?
1. 前者要解析數據字典，后者不需要 2. 結果輸出順序，前者與建表列順序相同，后者按指定字段順序。 3. 表字段改名，前者不需要修改，后者需要改 4. 后者可以建立索引進行優化，前者無法優化 5. 后者的可讀性比前者要高
所以，盡量使用后者來查詢
4、若一張表中只有一個字段 VARCHAR(N)類型，utf8 編碼，則 N 最大值為多少?
由於 utf8 的每個字符最多占用 3 個字節。而 MySQL 定義行的長度不能超過65535（text和blob不計算在內），因此 N 的最大值計算方法為：(65535-1-2)/3。減去 1 的原因是實 際存儲從第二個字節開始，減去 2 的原因是因為要在列表長度存儲實際的字符長度（長度大於256用兩個字節存儲），除以 3 是因為 utf8 限制：每個字符最多占用 3 個字節。
5、MySQL 中 InnoDB 引擎的行鎖是通過加在什么上完成（或稱實現）的？
InnoDB 行鎖是通過給索引上的索引項加鎖來實現的，這一點 MySQL 與Oracle 不同，后者是通過在數據塊中對相應數據行加鎖來實現的。
InnoDB 這種行鎖實現特點意味着：只有通過索引條件檢索數據，InnoDB 才使用行級鎖，否則，InnoDB 將使用表鎖
6、 mysql 中 myisam 與 innodb 的區別？
1. 事務支持
MyISAM：強調的是性能，每次查詢具有原子性,其執行數度比 InnoDB 類型更快，但是不提供事務支持。
InnoDB：提供事務支持事務，外部鍵等高級數據庫功能。具有事務(commit)、回滾(rollback)和崩潰修復能力(crash recovery capabilities)的事務安全(transaction-safe (ACID compliant))型表。
2. InnoDB 支持行級鎖，而 MyISAM 支持表級鎖.
用戶在操作myisam 表時，select，update，delete，insert 語句都會給表自動加鎖，如果加鎖以后的表滿足 insert 並發的情況下，可以在表的尾部插入新的數據。
3. InnoDB 支持 MVCC, 而 MyISAM 不支持 (MVCC：Multi-Version Concurrency Control 多版本並發控制)
4. InnoDB 支持外鍵，而 MyISAM 不支持
5. 表主鍵
MyISAM：允許沒有任何索引和主鍵的表存在，索引都是保存行的地址。
InnoDB：如果沒有設定主鍵或者非空唯一索引，就會自動生成一個 6 字節的主鍵(用戶不可見)，數據是主索引的一部分，附加索引保存的是主索引的值。
6. InnoDB 不支持全文索引，而 MyISAM 支持。
7. 可移植性、備份及恢復
MyISAM：數據是以文件的形式存儲，所以在跨平台的數據轉移中會很方便。在備份和恢復時可單獨針對某個表進行操作
InnoDB：免費的方案可以是拷貝數據文件、備份binlog，或者用 mysqldump，在數據量達到幾十 G 的時候就相對痛苦了
8. 存儲結構
MyISAM：每個 MyISAM 在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始，擴展名指出文件類型。.frm 文件存儲表定義。數據文件的擴展名為.MYD (MYData)。索引文件的擴展名是.MYI (MYIndex)。
InnoDB：所有的表都保存在同一個數據文件中（也可能是多個文件，或者是獨立的表空間文件），InnoDB 表的大小只受限於操作系統文件的大小，一般為 2GB。
7、mysql 的復制原理以及流程
Mysql 內建的復制功能是構建大型，高性能應用程序的基礎。將 Mysql 的數據分布到多個系統上去，這種分布的機制，是通過將 Mysql 的某一台主機的數據復制到其它主機（slaves）上，並重新執行一遍來實現的。
復制過程中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。主服務器將更新寫入二進制日志文件，並維護文件的一個索引以跟蹤日志循環。這些日志可以記錄發送到從服務器的更新。
當一個從服務器連接主服務器時，它通知主服務器在日志中讀取的最后一次成功更新的位置。從服務器接收從那時起發生的任何更新，然后封鎖並等待主服務器通知新的更新。
過程如下
1. 主服務器把更新記錄到二進制日志文件中。
2. 從服務器把主服務器的二進制日志拷貝到自己的中繼日志（replay log）中。
3. 從服務器重做中繼日志中的時間，把更新應用到自己的數據庫上。
8、請簡述常用的索引有哪些種類?
1. 普通索引: 即針對數據庫表創建索引 2. 唯一索引: 與普通索引類似，不同的就是：MySQL 數據庫索引列的值必須唯一，但允許有空值 3. 主鍵索引: 它是一種特殊的唯一索引，不允許有空值。一般是在建表的時候同時創建主鍵索引 4. 組合索引: 將數據庫表中的多個字段聯合起來作為一個組合索引
9、Mysql的四種事務隔離級別
1. Read Uncommitted（讀取未提交內容）
在該隔離級別，所有事務都可以看到其他未提交事務的執行結果。本隔離級別很少用於實際應用，因為它的性能也不比其他級別好多少。讀取未提交的數據，也被稱之為臟讀（Dirty Read）。
2. Read Committed（讀取提交內容）
這是大多數數據庫系統的默認隔離級別（但不是 MySQL 默認的）。它滿足了隔離的簡單定義：一個事務只能看見已經提交事務所做的改變。這種隔離級別也支持所謂的不可重復讀（Nonrepeatable Read），
因為同一事務的其他實例在該實例處理其間可能會有新的 commit，所以同一 select 可能返回不同結果。
3. Repeatable Read（可重讀）
這是 MySQL 的默認事務隔離級別，它確保同一事務的多個實例在並發讀取數據時，會看到同樣的數據行。不過理論上，這會導致另一個棘手的問題：幻讀（PhantomRead）。
簡單的說，幻讀指當用戶讀取某一范圍的數據行時，另一個事務又在該范圍內插入了新行，當用戶再讀取該范圍的數據行時，會發現 有新的“幻影” 行。InnoDB 和 Falcon 存儲引擎通過多版本並發控制（MVCC，Multiversion Concurrency Control 間隙鎖）機制解決了該問題。
注：其實多版本只是解決不可重復讀問題，而加上間隙鎖（也就是它這里所謂的並發控制）才解決了幻讀問題。
4. Serializable（可串行化）
這是最高的隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，它是在每個讀的數據行上加上共享鎖。
在這個級別，可能導致大量的超時現象和鎖競爭。
10、數據庫三范式（老生常談）
1. 第一范式（1NF）：字段具有原子性,不可再分。(所有關系型數據庫系統都滿足第一范式數據庫表中的字段都是單一屬性的，不可再分) => 關於列的設計 2. 第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。要求數據庫表中的每個實例或行必須可以被惟一地區分。=> 關於行的設計
通常需要為表加上一個列，以存儲各個實例的惟一標識。這個惟一屬性列被稱為主關鍵字或主鍵。 3. 滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。 => 關於表的設計拆分
所以第三范式具有如下特征： >>1. 每一列只有一個值 >>2. 每一行都能區分。 >>3. 每一個表字段都不依賴於除了主鍵外的其它列，否則，應當拆分表
所以，記住行、列、表三個字即可