mysql面試常考知識點

該文章借鑑了不一樣平臺對知識點的描述。

一、存儲引擎的區別

1.1 InnoDB 和MYISAM 存儲引擎的區別？

InnoDB:

• InnoDB 存儲引擎支持事務、支持外鍵、支持非鎖定讀、行鎖設計其設計主要面向OLTP 應用。
• InnoDB 存儲引擎表採用彙集的方式存儲，所以每張表的存儲順序都按主鍵的順序存放，若是沒有指定主鍵，InnoDB 存儲引擎會爲每一行生成一個6字節的ROWID並以此做爲主鍵。
• InnoDB 存儲引擎經過MVCC 獲的高併發性，並提供了插入緩衝、二次寫、自適應哈希索引和預讀等高性能高可用功能
• InnoDB 存儲引擎默認隔離級別爲REPEATABLE_READ（重複讀）並採用next-key locking(間隙鎖)來避免幻讀

MySIAM：

• MYISAM 存儲引擎不支持事務、表鎖設計、支持全文索引其設計主要面向OLAP 應用
• MYISAM 存儲引擎表由frm、MYD 和MYI 組成，frm 文件存放表格定義，MYD 用來存放數據文件，MYI 存放索引文件。MYISAM 存儲引擎不同凡響的地方在於它的緩衝池只緩存索引文件而不緩存數據文件，數據文件的緩存依賴於操做系統。

操做區別：

• MYISAM 保存表的具體行數，不帶where 是可直接返回。InnoDB 要掃描全表。
• DELETE 表時，InnoDB 是一行一行的刪除，MYISAM 是先drop表，而後重建表
• InnoDB 跨平臺可直接拷貝使用，MYISAM 不行
• InnoDB 表格很難被壓縮，MYISAM 能夠

選擇：

• MyISAM相對簡單因此在效率上要優於InnoDB。若是系統讀多，寫少。對原子性要求低。那麼MyISAM最好的選擇。且MyISAM恢復速度快。可直接用備份覆蓋恢復。
• InnoDB 更適合系統讀少，寫多的時候，尤爲是高併發場景。

　

二、索引

2.一、什麼是索引？你知道Mysql 有哪些索引？

索引是對數據庫表中一或多個列的值進行排序的結構，是幫助MySQL高效獲取數據的數據結構

（數據庫是磁盤文件，磁盤IO 的代價較高，因此採用索引減小IO 次數）

Mysql 中經常使用的索引有B+ 樹索引（包括普通索引、惟一索引、主鍵索引），哈希索引，全文索引，R-TREE 索引（空間索引，主要用於地理空間數據類型，不多使用）。

Mysql 傳統意義上的索引爲B+ 樹索引，B+ 樹索引的本質就是B+ 樹在數據庫中的實現，因爲B+ 樹的高扇出性，數據庫中的B+ 樹的高通常爲2-4層，所以查找某一鍵值的行記錄只需2-4次IO，大概0.02~0.04秒。

（扇出性：是指該模塊直接調用的下級模塊的個數。扇出大表示模塊的複雜度高，須要控制和協調過多的下級模塊）

B+ 樹索引

主要分爲彙集索引和輔助索引。

彙集索引是根據每張表的主鍵建造的一棵B+ 樹，葉子節點中存放的是整張表的行記錄。一張表只能有一個彙集索引。由於彙集索引在邏輯上是連續的，因此它對於主鍵的排序查找和範圍查找速度很是快。

輔助索引與彙集索引不一樣的地方在於，輔助索引不是惟一的，它的葉子節點只包含行記錄的部分數據以及對應彙集索引的節點位置。經過輔助索引來查找數據時，先遍歷輔助索引找到對應主鍵索引，再經過主鍵索引查找對應記錄。

在MYISAM 中主鍵索引和輔助索引都至關上述輔助索引，索引頁中存放的是主鍵和指向數據頁的偏移量，數據頁中存放的是主鍵和該主鍵所屬行記錄的地址空間。惟一的區別是MYISAM 中主鍵索引不能重複，輔助索引能夠。

從使用上來講還有聯合索引和覆蓋索引。

聯合索引是指對錶上的多個列進行索引。它對對應多個列的指定獲取比較快。另一個好處是聯合索引對第二個鍵已經排好序了，因此對兩個列的排序獲取能夠避免多作一次排序操做。

覆蓋索引其實更算一種思想，可以從輔助索引中獲取信息，就不須要查詢彙集索引中的數據。使用輔助索引的好處在於輔助索引包含的信息少，因此大小遠小於彙集索引，所以能夠大大減小IO 操做。

哈希索引是一種自適應的索引，數據庫會根據表的使用狀況自動生成哈希索引，咱們人爲是沒辦法干預的。

InnoDB 儲存引擎採用的哈希函數爲除法散列方式，採用的衝突處理方法爲鏈地址法。它指定查詢的速度很快，可是範圍查詢就無能爲力了。

全文索引用於實現關鍵詞搜索。但它只能根據空格分詞，所以不支持中文。

2.二、索引的優缺點？那些狀況適合建索引那些狀況不適合建索引？

索引的優勢：

• 經過建立惟一性索引，能夠保證數據庫表中每一行數據的惟一性。
• 能夠大大加快 數據的檢索速度，這也是建立索引的最主要的緣由。
• 能夠加速表和表之間的鏈接，特別是在實現數據的參考完整性方面特別有意義。
• 在使用分組和排序 子句進行數據檢索時，一樣能夠顯著減小查詢中分組和排序的時間。
• 經過使用索引，能夠在查詢的過程當中，使用優化隱藏器，提升系統的性能。

索引的缺點　　

• 建立索引和維護索引要耗費時間，這種時間隨着數據量的增長而增長。
• 索引須要佔物理空間，除了數據表佔數據空間以外，每個索引還要佔必定的物理空間，若是要創建聚簇索引，那麼須要的空間就會更大。
• 當對錶中的數據進行增長、刪除和修改的時候，索引也要動態的維護，這樣就下降了數據的維護速度。

擴展

聚簇索引和非聚簇索引：

哪些狀況須要加索引？

• 在常常須要搜索的列上，能夠加快搜索的速度；
• 在做爲主鍵的列上，強制該列的惟一性和組織表中數據的排列結構；
• 在常常用在鏈接的列上，這些列主要是一些外鍵，能夠加快鏈接的速度；
• 在常常須要根據範圍進行搜索的列上建立索引，由於索引已經排序，其指定的範圍是連續的；
• 在常常須要排序的列上建立索引，由於索引已經排序，這樣查詢能夠利用索引的排序，加快排序查詢時間；
• 在常用在WHERE子句中的列上面建立索引，加快條件的判斷速度

哪些狀況不須要加索引？

• 對於那些在查詢中不多使用或者參考的列不該該建立索引。這是由於，既然這些列不多使用到，所以有索引或者無索引，並不能提升查詢速度。相反，因爲增長了索引，反而下降了系統的維護速度和增大了空間需求。
• 對於那些只有不多數據值的列也不該該增長索引。這是由於，因爲這些列的取值不多，例如人事表的性別列，在查詢的結果中，結果集的數據行佔了表中數據行的很大比例，即須要在表中搜索的數據行的比例很大。增長索引，並不能明顯加快檢索速度。
• 對於那些定義爲text, image和bit數據類型的列不該該增長索引。這是由於，這些列的數據量要麼至關大，要麼取值不多。
• 當修改性能遠遠大於檢索性能時，不該該建立索引。這是由於，修改性能和檢索性能是互相矛盾的。當增長索引時，會提升檢索性能，可是會下降修改性能。當減小索引時，會提升修改性能，下降檢索性能。所以，當修改性能遠遠大於檢索性能時，不該該建立索引。

三、事務

3.一、什麼是事務，它有哪些特性？說一說事務的隔離級別，分別解決了什麼問題？

什麼是事務，它有哪些特性？

事務就是一組原子性的操做，這些操做要麼所有發生，要麼所有不發生。事務把數據庫從一種一致性狀態轉換成另外一種一致性狀態。

事務具備ACID 四種特性，即原子性(atomicity)，一致性(consistency)，隔離性(isolation)，持久性(durability)：

• 原子性，指的是事務是一個不可分割的操做，要麼全都正確執行，要麼全都不執行。
• 一致性，指的是事務把數據庫從一種一致性狀態轉換成另外一種一致性狀態，事務開始前和事務結束後，數據庫的完整性約束沒有被破壞。
• 隔離性要求每一個讀寫事務相互之間是分開的，在事務提交前對其餘事務是不可見的
• 持久性，指的是事務一旦提交，其結果就是永久性的，即便宕機也能恢復。

事務的隔離級別，分別解決了什麼問題？

事務有4 個隔離級別，分別是：

• 讀未提交(read uncommit)
• 讀已提交(read commit)
• 可重複讀(repeatable read)
• 和序列化(serializable)。

隔離級別依次提升，分別解決了髒讀、不可重讀和幻讀。

1. 髒讀：事務A讀取了事務B更新的數據，而後B回滾操做，那麼A讀取到的數據是髒數據
2. 不可重複讀：事務 A 屢次讀取同一數據，事務 B 在事務A屢次讀取的過程當中，對數據做了更新並提交，致使事務A屢次讀取同一數據時，結果 不一致。
3. 幻讀：系統管理員A將數據庫中全部學生的成績從具體分數改成ABCDE等級，可是系統管理員B就在這個時候插入了一條具體分數的記錄，當系統管理員A改結束後發現還有一條記錄沒有改過來，就好像發生了幻覺同樣，這就叫幻讀
4. InnoDB 默認隔離級別爲repeatable read，可是經過next-key lock 解決了幻讀，保證了ACID。

不可重複讀的和幻讀很容易混淆，不可重複讀側重於修改，幻讀側重於新增或刪除。解決不可重複讀的問題只需鎖住知足條件的行，解決幻讀須要鎖表

3.2事務的實現原理？事務的分類？使用事務應該注意的問題？

事務的實現原理？

事務是基於重作日誌(redo log)文件和回滾日誌(undo log)實現的

每提交一個事務必須先將該事務的全部日誌寫入到重作日誌文件進行持久化，數據庫就能夠經過重作日誌來保證事務的原子性和持久性。

每當有修改事務時， 還會產生undo log，若是須要回滾， 則根據undo log反向語句進行邏輯操做，好比insert一條記錄就delete一條記錄。undo log主要實現數據庫的一致性， 還能夠用來實現MVCC。

事務的分類？

• 扁平事務
• 帶有保存點的扁平事務
• 鏈事務
• 嵌套事務
• 分佈式事務

使用事務應該注意的問題？

• 不要在循環中使用事務（循環提交會致使大量的redo log）
• 不要使用自動提交
• 不要使用自動回滾
• 長事務切分處理

四、SQL優化

4.一、sql優化的通常步驟?

a.經過show status命令瞭解各SQL執行的頻率

show [session|global] status like 「Com_%」;

• session：當前鏈接執行的統計結果
• global：上一次數據庫啓動至今的統計結果

常見的執行參數

• Com_select：執行查詢的次數
• Com_insert：執行插入的次數
• Com_update：執行更新的次數
• Com_delete：執行刪除的次數
• Com_rows_read：執行查詢的返回行數（觸類旁通：inserted、updated、deleted）
• Connection：試圖鏈接Mysql 服務器的次數
• Uptime：服務器工做時間
• Slow_queries：慢查詢次數

  1 mysql> show global status like "
  2 Slow_queries";
  3 +---------------+-------+
  4 | Variable_name | Value |
  5 +---------------+-------+
  6 | Slow_queries  | 0     |
  7 +---------------+-------+
  8 1 row in set

   

b. 定位執行效率最低的sql語句

能夠經過兩個辦法定位效率較低的SQL 語句：

• 經過慢查詢日誌定位執行效率低的SQL，可是隻能在查詢完事後
• 使用show processlist 命令查看當前Mysql 正在進行的線程，包括線程狀態、是否鎖表

c.經過EXPLAIN 分析低效SQL 的執行計劃

查詢到效率低的sql 語句後，能夠經過EXPLAIN 分析低效SQL 的執行計劃。

mysql> explain select * from comment 
;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table   | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | comment | NULL       | ALL  | NULL          | NULL | NULL    | NULL |   92 |      100 | NULL  |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set

mysql> 

• select_type: 表示select 的類型，常見取值有SIMPLE(簡單表，即不使用錶鏈接或者子查詢)、PRIMARY、UNION、SUBQUERY等。
• table: 輸出結果集的表
• type: 表示Mysql 的訪問方式(從上到下依次變快)
  • type=all，全表掃描，Mysql 遍歷全表來找到匹配的行
  • type=index，Mysql 遍歷整個索引來找到匹配的行
  • type=range，索引範圍掃面
  • type=ref，使用非惟一索引掃描或惟一索引的前綴掃描
  • type=eq_ref，使用惟一索引
  • type-const/system，單表中最多隻有一個匹配行
  • type=NUll，MySQL 不用訪問表或者索引就能直接獲得結果
• possible_key: 表示查詢時可能用到的索引
• key: 表示實際用到的索引
• key_len: 使用到索引字段的長度
• rows: 掃描行的數量
• Extra: 執行狀況的說明和描述。

d.經過show profile 分析SQL

//默認不開啓profile，使用時先開啓profile
mysql> set profiling=1;
Query OK, 0 rows affected

mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
|           1 |
+-------------+
1 row in set

//在InnoDB 下獲取錶行數
mysql> select count(*) from comment;
+----------+
| count(*) |
+----------+
|       92 |
+----------+
1 row in set

// 查開執行時間
mysql> show profiles;
+----------+------------+------------------------------+
| Query_ID | Duration   | Query                        |
+----------+------------+------------------------------+
|        1 |  0.0109785 | select @@profiling           |
|        2 | 0.05502275 | select count(*) from comment |
+----------+------------+------------------------------+
2 rows in set

//具體查開每一步執行時間
mysql> show profile for query 2
;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 9.2E-5   |
| checking permissions | 9E-6     |
| Opening tables       | 2E-5     |
| init                 | 1.8E-5   |
| System lock          | 9E-6     |
| optimizing           | 0.054635 |  //在優化處理耗時最多
| statistics           | 5.6E-5   |
| preparing            | 1.7E-5   |
| executing            | 5E-6     |
| Sending data         | 8E-5     |
| end                  | 5E-6     |
| query end            | 1.5E-5   |
| closing tables       | 9E-6     |
| freeing items        | 3.6E-5   |
| cleaning up          | 1.9E-5   |
+----------------------+----------+
15 rows in set

mysql> 

f. 還能夠經過trace 分析優化器如何選擇執行計劃的（有興趣能夠看一下）

 

4.2經常使用的SQL 的優化

a.對大批量插入數據

• MYISAM 表

能夠經過DISABLE KEY 和 ENABLE KEY 關閉和打開MYISAM 表索引的更新來提升效率。

1 ALTER TABLE table_name DISABLE KEY //在導入數據前關閉索引更新
2 loading the data
3 ALTER TABLE table_name ENABLE KEY //導入完成後開啓

 

• InnoDB 表
  • 按主鍵順序導入
  • 關閉惟一性檢驗，導入後再開啓
  • 關閉自動提交，導入後再開啓

b.優化INSERT 語句

• 同一個客戶端，應使用多個值表的insert 語句，這種方式能夠大大縮減客戶端與數據庫之間的鏈接、關閉等消耗。

  insert into table_name values(1,2)(1,3)(1,4)...

• 從不一樣的客戶端插入的話，能夠採用INSERT DELAYED 語句得到更高的速度。它的意思是讓INSERT 語句立刻執行，由於數據都被放在內存的隊列中，並無真正寫入磁盤。
• 從文本文件裝載一個表時，使用LOAD DATA INFILE 一般比INSERT 快20 倍。
• 將索引文件和數據文件分放在不一樣的磁盤上（利用建表中的選項）。
• 若是是批量插入，MYISAM 能夠經過改變bulk_insert_buffer_size （插入緩存容量大小）變量值提升速度。

c 優化order by 語句

• 在MySQL 數據庫中有兩種排序方式：
  • 經過有序索引掃描直接返回有序數據
  • 經過對返回數據進行排序（Filesort 排序）
• 其中Filesort 會多排一次序，因此在使用order by 語句的時候儘可能用到索引。下面的規則是能夠用到索引的狀況：
  • where 和 order by 使用相同的索引
  • order by 的順序和索引的順序相同
  • order by 的字段都是升序或都是降序
• 同理用不到索引的狀況：
  • order by 的字段混合ASC 和DESC
  • 用於查詢行的關鍵字與ORDER BY 中所使用的不一樣
  • 對不一樣的關鍵字使用order by

d. 優化group by 語句

默認狀況下group by 語句對分組的數據進行排序操做，若是不須要排序操做能夠經過order by null 禁止排序。

e. 優化嵌套語句

若是能夠的話，特別是where 中包含索引的狀況，用join 語法來代替嵌套語法（in）由於join 不須要在MySQL 的內存中建立臨時表。

f. 優化or語句

對於含有or 的查詢語句，若是要利用索引，則or 之間的每個條件都必須用到索引，若是沒用索引，能夠考慮增長索引。不然會全表掃面。

g. 優化分頁查詢

通常分頁查詢時，經過建立覆蓋索引可以比較好的提升性能。一個常見又頭痛的場景是"limit 1000,20" 此時MySQL 排序出前1020 條數據後，只須要返回20條數據，查詢和排序的代價都很高。有兩種優化方案

• 在索引上完成排序分頁的操做，最後根據主鍵關聯查詢須要的內容，讓MySQL 掃描儘量少的頁面來提升分頁操做。

   1 mysql> explain select comment_id,comment_content from comment order by comment_create_time limit 50,5;
   2 +----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+----------------+
   3 | id | select_type | table   | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
   4 +----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+----------------+
   5 |  1 | SIMPLE      | comment | NULL       | ALL  | NULL          | NULL | NULL    | NULL |   92 |      100 | Using filesort |
   6 +----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+----------------+
   7 1 row in set
   8 
   9 mysql> explain select a.comment_id,a.comment_content from comment a inner join(select comment_id from comment order by comment_create_time limit 50,5)b on a.comment_id=b.comment_id ;
  10 +----+-------------+------------+------------+--------+---------------+---------+---------+--------------+------+----------+----------------+
  11 | id | select_type | table      | partitions | type   | possible_keys | key     | key_len | ref          | rows | filtered | Extra          |
  12 +----+-------------+------------+------------+--------+---------------+---------+---------+--------------+------+----------+----------------+
  13 |  1 | PRIMARY     | <derived2> | NULL       | ALL    | NULL          | NULL    | NULL    | NULL         |   55 |      100 | NULL           |
  14 |  1 | PRIMARY     | a          | NULL       | eq_ref | PRIMARY       | PRIMARY | 4       | b.comment_id |    1 |      100 | NULL           |
  15 |  2 | DERIVED     | comment    | NULL       | ALL    | NULL          | NULL    | NULL    | NULL         |   92 |      100 | Using filesort |
  16 +----+-------------+------------+------------+--------+---------------+---------+---------+--------------+------+----------+----------------+
  17 3 rows in set

• 把limit 查詢轉換成某個位置的查詢，limit m,n -> limit n

h. 使用SQL 提示

SQL 提示是優化數據庫的一個重要手段，經常使用的SQL 提示：

• USE INDEX

推薦數據庫使用某個索引，可讓Mysql 再也不考慮其餘可用索引

 1 sql語句 use index(index_name); 

• IGNORE INDEX

忽視數據庫某個索引，可讓Mysql 再也不考慮這個索引

 1 sql語句 ignore index(index_name); 

• FORCE INDEX

強迫數據庫使用某個索引，使用use index 數據庫仍是可能不用這個索引，可是force index 數據庫必須使用這個索引

 1 sql語句 force index(index_name); 

五、sql語句 force index(index_name)

5.一、數據庫的三大範式

第一範式:

確保每列的原子性(強調的是列的原子性，即列不可以再分紅其餘幾列).若是每列(或者每一個屬性)都是不可再分的最小數據單元(也稱爲最小的原子單元),則知足第一範式.

例如:顧客表(姓名、編號、地址、……)其中"地址"列還能夠細分爲國家、省、市、區等。

第二範式:

在第一範式的基礎上更進一層,目標是確保表中的每列都和主鍵相關(一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須徹底依賴於主鍵，而不能只依賴於主鍵的部分)若是一個關係知足第一範式,而且除了主鍵之外的其它列,都依賴於該主鍵,則知足第二範式.

例如:訂單表(訂單編號、產品編號、定購日期、價格、……)，"訂單編號"爲主鍵，"產品編號"和主鍵列沒有直接的關係，即"產品編號"列不依賴於主鍵列，應刪除該列。

第三範式:

在第二範式的基礎上更進一層,目標是確保每列都和主鍵列直接相關,而不是間接相關(另外非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴).若是一個關係知足第二範式,而且不依賴於除了主鍵之外的其它列,則知足第三範式.

爲了理解第三範式，須要根據Armstrong千米之必定義傳遞依賴。假設A、B和C是關係R的三個屬性，若是A-〉B且B-〉C，則從這些函數依賴中，能夠得出A-〉C，如上所述，
依賴A-〉C是傳遞依賴。

例如:訂單表(訂單編號，定購日期，顧客編號，顧客姓名，……)，初看該表沒有問題，知足第二範式，每列都和主鍵列"訂單編號"相關，再細看你會發現"顧客姓名"和"顧客
編號"相關，"顧客編號"和"訂單編號"又相關，最後通過傳遞依賴，"顧客姓名"也和"訂單編號"相關。爲了知足第三範式，應去掉"顧客姓名"列，放入客戶表中。

 

5.二、 什麼是存儲過程？有哪些優缺點？

存儲過程是一些預編譯的SQL語句。

優勢：

• 存儲過程是一個預編譯的代碼塊，執行效率比較高
• 存儲過程在服務器端運行，減小客戶端的壓力
• 容許模塊化程序設計，只須要建立一次過程，之後在程序中就能夠調用該過程任意次，相似方法的複用
• 一個存儲過程替代大量T_SQL語句 ，能夠下降網絡通訊量，提升通訊速率
• 能夠必定程度上確保數據安全，對於沒有權限執行存儲過程的用戶，也可受權他們執行存儲過程。

缺點：

• 可移植性不靈活（由於存儲過程依賴於具體的數據庫）
• 不便於調試。
• 沒辦法應用緩存。雖然有全局臨時表之類的方法能夠作緩存，但一樣加劇了數據庫的負擔。若是緩存併發嚴重，常常要加鎖，那效率實在堪憂。
• 沒法適應數據庫的切割（水平或垂直切割）。數據庫切割以後，存儲過程並不清楚數據存儲在哪一個數據庫中。

5.3 說一說drop、delete與truncate的區別？

• drop直接刪掉表有關的一切（數據/結構/約束…），不會記錄日誌，爲DDL(Data Definition Language,數據庫定義語言)操做。
• truncate 刪除表中全部數據（再插入時自增加id又從1開始），該操做也不會記錄日誌因此比較快，爲DDL操做。只能刪table。
• DELETE語句執行刪除的過程是每次從表中刪除一行，須要記錄日誌，比較慢，能夠加where 語句，爲DML（Data Manipulation Language, 數據操縱語言）。能夠刪table 和view 。
• 速度上drop > truncate > delete

5.4 什麼是視圖？以及視圖的使用場景有哪些？

　　視圖是一種虛擬的表，具備和物理表相同的功能，沒有物理存儲。能夠對視圖進行增，改，查，操做，試圖一般是有一個表或者多個表的行或列的子集。對視圖的修改不影響基本表。它使得咱們獲取數據更容易，相比多表查詢。

使用場景：

• 只但願用戶查看特定信息的列
• 來源於多個表，能夠建立視圖提取咱們須要的信息，簡化操做。

5.5 超鍵、候選鍵、主鍵、外鍵分別是什麼？

超鍵：在關係中能惟一標識元組的屬性集稱爲關係模式的超鍵。一個屬性能夠爲做爲一個超鍵，多個屬性組合在一塊兒也能夠做爲一個超鍵。超鍵包含候選鍵和主鍵。

候選鍵：是最小超鍵，即沒有冗餘元素的超鍵。

主鍵：數據庫表中對儲存數據對象予以惟一和完整標識的數據列或屬性的組合。一個數據列只能有一個主鍵，且主鍵的取值不能缺失，即不能爲空值（Null）。

外鍵：在一個表中存在的另外一個表的主鍵稱此表的外鍵

5.6 Mysql 的幾種鏈接方式？

• 內鏈接：inner join on

組合兩個表中的記錄，返回關聯字段相符的記錄，也就是返回兩個表的交集（陰影）部分。

• 左鏈接：left join on / left outer join on

left join 是left outer join的簡寫，它的全稱是左外鏈接，是外鏈接中的一種。
左(外)鏈接，左表(a_table)的記錄將會所有表示出來，而右表(b_table)只會顯示符合搜索條件的記錄。右表記錄不足的地方均爲NULL。

• 右鏈接：right join on / right outer join on

right join是right outer join的簡寫，它的全稱是右外鏈接，是外鏈接中的一種。
與左(外)鏈接相反，右(外)鏈接，左表(a_table)只會顯示符合搜索條件的記錄，而右表(b_table)的記錄將會所有表示出來。左表記錄不足的地方均爲NULL。

• 全鏈接

MySQL目前不支持此種方式，能夠用其餘方式替代解決。

5.7 說一說什麼是Mysql 的完整性約束？

完整性約束是對字段進行限制，從而符合該字段達到咱們指望的效果好比字段含有默認值，不能是NULL等, 主要有惟1、自增、主鍵、外鍵約束

1 PRIMARY KEY (PK)    標識該字段爲該表的主鍵，能夠惟一的標識記錄
2 FOREIGN KEY (FK)    標識該字段爲該表的外鍵
3 NOT NULL    標識該字段不能爲空
4 UNIQUE KEY (UK)    標識該字段的值是惟一的
5 AUTO_INCREMENT    標識該字段的值自動增加（整數類型，並且爲主鍵）
6 DEFAULT    爲該字段設置默認值
7 
8 UNSIGNED 無符號
9 ZEROFILL 使用0填充

 

參考文章：https://blog.csdn.net/qq_36906627/java/article/details/86634518