mysql數據庫範式（mysql數據庫範式作業）

本文目錄一覽：

• 1、第一範式第二範式第三範式怎麼區分？
• 2、什麼是數據庫中的規範化?
• 3、數據庫（mysql）關鍵知識
• 4、MySQL數據庫性能優化之分區分表分庫
• 5、數據庫第二範式和第三範式的區別的是什麼？

第一範式第二範式第三範式怎麼區分？

滿足第一範式 就是每個屬性都不可在拆分，滿足第二範式，非屬性值要完全依賴主編碼 非碼屬性不相互依賴，滿足第三範式，不存在傳遞依賴。

什麼是數據庫中的規範化?

規範化理論把關係應滿足的規範要求分為幾級，滿足最低要求的一級叫做第一範式(1NF)，在第一範式的基礎上提出了第二範式(2NF)，在第二範式的基礎上又提出了第三範式(3NF)，以後又提出了BCNF範式，4NF，5NF。範式的等級越高，應滿足的約束集條件也越嚴格。

第一範式（1NF）

在關係模式R中中，如果每個屬性值都是不可再分的原子屬性，則稱R是第一範式的關係[2]。例如：關係R（職工號，姓名，電話號碼）中一個人可能有一個辦公室電話和一個住宅電話號碼，規範成為1NF的方法一般是將電話號碼分為單位電話和住宅電話兩個屬性，即 R（職工號，姓名，辦公電話，住宅電話）。1NF是關係模式的最低要求。

第二範式（2NF）

如果關係模式R是1NF且其中的所有非主屬性都完全函數依賴於關鍵字，則稱關係R 是屬於第二範式的[2]。例：選課關係 SC（SNO，CNO，GRADE，CREDIT）其中SNO為學號， CNO為課程號，GRADEGE 為成績，CREDIT 為學分。 由以上條件，關鍵字為組合關鍵字（SNO，CNO）。在應用中使用以上關係模式有以下問題： （1）數據冗餘，假設同一門課由40個學生選修，學分就重複40次；（2）更新複雜，若調整了某課程的學分，相應元組的CREDIT值都要更新，有可能會出現同一門課學分不同；（3）插入異常，如計劃開新課，由於沒人選修，沒有學號關鍵字，只能等有人選修才能把課程和學分存入；（4）.刪除異常，若學生已經結業，從當前數據庫刪除選修記錄，而某些課程新生尚未選修，則此門課程及學分記錄無法保存。以上問題產生的原因是非主屬性CREDIT僅函數依賴於CNO，也就是CREDIT部分依賴組合關鍵字（SNO，CNO）而不是完全依賴。解決方法是將以上關係分解成兩個關係模式 SC（SNO，CNO，GRADE）和C（CNO，CREDIT）。新關係包括兩個關係模式，它們之間通過SC中的外鍵CNO相聯繫，需要時再進行自然聯接，恢復原來的關係

第三範式（3NF）

如果關係模式R是2NF且其中的所有非主屬性都不傳遞依賴於碼，則稱關係R是屬於第三範式的[1]。例如關係模式S（SNO，SNAME，DNO，DNAME，LOCATION）中各屬性分別代表學號、姓名、所在系、系名稱、系地址。關鍵字SNO決定各個屬性。由於是單個關鍵字，沒有部分依賴的問題，肯定是2NF。但關係S肯定有大量的冗餘，有關學生所在系的幾個屬性DNO，DNAME，LOCATION將重複存儲，插入、刪除和修改時也將產生類似以上例的情況。原因在於關係中存在傳遞依賴，即SNO – DNO，DNO – LOCATION, 因此關鍵字SNO對LOCATION函數決定是通過傳遞依賴SNO – LOCATION 實現的。也就是說，SNO不直接決定非主屬性LOCATION。解決方法是將該關係模式分解為兩個關係S（SNO，SNAME，DNO）和D（DNO，DNAME，LOCATION），兩個關係通過S中的外鍵DNO聯繫。

BC範式(BCNF)

如果關係模式R的所有屬性（包括主屬性和非主屬性）都不傳遞依賴於R的任何候選關鍵字，那麼稱關係R是屬於BCNF的。或者說關係模式R中，如果每個決定因素都包含關鍵字（而不是被關鍵字所包含），則R是BCNF[3]。 通常認為BCNF是修正的第三範式，有時也稱為擴充的第三範式。

數據庫（mysql）關鍵知識

Mysql是目前互聯網使用最廣的關係數據庫，關係數據庫的本質是將問題分解為多個分類然後通過關係來查詢。 一個經典的問題是用戶借書，三張表，一個用戶，一個書，一個借書的關係表。當需要查詢某個用戶借書情況或者是書被那些人借了，就用關係查詢來實現。

關係數據庫範式

來自英文Normal form，簡稱NF。要想設計—個好的關係，必須使關係滿足一定的約束條件，滿足這些規範的數據庫是簡潔的、結構明晰的，同時，不會發生插入(insert)、刪除(delete)和更新(update)操作異常。總共有六種範式：第一範式（1NF）、第二範式（2NF）、 第三範式 （3NF）、巴斯-科德範式（BCNF）、 第四範式 (4NF）和 第五範式 （5NF，又稱完美範式）。

1NF是指數據庫表的每一列都是不可分割的原子數據項。2NF必須滿足1NF，要求數據庫表中的每行記錄必須可以被唯一地區分。3NF在2NF基礎上，任何非主 屬性 不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）。BCNF是在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）， 滿足BCNF不再會有任何由於函數依賴導致的異常，但是我們還可能會遇到由於多值依賴導致的異常。4NF的定義很簡單：已經是BC範式，並且不包含多值依賴關係。5NF處理的是無損連接問題，這個範式基本沒有實際意義，因為無損連接很少出現，而且難以察覺。而域鍵範式試圖定義一個終極範式，該範式考慮所有的依賴和約束類型，但是實用價值也是最小的，只存在理論研究中。

Catalog和Schema

是數據庫對象命名空間中的層次，主要用來解決命名衝突的問題。從概念上說，一個數據庫系統包含多個Catalog，每個Catalog又包含多個Schema，而每個Schema又包含多個數據庫對象（表、視圖、字段等）。但是Mysql的數據庫名就是Schema，不支持Catalog。

Mysql的數據庫引擎主要有兩種MyISAM和InnoDB，MyISAM支持全文檢索，InnoDB支持事務。

SQL中的通配符‘%’代表任意字符出現任意次數。‘_’代表任意字符出現一次。SQL與正則表達式結合查詢一般用在WHERE table_name REGEXP ‘^12.34’。子查詢是從裡到外執行。

數據庫聯結（join）涉及到外鍵，外鍵是指一個表的列是另一個表的主鍵，那麼它就是外鍵。笛卡爾積聯結（不指定聯結條件時）生成的記錄條目是單純的第一個表的行乘以第二個表的列數。用得最多的是等值聯結也叫內部聯結。

高級聯結還有自連接，是指查詢中的兩張表是同一張表，它通常作為外部語句用來代替從相同表中檢索數據時使用的子查詢。自然聯結使每個列只返回一次。外部聯結是指聯結包含了那些在相關表中沒有關聯行的行。例如列出所有產品及其訂購數量，包括沒有人訂購的產品。LEFT OUTER JOIN指選擇左邊表的所有行。

組合查詢是指採用UNION等將兩個查詢結果取並集。

視圖是查看存儲在別處的數據的一種工具，它本身並不包含數據，因此表的數據修改了，視圖返回的數據也將隨之修改，因此如果使用了複雜或嵌套視圖會對性能有較大的影響。視圖的作用之一是隱藏複雜的SQL通常會涉及到聯結查詢。

存儲過程類似於批處理，包含了一條或多條SQL語句。語法：

CREATE PROCEDURE name（）

BEGIN

SQL

END

————————-

CALL name（）//來調用存儲過程

游標有DECLARE定義，游標與存儲過程是綁定的，存儲過程處理完成，游標就會消失。游標被打開後可以使用FETCH語句訪問每一行。

觸發器是在某個時間發生時自動執行某條SQL語句。語法：

CREATE TRIGGER name AFTER INSERT ON talbe_name FOR EACH ROW

事務處理可以維護數據庫的完整性，保證批量的操作要麼完全執行，要麼完全不執行。包括事務、回退、提交、保留點幾個關鍵術語。ROLLBACK只能在一個事務處理內使用。他不能回退CREATE和DROP操作。使用COMMIT保證事務提交。複雜的事務處理需要部分提交或回退，因此我們需要使用保留點SAVEPOINT。可以使用ROLLBACK TO savepoint_name。保留點越多越好。保留點在事務執行完成後自動釋放。

MySQL數據庫性能優化之分區分表分庫

分表是分散數據庫壓力的好方法。

分表，最直白的意思，就是將一個表結構分為多個表，然後，可以再同一個庫里，也可以放到不同的庫。

當然，首先要知道什麼情況下，才需要分表。個人覺得單表記錄條數達到百萬到千萬級別時就要使用分表了。

分表的分類

**1、縱向分表**

將本來可以在同一個表的內容，人為劃分為多個表。（所謂的本來，是指按照關係型數據庫的第三範式要求，是應該在同一個表的。）

分表理由：根據數據的活躍度進行分離，（因為不同活躍的數據，處理方式是不同的）

案例：

對於一個博客系統，文章標題，作者，分類，創建時間等，是變化頻率慢，查詢次數多，而且最好有很好的實時性的數據，我們把它叫做冷數據。而博客的瀏覽量，回複數等，類似的統計信息，或者別的變化頻率比較高的數據，我們把它叫做活躍數據。所以，在進行數據庫結構設計的時候，就應該考慮分表，首先是縱向分表的處理。

這樣縱向分表後：

首先存儲引擎的使用不同，冷數據使用MyIsam 可以有更好的查詢數據。活躍數據，可以使用Innodb ,可以有更好的更新速度。

其次，對冷數據進行更多的從庫配置，因為更多的操作時查詢，這樣來加快查詢速度。對熱數據，可以相對有更多的主庫的橫向分表處理。

其實，對於一些特殊的活躍數據，也可以考慮使用memcache ,redis之類的緩存，等累計到一定量再去更新數據庫。或者mongodb 一類的nosql 數據庫，這裡只是舉例，就先不說這個。

**2、橫向分表**

字面意思，就可以看出來，是把大的表結構，橫向切割為同樣結構的不同表，如，用戶信息表，user_1,user_2等。表結構是完全一樣，但是，根據某些特定的規則來劃分的表，如根據用戶ID來取模劃分。

分表理由：根據數據量的規模來劃分，保證單表的容量不會太大，從而來保證單表的查詢等處理能力。

案例：同上面的例子，博客系統。當博客的量達到很大時候，就應該採取橫向分割來降低每個單表的壓力，來提升性能。例如博客的冷數據表，假如分為100個表，當同時有100萬個用戶在瀏覽時，如果是單表的話，會進行100萬次請求，而現在分表後，就可能是每個表進行1萬個數據的請求（因為，不可能絕對的平均，只是假設），這樣壓力就降低了很多很多。

延伸：為什麼要分表和分區？

日常開發中我們經常會遇到大表的情況，所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，導致數據庫在查詢和插入的時候耗時太長，性能低下，如果涉及聯合查詢的情況，性能會更加糟糕。分表和表分區的目的就是減少數據庫的負擔，提高數據庫的效率，通常點來講就是提高表的增刪改查效率。

什麼是分表？

分表是將一個大表按照一定的規則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應三個文件，MYD數據文件，.MYI索引文件，.frm表結構文件。這些子表可以分布在同一塊磁盤上，也可以在不同的機器上。app讀寫的時候根據事先定義好的規則得到對應的子表名，然後去操作它。

什麼是分區？

分區和分表相似，都是按照規則分解表。不同在於分表將大表分解為若干個獨立的實體表，而分區是將數據分段劃分在多個位置存放，可以是同一塊磁盤也可以在不同的機器。分區後，表面上還是一張表，但數據散列到多個位置了。app讀寫的時候操作的還是大表名字，db自動去組織分區的數據。

**MySQL分表和分區有什麼聯繫呢？**

1、都能提高mysql的性高，在高並髮狀態下都有一個良好的表現。

2、分表和分區不矛盾，可以相互配合的，對於那些大訪問量，並且表數據比較多的表，我們可以採取分表和分區結合的方式（如果merge這種分表方式，不能和分區配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以採取分區的方式等。

3、分表技術是比較麻煩的，需要手動去創建子表，app服務端讀寫時候需要計算子表名。採用merge好一些，但也要創建子表和配置子表間的union關係。

4、表分區相對於分表，操作方便，不需要創建子表。

我們知道對於大型的互聯網應用，數據庫單表的數據量可能達到千萬甚至上億級別，同時面臨這高並發的壓力。Master-Slave結構只能對數據庫的讀能力進行擴展，寫操作還是集中在Master中，Master並不能無限制的掛接Slave庫，如果需要對數據庫的吞吐能力進行進一步的擴展，可以考慮採用分庫分表的策略。

**1、分表**

在分表之前，首先要選中合適的分表策略（以哪個字典為分表字段，需要將數據分為多少張表），使數據能夠均衡的分布在多張表中，並且不影響正常的查詢。在企業級應用中，往往使用org_id(組織主鍵)做為分表字段，在互聯網應用中往往是userid。在確定分表策略後，當數據進行存儲及查詢時，需要確定到哪張表裡去查找數據，

數據存放的數據表 = 分表字段的內容 % 分表數量

**2、分庫**

分表能夠解決單表數據量過大帶來的查詢效率下降的問題，但是不能給數據庫的並發訪問帶來質的提升，面對高並發的寫訪問，當Master無法承擔高並發的寫入請求時，不管如何擴展Slave服務器，都沒有意義了。我們通過對數據庫進行拆分，來提高數據庫的寫入能力，即所謂的分庫。分庫採用對關鍵字取模的方式，對數據庫進行路由。

數據存放的數據庫=分庫字段的內容%數據庫的數量

**3、即分表又分庫**

數據庫分表可以解決單表海量數據的查詢性能問題，分庫可以解決單台數據庫的並發訪問壓力問題。

當數據庫同時面臨海量數據存儲和高並發訪問的時候，需要同時採取分表和分庫策略。一般分表分庫策略如下：

中間變量 = 關鍵字%（數據庫數量*單庫數據表數量）

庫 = 取整（中間變量/單庫數據表數量）

表 = （中間變量%單庫數據表數量）

實例：

1、分庫分表

很明顯，一個主表（也就是很重要的表，例如用戶表）無限制的增長勢必嚴重影響性能，分庫與分表是一個很不錯的解決途徑，也就是性能優化途徑，現在的案例是我們有一個1000多萬條記錄的用戶表members,查詢起來非常之慢，同事的做法是將其散列到100個表中，分別從members0到members99，然後根據mid分發記錄到這些表中，牛逼的代碼大概是這樣子：

複製代碼 代碼如下:

?php

for($i=0;$i 100; $i++ ){

//echo “CREATE TABLE db2.members{$i} LIKE db1.members

“;

echo “INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}

“;

}

?

2、不停機修改mysql表結構

同樣還是members表，前期設計的表結構不盡合理，隨着數據庫不斷運行，其冗餘數據也是增長巨大，同事使用了下面的方法來處理：

先創建一個臨時表：

/*創建臨時表*/

CREATE TABLE members_tmp LIKE members

然後修改members_tmp的表結構為新結構，接着使用上面那個for循環來導出數據，因為1000萬的數據一次性導出是不對的，mid是主鍵，一個區間一個區間的導，基本是一次導出5萬條吧，這裡略去了

接着重命名將新表替換上去：

/*這是個頗為經典的語句哈*/

RENAME TABLE members TO members_bak,members_tmp TO members;

就是這樣，基本可以做到無損失，無需停機更新表結構，但實際上RENAME期間表是被鎖死的，所以選擇在線少的時候操作是一個技巧。經過這個操作，使得原先8G多的表，一下子變成了2G多。

數據庫第二範式和第三範式的區別的是什麼？

一、含義不同：

第二範式（2NF）：關係模式R屬於第一範式，且每個非主屬性都完全函數依賴於鍵碼。

第三範式（3NF）：關係模式R屬於第一範式，且每個非主屬性都不偉遞領帶於鍵碼。

二、內容不同：

第二範式（2NF）：首先是 1NF，另外包含兩部分內容，一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。

第三範式（3NF）：首先是 2NF，另外非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。

第二範式

通常稱這種關係為函數依賴(Functional dependence)關係，即表中其他數據元素都依賴於主關鍵字,或稱該數據元素惟一地被主關鍵字所標識。第二範式是數據庫規範化中所使用的一種正規形式。它的規則是要求數據表裡的所有非主屬性都要和該數據表的主鍵有完全依賴關係；如果有哪些非主屬性只和主鍵的一部份有關的話，它就不符合第二範式。

以上內容參考：百度百科-第二範式