事務(wù)4大特性，一致性具體指什么？這4個(gè)特性mysql如何保證實(shí)現(xiàn)的？

事務(wù)的四大特性

1. 原子性：事務(wù)由一系列動作組成，整個(gè)事務(wù)的所有操作，要么全部完成，要么全部不完成

2. 一致性：一旦事務(wù)完成，在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性約束沒有被破壞

3. 隔離性：隔離狀態(tài)執(zhí)行事務(wù)，事務(wù)與事務(wù)之間互不影響各自的操作和執(zhí)行

4. 持久性：在事務(wù)完成以后，該事務(wù)對數(shù)據(jù)庫所作的更改操作便持久的保存在數(shù)據(jù)庫之中，而不是臨時(shí)的，也不會回滾

Mysql怎么保證一致性的？

從數(shù)據(jù)庫層面，數(shù)據(jù)庫通過原子性、隔離性、持久性來保證一致性。也就是說ACID四大特性之中，C(一致性)是目的，A(原子性)、I(隔離性)、D(持久性)是手段，是為了保證一致性，數(shù)據(jù)庫提供的手段。數(shù)據(jù)庫必須要實(shí)現(xiàn)AID三大特性，才有可能實(shí)現(xiàn)一致性。例如，原子性無法保證，顯然一致性也無法保證。

但是，如果你在事務(wù)里故意寫出違反約束的代碼，一致性還是無法保證的。例如，你在轉(zhuǎn)賬的例子中，你的代碼里故意不給B賬戶加錢，那一致性還是無法保證。因此，還必須從應(yīng)用層角度考慮。

從應(yīng)用層面，通過代碼判斷數(shù)據(jù)庫數(shù)據(jù)是否有效，然后決定回滾還是提交數(shù)據(jù)！

Mysql怎么保證原子性的？

是利用Innodb的undo log。 undo log名為回滾日志，是實(shí)現(xiàn)原子性的關(guān)鍵，當(dāng)事務(wù)回滾時(shí)能夠撤銷所有已經(jīng)成功執(zhí)行的sql語句，他需要記錄你要回滾的相應(yīng)日志信息

Mysql怎么保證持久性的？

是利用Innodb的redo log。

采用redo log的好處？ 其實(shí)好處就是將redo log進(jìn)行刷盤比對數(shù)據(jù)頁刷盤效率高，具體表現(xiàn)如下

• redo log體積小，畢竟只記錄了哪一頁修改了啥，因此體積小，刷盤快。

• redo log是一直往末尾進(jìn)行追加，屬于順序IO。效率顯然比隨機(jī)IO來的快。

Mysql怎么保證隔離性的？

利用的是鎖和MVCC機(jī)制。

MVCC,即多版本并發(fā)控制(Multi Version Concurrency Control),一個(gè)行記錄數(shù)據(jù)有多個(gè)版本對快照數(shù)據(jù)，這些快照數(shù)據(jù)在undo log中。

如果一個(gè)事務(wù)讀取的行正在做DELELE或者UPDATE操作，讀取操作不會等行上的鎖釋放，而是讀取該行的快照版本。

在事務(wù)隔離級別為讀已提交(Read Commited)時(shí)，一個(gè)事務(wù)能夠讀到另一個(gè)事務(wù)已經(jīng)提交的數(shù)據(jù)，是不滿足隔離性的。但是當(dāng)事務(wù)隔離級別為可重復(fù)讀(Repeateable Read)中，是滿足隔離性的。

事務(wù)隔離級別，4個(gè)隔離級別分別有什么并發(fā)問題？

• 未提交讀：最低的隔離級別，允許讀取尚未提交的數(shù)據(jù)變更，可能會導(dǎo)致臟讀、幻讀或不可重復(fù)讀

• 已提交讀：允許讀取并發(fā)事務(wù)已經(jīng)提交的數(shù)據(jù)，可以阻止臟讀，但是幻讀或不可重復(fù)讀仍有可能發(fā)生

• 可重復(fù)讀：對同一字段的多次讀取結(jié)果都是一致的，除非數(shù)據(jù)是被本身事務(wù)自己所修改，可以阻止臟讀和不可重復(fù)讀，但幻讀仍有可能發(fā)生

• 串行化：最高的隔離級別，完全服從 ACID 的隔離級別。所有的事務(wù)依次逐個(gè)執(zhí)行，這樣事務(wù)之間就完全不可能產(chǎn)生干擾，也就是說，該級別可以防止臟讀、不可重復(fù)讀以及幻讀。但是這將嚴(yán)重影響程序的性能。通常情況下也不會用到該級別。

Mysql默認(rèn)隔離級別？如何保證并發(fā)安全？

MySql默認(rèn)采用可重復(fù)讀

MySql存儲引擎使用的InnoDB，InnoDB支持行級鎖和表級鎖，默認(rèn)使用的是行級鎖，InnoDB的行級鎖有兩種：

• 共享鎖：只允許一個(gè)事務(wù)去讀一行，阻止其他事務(wù)獲取相同數(shù)據(jù)集的排他鎖

• 排他鎖：允許獲得排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同數(shù)據(jù)集的共享鎖和排他鎖

4、RR和RC如何實(shí)現(xiàn)的？RR使用場景？對比volatile可見性，為什么RR的事務(wù)要設(shè)計(jì)成不能讀另一個(gè)事務(wù)已經(jīng)提交的數(shù)據(jù)？

隔離級別的單位是數(shù)據(jù)表還是數(shù)據(jù)行？如串行化級別，兩個(gè)事務(wù)訪問不同的數(shù)據(jù)行，能并發(fā)？

1. 事務(wù)隔離級別為讀提交時(shí)，寫數(shù)據(jù)只會鎖住相應(yīng)的行

2. 事務(wù)隔離級別為可重復(fù)讀時(shí)，如果檢索條件有索引（包括主鍵索引）的時(shí)候，默認(rèn)加鎖方式是next-key 鎖；如果檢索條件沒有索引，更新數(shù)據(jù)時(shí)會鎖住整張表。一個(gè)間隙被事務(wù)加了鎖，其他事務(wù)是不能在這個(gè)間隙插入記錄的，這樣可以防止幻讀。

3. 事務(wù)隔離級別為串行化時(shí)，讀寫數(shù)據(jù)都會鎖住整張表

隔離級別越高，越能保證數(shù)據(jù)的完整性和一致性，但是對并發(fā)性能的影響也越大。

MYSQL MVCC實(shí)現(xiàn)機(jī)制參考鏈接：https://blog.csdn.net/whoamiyang/article/details/51901888

關(guān)于next-key 鎖可以參考鏈接：https://blog.csdn.net/bigtree_3721/article/details/73731377**

存儲引擎Innodb和Myisam的區(qū)別以及使用場景

區(qū)別：

1. MyISAM只支持表級鎖，而InnoDB支持表級鎖和行級鎖

2. MyISAM不支持外鍵，而InnoDB支持外鍵

3. MyISAM不提供事務(wù)支持，而InnoDB提供事務(wù)支持

4. MyISAM 強(qiáng)調(diào)的是性能，每次查詢具有原子性，其執(zhí)行速度比 InnoDB 類型更快

5. MyISAM 在數(shù)據(jù)崩潰之后不能進(jìn)行安全恢復(fù)，而InnoDB具備崩潰修復(fù)能力

6. 因?yàn)?MyISAM 緩存有表 meta-data（行數(shù)等），因此在做 COUNT(*)時(shí)對于一個(gè)結(jié)構(gòu)很好的查詢是不需要消耗多少資源的。而對于 InnoDB 來說，則沒有這種緩存

使用場景：

MyISAM 更適合讀密集的表，而 InnoDB 更適合寫密集的表。 在數(shù)據(jù)庫做主從分離的情況下，經(jīng)常選擇 MyISAM 作為主庫的存儲引擎。

一般來說，如果需要事務(wù)支持，并且有較高的并發(fā)讀取頻率(MyISAM 的表鎖的粒度太大，所以當(dāng)該表寫并發(fā)量較高時(shí)，要等待的查詢就會很多了)，InnoDB 是不錯(cuò)的選擇。如果你的數(shù)據(jù)量很大（MyISAM 支持壓縮特性可以減少磁盤的空間占用），而且不需要支持事務(wù)時(shí)，MyISAM 是最好的選擇。

介紹Inodb鎖機(jī)制，行鎖，表鎖，意向鎖

mysql鎖機(jī)制：

InnoDB存儲引擎既支持行級鎖（row-level locking），也支持表級鎖，但默認(rèn)情況下是采用行級鎖。

表級鎖：開銷小，加鎖快；不會出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高,并發(fā)度最低。 行級鎖：開銷大，加鎖慢；會出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低,并發(fā)度也最高。

Innodb 行級鎖 record-level lock大致有三種：record lock, gap lock and Next-KeyLocks。

record lock 鎖住某一行記錄 gap lock 鎖住某一段范圍中的記錄 next key lock 是前兩者效果的疊加。

InnoDB實(shí)現(xiàn)了以下兩種類型的行鎖：

• 共享鎖：允許一個(gè)事務(wù)去讀一行，阻止其他事務(wù)獲得相同數(shù)據(jù)集的排他鎖；

• 排他鎖：允許獲得排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同數(shù)據(jù)集的共享讀鎖和排他寫鎖。

為了允許行鎖和表鎖共存，實(shí)現(xiàn)多粒度鎖機(jī)制，InnoDB還有兩種內(nèi)部使用的意向鎖（意向共享鎖和意向排他鎖）。這兩種意向鎖都是表鎖。意向鎖是InnoDB自動加的，不需要用戶干預(yù)。 對于UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數(shù)據(jù)集加排他鎖；對于普通SELECT語句，InnoDB不會加任意鎖。

事務(wù)可以通過以下語句顯示給記錄集加共享鎖或者排他鎖：

SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE  #共享鎖
SELECT * FROM table_name WHERE ... FOR UPDATE  #排他鎖

InnoDB的行鎖實(shí)現(xiàn)的特點(diǎn)：只有通過索引條件檢索數(shù)據(jù)，InnoDB才會使用行級鎖，否則，InnoDB將會使用表鎖。因?yàn)镸ySQL的行鎖是針對索引加的鎖，
而不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是使用相同的索引建，是會出現(xiàn)鎖沖突的。

對于鍵值在條件范圍內(nèi)但并不存在的記錄，叫做間隙。InnoDB會對這個(gè)間隙加鎖，這種鎖機(jī)制就是所謂的間隙鎖（Next-Key鎖）。 InnoDB使用間隙鎖的目的：一是為了防止幻讀，二是為了滿足其恢復(fù)和復(fù)制的需要。

InnoDB如何解決死鎖問題的：

在InnoDB中，鎖是逐步獲得的，因此發(fā)生死鎖是可能的。發(fā)生死鎖后，InnoDB一般都能自動檢測到，并使一個(gè)事務(wù)釋放鎖并回退，另外一個(gè)事務(wù)獲得鎖，并繼續(xù)完成事務(wù)。但在涉及外部鎖， 或涉及表鎖的情況下，InnoDB并不能完全自動檢測到死鎖，這需要通過設(shè)置鎖等待超時(shí)參數(shù)innodb_lock_wait_timeout來解決。

介紹MVCC

https://blog.csdn.net/whoamiyang/article/details/51901888

哈希索引是如何實(shí)現(xiàn)的？

Hash索引：一對一主鍵 不利于范圍查詢 無法利用前綴查詢

所謂Hash索引，當(dāng)我們要給某張表某列增加索引時(shí)，將這張表的這一列進(jìn)行哈希算法計(jì)算，得到哈希值，排序在哈希數(shù)組上。所以Hash索引可以一次定位，其效率很高

哈希索引（hash index）基于哈希表實(shí)現(xiàn)，只有精確匹配索引所有列的查詢才有效。對于每一行數(shù)據(jù)，存儲引擎都會對所有的索引列計(jì)算一個(gè)哈希碼（hash code），哈希碼是一個(gè)較小的值，并且不同鍵值的行計(jì)算出來的哈希碼也不一樣。哈希索引將所有的哈希碼存儲在索引中，同時(shí)在哈希表中保存指向每個(gè)數(shù)據(jù)行的指針。

哈希索引可細(xì)分為靜態(tài)哈希和動態(tài)哈希這兩大類

B樹索引為什么使用B+樹，相對于B樹有什么優(yōu)點(diǎn)？為什么不能紅黑樹？要提到磁盤預(yù)讀

參考：http://www.liuzk.com/410.html

聚簇索引和非聚簇索引區(qū)別

1）聚簇索引

• 一個(gè)索引項(xiàng)直接對應(yīng)實(shí)際數(shù)據(jù)記錄的存儲頁，可謂“直達(dá)” 主鍵缺省使用它

• 索引項(xiàng)的排序和數(shù)據(jù)行的存儲排序完全一致，利用這一點(diǎn)，想修改數(shù)據(jù)的存儲順序，可以通過改變主鍵的方法（撤銷原有主鍵，另找也能滿足主鍵要求的一個(gè)字段或一組字段，重建主鍵）

• 一個(gè)表只能有一個(gè)聚簇索引（理由：數(shù)據(jù)一旦存儲，順序只能有一種）

2) 非聚簇索引

• 不能“直達(dá)”，可能鏈?zhǔn)降卦L問多級頁表后，才能定位到數(shù)據(jù)頁

• 表數(shù)據(jù)存儲順序與索引順序無關(guān)。對于非聚集索引，葉結(jié)點(diǎn)包含索引字段值及指向數(shù)據(jù)頁數(shù)據(jù)行的邏輯指針，其行數(shù)量與數(shù)據(jù)表行數(shù)據(jù)量一致。

• 一個(gè)表可以有多個(gè)非聚簇索引

回表查詢和覆蓋索引

回表查詢：即先定位主鍵值，再根據(jù)主鍵值定位行記錄，性能相對于只掃描一遍聚集索引樹的性能要低一些。

覆蓋索引：索引覆蓋是一種避免回表查詢的優(yōu)化策略。具體的做法就是將要查詢的數(shù)據(jù)作為索引列建立普通索引（可以是單列索引，也可以一個(gè)索引語句定義所有要查詢的列，即聯(lián)合索引），這樣的話就可以直接返回索引中的的數(shù)據(jù)，不需要再通過聚集索引去定位行記錄，避免了回表的情況發(fā)生。

覆蓋索引的優(yōu)點(diǎn)

1. 索引條目通常遠(yuǎn)小于數(shù)據(jù)行的大小，因?yàn)楦采w索引只需要讀取索引，極大地減少了數(shù)據(jù)的訪問量。

2. 索引是按照列值順序存儲的，對于IO密集的范圍查找會比隨機(jī)從磁盤讀取每一行數(shù)據(jù)的IO小很多。

3. 一些存儲引擎比如MyISAM在內(nèi)存中只緩存索引，數(shù)據(jù)則依賴操作系統(tǒng)來緩存，因此要訪問數(shù)據(jù)的話需要一次系統(tǒng)調(diào)用，使用覆蓋索引則避免了這一點(diǎn)。

4. 由于InnoDB的聚簇索引，覆蓋索引對InnoDB引擎下的數(shù)據(jù)庫表特別有用。因?yàn)镮nnoDB的二級索引在葉子節(jié)點(diǎn)中保存了行的主鍵值，如果二級索引能夠覆蓋查詢，就避免了對主鍵索引的二次查詢。

參考：https://www.cnblogs.com/yanggb/p/11252966.html

如何創(chuàng)建索引？

• 1. 主鍵索引（PRIMARY KEY）：它是一種特殊的唯一索引，不允許有空值。一般在建表的時(shí)候同時(shí)創(chuàng)建主鍵索引。

  2. 唯一索引（UNIQUE）：唯一索引列的值必須唯一，但允許有空值。

     ALTER TABLE 表名 ADD UNIQUE(字段名)
     

  3. 普通索引（INDEX）：最基本的索引，它沒有任何限制。

     ALTER TABLE 表名 ADD INDEX 索引名稱(字段名稱)
     

  4. 組合索引（INDEX）：一個(gè)索引包含多個(gè)列，多用于避免回表查詢。

     ALTER TABLE 表名 ADD INDEX 索引名稱(字段名稱1，字段名稱2，字段名稱N)
     

  5. 全文索引（FULLTEXT）：全文檢索，是目前搜索引擎的一種關(guān)鍵技術(shù)，一般用于有大量的text類型數(shù)據(jù)的字段

     ALTER TABLE student_register ADD FULLTEXT(字段名稱)
     

如何使用索引避免全表掃描？

1. 盡量不要使用like進(jìn)行模糊查詢，如果非要使用，盡量使用后導(dǎo)查詢（左模糊like：...%）

2. 應(yīng)盡量避免在 where 子句中對字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

3. 盡量避免在 where 子句中使用!=或< >操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。

4. 盡量避免在 where 子句中使用 or 來連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

5. in 和 not in 也要慎用，否則會導(dǎo)致全表掃描

6. 應(yīng)考慮在 where 及 order by 涉及的列上建立索引。

Explain語句各字段的意義

1. id

每個(gè)被獨(dú)立執(zhí)行的操作的標(biāo)識，表示對象被操作的順序；id值大，先被執(zhí)行；如果相同，執(zhí)行順序從上到下。

若沒有子查詢和聯(lián)合查詢，id則都是1。Mysql會按照id從大到小的順序執(zhí)行query，在id相同的情況下，則從上到下執(zhí)行。

2. select_type

查詢中每個(gè)select子句的類型

（1）SIMPLE

（2）PRIMARY/UNION

（3）DEPENDENT UNION/UNIOIN RESULT

（4）SUBQUERY/DEPENDENT SUBQUERY

（5）DERIVED/MATERIALIZED

（6）UNCACHEABLE SUBQUERY/UNCACHEABLE UNION

3. table

名字，被操作的對象名稱，通常是表名，或者表的別名，或者一個(gè)為查詢產(chǎn)生臨時(shí)表的標(biāo)示符（如派生表、子查詢、集合）。

4. type

代表查詢執(zhí)行計(jì)劃中表使用的連接方式。

連接操作類型及級別：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

一般來說，得保證查詢至少達(dá)到range級別，最好能達(dá)到ref。

5. partitions

匹配的分區(qū)信息（對于非分區(qū)表值為NULL）。

6. possible_keys

備選的索引（列出可能被使用到的索引）

7. key

經(jīng)優(yōu)化器選定的索引；常用ANALYZE TABLE命令，可以使優(yōu)化器正確地選擇索引。如果沒有選擇索引，鍵是NULL。要想強(qiáng)制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

8. key_len

被優(yōu)化器選定的索引鍵的長度，單位是字節(jié)。

9. ref

表示本行被操作的對象的參照對象（被參照的對象可能是一個(gè)常量用const表示，也可能是其他表的key指向的對象）。

10. rows

查詢執(zhí)行所掃描的元組個(gè)數(shù)（對于InnoDB，此值是估計(jì)值）。

11. filtered

按照條件表上數(shù)據(jù)被過濾的元組個(gè)數(shù)的百分比，rows×filtered/100可以求出過濾后的元組數(shù)即實(shí)際的元組數(shù)。

12. Extra

（1）using where

（2）using temporary

（3）using filesort

（4）using index

（5）using join buffer

（6）impossible where

（7）select tables optimized away

（8）distinct

最左前綴??！聯(lián)合索引B+樹是如何建立的？是如何查詢的？當(dāng)where子句中出現(xiàn)>時(shí)，聯(lián)合索引命中是如何的? 如 where a > 10 and b = “111”時(shí)，聯(lián)合索引如何創(chuàng)建？mysql優(yōu)化器會針對得做出優(yōu)化嗎？

MySQL中一條SQL語句的執(zhí)行過程

image

1. 連接

   SQL客戶端與與服務(wù)器建立連接，該請求被發(fā)送到連接管理器，連接成功后會驗(yàn)證權(quán)限等，這過程其實(shí)就是一個(gè)TCP連接的過程。注意，MySQL服務(wù)器與客戶端之間的通信是“半雙工”的，意味著任意時(shí)刻，要么是服務(wù)器向客戶端發(fā)送數(shù)據(jù)，要什么是客戶端向服務(wù)器發(fā)送數(shù)據(jù)（請求），不能同時(shí)進(jìn)行。

2. 查詢緩存

   如果查詢命中緩存（一個(gè)大小寫敏感的哈希查找實(shí)現(xiàn)的）則直接返回結(jié)果（注意：在返回結(jié)果前還會檢查一次用戶號的權(quán)限）；如果查詢沒有命中緩存，則進(jìn)行下一步sql解析。

3. 語法解析器和預(yù)處理

   首先通過mysql關(guān)鍵字將語句解析，會生成一個(gè)內(nèi)部解析樹，mysql解析器將對其解析，查看是否是有錯(cuò)誤的關(guān)鍵字，關(guān)鍵字順序是佛正確； 預(yù)處理器則是根據(jù)mysql的規(guī)則進(jìn)行進(jìn)一步的檢查，檢查mysql語句是否合法，如，庫表是否存在，字段是否存在，字段之間是否模棱兩可等等，預(yù)處理器也會驗(yàn)證權(quán)限。

4. 查詢優(yōu)化器

   sql語句在優(yōu)化器中轉(zhuǎn)換成執(zhí)行計(jì)劃，一條sql語句可以有多種方式查詢，最后返回的結(jié)果肯定是相同，但是不同的查詢方式效果不同，優(yōu)化器的作用就是：選擇一種合適的執(zhí)行計(jì)劃 mysql是基于成本的優(yōu)化器，他將預(yù)測執(zhí)行此計(jì)劃的成本，并選擇成本最小的那條

5. 執(zhí)行計(jì)劃

   和很多關(guān)系型數(shù)據(jù)庫不同的是，mysql不會產(chǎn)生查詢字節(jié)碼來執(zhí)行查詢，而是生成查詢的一顆指令樹，通過存儲引擎執(zhí)行指令并返回結(jié)果。最終的執(zhí)行計(jì)劃包含了重構(gòu)查詢的全部信息，通過EXPLAIN EXTENDED 和SHOW WARNINGS就可以看到重構(gòu)的查詢。

6. 執(zhí)行SQL

   在解析和優(yōu)化階段，MySQL將生成查詢對應(yīng)的執(zhí)行計(jì)劃，由執(zhí)行計(jì)劃調(diào)用存儲引擎的API來執(zhí)行查詢MySQL就行（在此過程中只是簡單的根據(jù)執(zhí)行計(jì)劃給出的指令逐步執(zhí)行） 將結(jié)果返回給客戶端；即使查詢不需要返回結(jié)果，MySQL也會返回影響到的行數(shù)。注意：返回結(jié)果時(shí)是個(gè)逐步返回結(jié)果的過程，并不是一次性查詢完然后返回一個(gè)大的結(jié)果集

https://zhuanlan.zhihu.com/p/70295845

數(shù)據(jù)庫幾大范式

• 第一范式：列不可再分，數(shù)據(jù)表的每一個(gè)字段都具備原子性，不能在進(jìn)行分割

• 第二范式：在第一范式的基礎(chǔ)之上，數(shù)據(jù)表的每一行數(shù)據(jù)有一個(gè)可進(jìn)行標(biāo)識的主屬性字段（主鍵），該行的其余字段都應(yīng)全部依賴于該主屬性字段（主鍵），如果存在不依賴于該主鍵的字段，必須將其分離出去

• 第三范式：在第二范式的基礎(chǔ)之上，針對于數(shù)據(jù)的冗余性，表與表之間的數(shù)據(jù)引用關(guān)系，若存在兩張數(shù)據(jù)表A和B，B的字段中出現(xiàn)了A的主鍵，則B中不能再出現(xiàn)A中依賴于其主鍵的其它字段（即不能有依賴傳遞）

• 反范式：指不遵循三大范式，通過增加冗余或重復(fù)的數(shù)據(jù)來提高數(shù)據(jù)庫的讀性能。反范式可以減輕數(shù)據(jù)庫的關(guān)聯(lián)查找所帶來的負(fù)擔(dān)

數(shù)據(jù)庫基本查詢關(guān)鍵字使用，如left join on,where,beteen and,group by,having,limit,聚合函數(shù)等。

left join,right join,inner join,outer join的含義及區(qū)別

mysql主從復(fù)制過程，binlog記錄格式，復(fù)制的異步半同步同步模式區(qū)別

主從復(fù)制或讀寫分離等數(shù)據(jù)不一致性問題以及如何解決

銀行的話，可以會考mysql數(shù)據(jù)類型，如余額要用decimal