資料庫相關

1.InnoDB的日誌

InnoDB有很多日誌,日誌中有2個概念需要分清楚,邏輯日誌和物理日誌.

• 1.1 邏輯日誌
  有關操作的信息日誌成為邏輯日誌.
  比如,插入一條數據,undo邏輯日誌的格式大致如下:
  <Ti,Qj,delete,U> Ti表示事務id,U表示Undo信息,Qj表示某次操作的唯一標示符

  undo日誌總是這樣:
  1). insert操作,則記錄一條delete邏輯日誌. 
  2). delete操作,則記錄一條insert邏輯日誌.
  3). update操作,記錄相反的update,將修改前的行改回去.

• 1.2 物理日誌
  新值和舊值的信息日誌稱為物理日誌. <Ti,Qj,V> 物理日誌

  binlog(二進位日誌)就是典型的邏輯日誌,而事務日誌(redo log)則記錄的物理日誌,他們的區別是什麼呢?

  1. redo log 是在存儲引擎層產生的,binlog是在資料庫上層的一種邏輯日誌,任何存儲引擎均會產生binlog.
  2. binlog記錄的是sql語句, 重做日誌則記錄的是對每個頁的修改.
  3. 寫入的時間點不一樣. binlog是在事務提交後進行一次寫入,redo log在事務的進行中不斷的被寫入.
  4. redo log是等冪操作(執行多次等於執行一次,redo log記錄<T0,A,950>記錄新值,執行多少次都一樣),binlog不一樣;

• 1.3 日誌種類
  錯誤日誌：記錄出錯信息，也記錄一些警告信息或者正確的信息。
  查詢日誌：記錄所有對資料庫請求的信息，不論這些請求是否得到了正確的執行。
  慢查詢日誌：設置一個閾值，將運行時間超過該值的所有SQL語句都記錄到慢查詢的日誌文件中。 二進位日誌：記錄對資料庫執行更改的所有操作。
  中繼日誌、事務日誌等。

• 1.4 總結
  1, redo log(事務日誌)保證事務的原子性和持久性(物理日誌)
  2, undo log保證事務的一致性,InnoDB的MVCC(多版本併發控制)也是用undo log來實現的(邏輯日誌).
  3, redo log中帶有有checkPoint,用來高效的恢複數據.
  4, 物理日誌記錄的是修改頁的的詳情,邏輯日誌記錄的是操作語句. 物理日誌恢復的速度快於邏輯日誌.

2.事務的實現原理

事務的作用: 事務會把資料庫從一種一致的狀態轉換為另一種一致狀態。

事務的機制通常被概括為“ACID”原則即原子性（A）、一致性（C）、隔離性（I）和持久性（D）。

1. 原子性：構成事務的的所有操作必須是一個邏輯單元，要麼全部執行，要麼全部不執行。
2. 一致性：資料庫在事務執行前後狀態都必須是穩定的。
3. 隔離性：事務之間不會相互影響。
4. 持久性：事務執行成功後必須全部寫入磁碟。

2.1 事務的隔離性由存儲引擎的鎖來實現

　　資料庫事務會導致臟讀、不可重覆讀和幻影讀等問題。
　　1)臟讀：事務還沒提交，他的修改已經被其他事務看到。
　　2)不可重覆讀：同一事務中兩個相同SQL讀取的內容可能不同。兩次讀取之間其他事務提交了修改可能會造成讀取數據不一致。
　　3)幻影數據：同一個事務突然發現他以前沒發現的數據。和不可重覆讀很類似，不過修改數據改成增加數據。

InnoDB提供了四種不同級別的機制保證數據隔離性。
不同於MyISAM使用表級別的鎖，InnoDB採用更細粒度的行級別鎖，提高了數據表的性能。InnoDB的鎖通過鎖定索引來實現，如果查詢條件中有主鍵則鎖定主鍵，如果有索引則先鎖定對應索引然後再鎖定對應的主鍵（可能造成死鎖），如果連索引都沒有則會鎖定整個數據表。

4種隔離級別： 
1) READ UNCOMMITTED(未提交讀)
事務中的修改,即使沒有提交,對其它事務也是可見的. 臟讀(Dirty Read).
2) READ COMMITTED(提交讀)
一個事務開始時,只能"看見"已經提交的事務所做的修改. 這個級別有時候也叫不可重覆讀(nonrepeatable read).
3) REPEATABLE READ(可重覆讀)
該級別保證了同一事務中多次讀取到的同樣記錄的結果是一致的. 但理論上,該事務級別還是無法解決另外一個幻讀的問題(Phantom Read). 
幻讀: 當某個事務讀取某個範圍內的記錄時,另外一個事務又在該範圍內插入了新的記錄.當之前的事務再次讀取該範圍時,會產生幻行.(Phantom Row).
幻讀的問題理應由更高的隔離級別來解決,但mysql和其它資料庫不一樣,它同樣在可重覆讀的隔離級別解決了這個問題. 
mysql的可重覆讀的隔離級別解決了"不可重覆讀"和“幻讀”2個問題. 
而oracle資料庫,可能需要在“SERIALIZABLE”事務隔離級別下才能解決幻讀問題.
mysql預設的隔離級別也是:REPEATABLE READ(可重覆讀)
4) SERIALIZABLE (可串列化)
強制事務串列執行,避免了上面說到的 臟讀,不可重覆讀,幻讀 三個的問題.

2.2 原子性和持久性的實現

redo log 稱為重做日誌(也叫事務日誌),用來保證事務的原子性和持久性. 
redo恢復提交事務修改的頁操作,redo是物理日誌,頁的物理修改操作.

當提交一個事務時,實際上它幹了如下2件事:
一: InnoDB存儲引擎把事務寫入日誌緩衝(log buffer),日誌緩衝把事務刷新到事務日誌.
二: InnoDB存儲引擎把事務寫入緩衝池(Buffer pool).

這裡有個問題, 事務日誌也是寫磁碟日誌,為什麼不需要雙寫技術？
因為事務日誌塊的大小和磁碟扇區的大小一樣,都是512位元組,因此事務日誌的寫入可以保證原子性，不需要doublewrite技術

重做日誌緩衝是由每個為512位元組大小的日誌塊組成的. 日誌塊分為三部分: 日誌頭(12位元組),日誌內容(492位元組),日誌尾(8位元組).

2.3 一致性的實現

undo log 用來保證事務的一致性. undo 回滾行記錄到某個特定版本,undo 是邏輯日誌,根據每行記錄進行記錄.
undo 存放在資料庫內部的undo段,undo段位於共用表空間內.
undo 只把資料庫邏輯的恢復到原來的樣子.

undo日誌除了回滾作用之外, undo 實現MVCC(多版本併發控制),讀取一行記錄時,發現事務鎖定,通過undo恢復到之前的版本,實現非鎖定讀取.

    myisam引擎不支持事務, innodb和BDB引擎支持

3. 索引有什麼用

• 作用：索引是與表或視圖關聯的磁碟上結構，可以加快從表或視圖中檢索行的速度。索引包含由表或視圖中的一列或多列生成的鍵。這些鍵存儲在一個結構（B樹）中，使資料庫可以快速有效地查找與鍵值關聯的行。

• 設計良好的索引可以減少磁碟 I/O 操作，並且消耗的系統資源也較少，從而可以提高查詢性能。

• 一般來說，應該在這些列 上創建索引，例如：
  在經常需要搜索的列上，可以加快搜索的速度；
  在作為主鍵的列上，強制該列的唯一性和組織表中數據的排列結構；
  在經常用在連接的列上，這 些列主要是一些外鍵，可以加快連接的速度；
  在經常需要根據範圍進行搜索的列上創建索引，因為索引已經排序，其指定的範圍是連續的； 
  在經常需要排序的列上創 建索引，因為索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間；
  在經常使用在WHERE子句中的列上面創建索引，加快條件的判斷速度。

• 索引的缺點：
  第一，創建索引和維護索引要耗費時間，這種時間隨著數據 量的增加而增加。 
  第二，索引需要占物理空間，除了數據表占數據空間之外，每一個索引還要占一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。 
  第三，當對錶中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度。

4.資料庫優化相關

• 臨時表在如下幾種情況被創建(臨時表會消耗性能):
  1、如果group by 的列沒有索引,必產生內部臨時表。
  2、如果order by 與group by為不同列時,或多表聯查時order by ,group by 包含的列不是第一張表的列,將會產生臨時表 
  3、distinct 與order by 一起使用可能會產生臨時表
  4、如果使用SQL_SMALL_RESULT,MySQL會使用記憶體臨時表,除非查詢中有一些必須要把臨時表建立在磁碟上.
  5、union合併查詢時會用到臨時表
  6、某些視圖會用到臨時表,如使用temptable方式建立,或使用union或聚合查詢的視圖 想確定查詢是否需要臨時表,可以用EXPLAIN查詢計劃,並查看Extra列,看是否有Using temporary.

• 建表: 表結構的拆分,如核心欄位都用int,char,enum等定長結構
  非核心欄位,或用到text,超長的varchar,拆出來單放一張表.
  建索引: 合理的索引可以減少內部臨時表 
  寫語句: 不合理的語句將導致大量數據傳輸以及內部臨時表的使用

• 表的優化與列類型選擇
  表的優化:
  1: 定長與變長分離
  如 id int, 占4個位元組, char(4) 占4個字元長度,也是定長, time 
  即每一單元值占的位元組是固定的.
  核心且常用欄位,宜建成定長,放在一張表.
  而varchar, text,blob,這種變長欄位,適合單放一張表, 用主鍵與核心表關聯起來.
  2:常用欄位和不常用欄位要分離.
  需要結合網站具體的業務來分析,分析欄位的查詢場景,查詢頻度低的欄位,單拆出來.
  3:合理添加冗餘欄位.

• 列選擇原則:
  1:欄位類型優先順序 整型 > date,time > enum,char > varchar > blob

  列的特點分析:
  整型: 定長,沒有國家/地區之分,沒有字元集的差異
  time定長,運算快,節省空間. 考慮時區,寫sql時不方便 where > ‘2005-10-12’;
  enum: 能起來約束值的目的, 內部用整型來存儲,但與char聯查時,內部要經歷串與值的轉化 Char 定長, 考慮字元集和(排序)校對集 varchar, 不定長 要考慮字元集的轉換與排序時的校對集,速度慢.相比於char增加了一個長度標識，處理時需要多運算一次。 text/Blob 無法使用記憶體臨時表

  附: 關於date/time的選擇,明確意見 http://www.xaprb.com/blog/2014/01/30/timestamps-in-mysql/

  2: 夠用就行,不要慷慨 (如smallint,varchar(N))
  原因: 大的欄位浪費記憶體,影響速度
  以年齡為例 tinyint unsigned not null ,可以存儲255歲,足夠. 用int浪費了3個位元組 以varchar(10) ,varchar(300)存儲的內容相同, 但在表聯查時,varchar(300)要花更多記憶體

  3: 儘量避免用NULL()
  原因: NULL不利於索引,要用特殊的位元組來標註. 每一行多了一個位元組在磁碟上占據的空間其實更大.

  Enum列的說明
  1: enum列在內部是用整型來儲存的
  2: enum列與enum列相關聯速度最快
  3: enum列比(var)char 的弱勢---在碰到與char關聯時,要轉化. 要花時間.
  4: 優勢在於,當char非常長時,enum依然是整型固定長度.當查詢的數據量越大時,enum的優勢越明顯.
  5: enum與char/varchar關聯 ,因為要轉化,速度要比enum->enum,char->char要慢,但有時也這樣用-----就是在數據量特別大時,可以節省IO.

• SQL語句優化
  1）應儘量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
  2）應儘量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
  select id from t where num is null
  可以在num上設置預設值0，確保表中num列沒有null值，然後這樣查詢：
  select id from t where num=0
  3）很多時候用 exists 代替 in 是一個好的選擇
  4）用Where子句替換HAVING 子句 因為HAVING 只會在檢索出所有記錄之後才對結果集進行過濾

• explain出來的各種item的意義；
  select_type 
  表示查詢中每個select子句的類型
  type
  表示MySQL在表中找到所需行的方式，又稱“訪問類型”
  possible_keys 
  指出MySQL能使用哪個索引在表中找到行，查詢涉及到的欄位上若存在索引，則該索引將被列出，但不一定被查詢使用
  key
  顯示MySQL在查詢中實際使用的索引，若沒有使用索引，顯示為NULL
  key_len
  表示索引中使用的位元組數，可通過該列計算查詢中使用的索引的長度
  ref
  表示上述表的連接匹配條件，即哪些列或常量被用於查找索引列上的值 
  Extra
  包含不適合在其他列中顯示但十分重要的額外信息
  
  
• profile的意義以及使用場景；
  查詢到 SQL 會執行多少時間, 並看出 CPU/Memory 使用量, 執行過程中 Systemlock, Table lock 花多少時間等等

索引優化策略

• 1 索引類型

  1.1 B-tree索引
  註: 名叫btree索引,大的方面看,都用的平衡樹,但具體的實現上, 各引擎稍有不同,比如,嚴格的說,NDB引擎,使用的是T-tree，Myisam,innodb中,預設用B-tree索引，但抽象一下---B-tree系統,可理解為”排好序的快速查找結構”.

  1.2 hash索引
  在memory表裡,預設是hash索引, hash的理論查詢時間複雜度為O(1)

  疑問: 既然hash的查找如此高效,為什麼不都用hash索引?
  答: 
  1)hash函數計算後的結果,是隨機的,如果是在磁碟上放置數據,比主鍵為id為例, 那麼隨著id的增長, id對應的行,在磁碟上隨機放置.
  2)不法對範圍查詢進行優化.
  3)無法利用首碼索引. 比如 在btree中, field列的值“hellopworld”,並加索引 查詢 xx=helloword,自然可以利用索引, xx=hello,也可以利用索引. (左首碼索引) 因為hash(‘helloword’),和hash(‘hello’),兩者的關係仍為隨機
  4)排序也無法優化.
  5)必須回行.就是說 通過索引拿到數據位置,必須回到表中取數據

• 2 btree索引的常見誤區

  2.1 在where條件常用的列上都加上索引
  例: where cat_id=3 and price>100 ; //查詢第3個欄目,100元以上的商品
  誤: cat_id上,和, price上都加上索引.
  錯: 只能用上cat_id或Price索引,因為是獨立的索引,同時只能用上1個.

  2.2 在多列上建立索引後,查詢哪個列,索引都將發揮作用
  誤: 多列索引上,索引發揮作用,需要滿足左首碼要求.

• 在多列上建立索引後,查詢語句發揮作用的索引：

  為便於理解, 假設ABC各10米長的木板, 河面寬30米.
  全值索引是則木板長10米,
  Like,左首碼及範圍查詢, 則木板長6米,
  自己拼接一下,能否過河對岸,就知道索引能否利用上.
  如上例中, where a=3 and b>10, and c=7,
  A板長10米,A列索引發揮作用
  A板正常接B板, B板索引發揮作用
  B板短了,接不到C板, C列的索引不發揮作用.

索引應用舉例：

• innodb的主索引文件上 直接存放該行數據,稱為聚簇索引,次索引指向對主鍵的引用
  myisam中, 主索引和次索引,都指向物理行(磁碟位置).

  註意: 對innodb來說, 
  1: 主鍵索引 既存儲索引值,又在葉子中存儲行的數據
  2: 如果沒有主鍵, 則會Unique key做主鍵 
  3: 如果沒有unique,則系統生成一個內部的rowid做主鍵.
  4: 像innodb中,主鍵的索引結構中,既存儲了主鍵值,又存儲了行數據,這種結構稱為”聚簇索引”

• 聚簇索引

  優勢: 根據主鍵查詢條目比較少時,不用回行(數據就在主鍵節點下)
  劣勢: 如果碰到不規則數據插入時,造成頻繁的頁分裂.
  聚簇索引的主鍵值,應儘量是連續增長的值,而不是要是隨機值,(不要用隨機字元串或UUID)否則會造成大量的頁分裂與頁移動.

• 高性能索引策略

  對於innodb而言,因為節點下有數據文件,因此節點的分裂將會比較慢.
  對於innodb的主鍵,儘量用整型,而且是遞增的整型.
  如果是無規律的數據,將會產生的頁的分裂,影響速度.

• 索引覆蓋:

  索引覆蓋是指 如果查詢的列恰好是索引的一部分,那麼查詢只需要在索引文件上進行,不需要回行到磁碟再找數據.這種查詢速度非常快,稱為”索引覆蓋”

• 理想的索引

  1:查詢頻繁 2:區分度高 3:長度小 4: 儘量能覆蓋常用查詢欄位.

  註：
  索引長度直接影響索引文件的大小,影響增刪改的速度,並間接影響查詢速度(占用記憶體多). 針對列中的值,從左往右截取部分,來建索引
  1: 截的越短, 重覆度越高,區分度越小, 索引效果越不好
  2: 截的越長, 重覆度越低,區分度越高, 索引效果越好,但帶來的影響也越大--增刪改變慢,並間接影響查詢速度.

  所以, 我們要在 區分度 + 長度 兩者上,取得一個平衡.
  慣用手法: 截取不同長度,並測試其區分度,
  select count(distinct left(word,6))/count(*) from dict;

  對於一般的系統應用: 區別度能達到0.1,索引的性能就可以接受.
  對於左首碼不易區分的列 ,建立索引的技巧：如 url列
  http://www.baidu.com
  http://www.zixue.it
  列的前11個字元都是一樣的,不易區分, 可以用如下2個辦法來解決
  1: 把列內容倒過來存儲,並建立索引
  Moc.udiab.www//:ptth
  Ti.euxiz.www//://ptth
  這樣左首碼區分度大,
  2: 偽hash索引效果
  同時存 url_hash列

  多列索引 多列索引的考慮因素---列的查詢頻率、列的區分度。

• 索引與排序

  排序可能發生2種情況:
  1: 對於覆蓋索引,直接在索引上查詢時,就是有順序的, using index
  2: 先取出數據,形成臨時表做filesort(文件排序,但文件可能在磁碟上,也可能在記憶體中)

  我們的爭取目標-----取出來的數據本身就是有序的! 利用索引來排序.

• 重覆索引與冗餘索引

  重覆索引: 是指 在同1個列(如age), 或者 順序相同的幾個列(age,school), 建立了多個索引, 稱為重覆索引, 重覆索引沒有任何幫助,只會增大索引文件,拖慢更新速度, 去掉.

  冗餘索引:是指2個索引所覆蓋的列有重疊,稱為冗餘索引
  比如x,m,列,加索引index x(x),index xm(x,m)
  x,xm索引, 兩者的x列重疊了, 這種情況,稱為冗餘索引.
  甚至可以把 index mx(m,x) 索引也建立, mx, xm 也不是重覆的,因為列的順序不一樣.

• 索引碎片與維護

  在長期的數據更改過程中, 索引文件和數據文件,都將產生空洞,形成碎片.
  我們可以通過一個nop操作(不產生對數據實質影響的操作), 來修改表.
  比如: 表的引擎為innodb , 可以 alter table xxx engine innodb
  optimize table 表名,也可以修複.

  註意: 修複表的數據及索引碎片,就會把所有的數據文件重新整理一遍,使之對齊.
  這個過程,如果表的行數比較大,也是非常耗費資源的操作.所以,不能頻繁的修複.

  如果表的Update操作很頻率,可以按周/月,來修複.
  如果不頻繁,可以更長的周期來做修複.

資料庫相關面試題

1. drop,delete與truncate的區別

drop直接刪掉表 truncate刪除表中數據，再插入時自增長id又從1開始 delete刪除表中數據，可以加where字句。
（1） DELETE語句執行刪除的過程是每次從表中刪除一行，並且同時將該行的刪除操作作為事務記錄在日誌中保存以便進行進行回滾操作。TRUNCATE TABLE 則一次性地從表中刪除所有的數據並不把單獨的刪除操作記錄記入日誌保存，刪除行是不能恢復的。並且在刪除的過程中不會激活與表有關的刪除觸發器。執行速度快。
（2） 表和索引所占空間。當表被TRUNCATE 後，這個表和索引所占用的空間會恢復到初始大小，而DELETE操作不會減少表或索引所占用的空間。drop語句將表所占用的空間全釋放掉。
（3） 一般而言，drop > truncate > delete
（4） 應用範圍。TRUNCATE 只能對TABLE；DELETE可以是table和view
（5） TRUNCATE 和DELETE只刪除數據，而DROP則刪除整個表（結構和數據）。
（6） truncate與不帶where的delete ：只刪除數據，而不刪除表的結構（定義）drop語句將刪除表的結構被依賴的約束（constrain),觸發器（trigger)索引（index);依賴於該表的存儲過程/函數將被保留，但其狀態會變為：invalid。
（7） delete語句為DML（data maintain Language),這個操作會被放到 rollback segment中,事務提交後才生效。如果有相應的 tigger,執行的時候將被觸發。
（8） truncate、drop是DLL（data define language),操作立即生效，原數據不放到 rollback segment中，不能回滾
（9） 在沒有備份情況下，謹慎使用 drop 與 truncate。要刪除部分數據行採用delete且註意結合where來約束影響範圍。回滾段要足夠大。要刪除表用drop;若想保留表而將表中數據刪除，如果於事務無關，用truncate即可實現。如果和事務有關，或老師想觸發trigger,還是用delete。
（10） Truncate table 表名 速度快,而且效率高,因為:
truncate table 在功能上與不帶 WHERE 子句的 DELETE 語句相同：二者均刪除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系統和事務日誌資源少。DELETE 語句每次刪除一行，併在事務日誌中為所刪除的每行記錄一項。TRUNCATE TABLE 通過釋放存儲表數據所用的數據頁來刪除數據，並且只在事務日誌中記錄頁的釋放。
（11） TRUNCATE TABLE 刪除表中的所有行，但表結構及其列、約束、索引等保持不變。新行標識所用的計數值重置為該列的種子。如果想保留標識計數值，請改用 DELETE。如果要刪除表定義及其數據，請使用 DROP TABLE 語句。
（12） 對於由 FOREIGN KEY 約束引用的表，不能使用 TRUNCATE TABLE，而應使用不帶 WHERE 子句的 DELETE 語句。由於 TRUNCATE TABLE 不記錄在日誌中，所以它不能激活觸發器。

2.資料庫範式

1 第一範式（1NF）

在任何一個關係資料庫中，第一範式（1NF）是對關係模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關係資料庫。
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重覆的屬性。如果出現重覆的屬性，就可能需要定義一個新的實體，新的實體由重覆的屬性構成，新實體與原實體之間為一對多關係。在第一範式（1NF）中表的每一行只包含一個實例的信息。簡而言之，第一範式就是無重覆的列。

2 第二範式（2NF）

第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。 第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。

3 第三範式（3NF）

滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。（我的理解是消除冗餘）

3.MySQL的複製原理以及流程

基本原理流程，3個線程以及之間的關聯；
1. 主：binlog線程——記錄下所有改變了資料庫數據的語句，放進master上的binlog中；
2. 從：io線程——在使用start slave 之後，負責從master上拉取 binlog 內容，放進 自己的relay log中；
3. 從：sql執行線程——執行relay log中的語句；

4.MySQL中myisam與innodb的區別，至少5點

1>.InnoDB支持事物，而MyISAM不支持事物
2>.InnoDB支持行級鎖，而MyISAM支持表級鎖
3>.InnoDB支持MVCC, 而MyISAM不支持
4>.InnoDB支持外鍵，而MyISAM不支持
5>.InnoDB不支持全文索引，而MyISAM支持。

5.innodb引擎的4大特性

插入緩衝（insert buffer),二次寫(double write),自適應哈希索引(ahi),預讀(read ahead)

6.myisam和innodb 2者selectcount(*)哪個更快，為什麼

myisam更快，因為myisam內部維護了一個計數器，可以直接調取。

7.MySQL中varchar與char的區別以及varchar(50)中的50代表的涵義

(1)、varchar與char的區別
char是一種固定長度的類型，varchar則是一種可變長度的類型

(2)、varchar(50)中50的涵義
最多存放50個字元，varchar(50)和(200)存儲hello所占空間一樣，但後者在排序時會消耗更多記憶體，因為order by col採用fixed_length計算col長度(memory引擎也一樣)

(3)、int（20）中20的涵義 是指顯示字元的長度
但要加參數的，最大為255，比如它是記錄行數的id,插入10筆資料，它就顯示00000000001 ~~~00000000010，當字元的位數超過11,它也只顯示11位，如果你沒有加那個讓它未滿11位就前面加0的參數，它不會在前面加0 20表示最大顯示寬度為20，但仍占4位元組存儲，存儲範圍不變；

(4)、mysql為什麼這麼設計
對大多數應用沒有意義，只是規定一些工具用來顯示字元的個數；int(1)和int(20)存儲和計算均一樣；

8.開放性問題：

一個6億的表a，一個3億的表b，通過外間tid關聯，你如何最快的查詢出滿足條件的第50000到第50200中的這200條數據記錄。
1、如果A表TID是自增長,並且是連續的,B表的ID為索引
select * from a,b where a.tid = b.id and a.tid>500000 limit 200;

2、如果A表的TID不是連續的,那麼就需要使用覆蓋索引.TID要麼是主鍵,要麼是輔助索引,B表ID也需要有索引。
select * from b , (select tid from a limit 50000,200) a where b.id = a .tid;

9.mysql資料庫引擎MyISAM和InnoDB的區別

10.MySql 表中允許有多少種 TRIGGERS?

在 MySql 表中允許有六種觸發器，如下：
·BEFORE INSERT
·AFTER INSERT
·BEFORE UPDATE
·AFTER UPDATE
·BEFORE DELETE
·AFTER DELETE