【資料庫】SQL文法
https://blog.csdn.net/weixin_42915286/article/details/85339284
MySQL：
5K QPS
一般抗到2K就差不多了
資料庫原理
SQL是什麼？
SQL代表結構化查詢語言(Structured Query Language)。SQL是用于通路資料庫的标準化語言。
SQL包含三個部分：
- 資料定義語言包含定義資料庫及其對象的語句，例如表，視圖，觸發器，存儲過程等；
- 資料操作語言包含允許您更新和查詢資料的語句。
- 資料控制語言允許授予使用者權限通路資料庫中特定資料的權限。
關系型資料庫 與 非關系型資料庫
目前資料庫分為 關系型資料庫 和 非關系型資料庫
（關系型 與 分布式 相對立）；
1.關系型資料庫
關系型資料庫：指采用了關系模型（即表結構：二維表格模型）來組織資料 的 資料庫。
（非關系型資料庫：指非關系型的，分布式的，且一般不保證遵循ACID原則的資料存儲系統。）
關系模型指的就是二維表格模型，而一個關系型資料庫就是由二維表及其之間的聯系所組成的一個資料組織。
關系模型中常用的概念：
關系：（表名）一張二維表，每個關系都具有一個關系名，也就是表名
元組：（行）二維表中的一行，在資料庫中被稱為記錄
屬性：（列）/（字段） 二維表中的一列，在資料庫中被稱為字段
域：（屬性取值範圍） 屬性的取值範圍，也就是資料庫中某一列的取值限制
關鍵字：一組可以唯一辨別元組的屬性，資料庫中常稱為主鍵 Primary Key，由一個或多個列組成
關系模式：（表結構） 指對關系的描述。其格式為：關系名(屬性1，屬性2， … … ，屬性N)，在資料庫中成為表結構
碼：表中可以唯一确定一個元組的某個屬性（或者屬性組），如果這樣的碼有不止一個，那麼大家都叫候選碼，我們從候選碼中挑一個出來做老大，它就叫主碼。
傳遞依賴：
關系型資料庫的優點：
1.容易了解：二維表結構是非常貼近邏輯世界的一個概念，關系模型相對網狀、層次等其他模型來說更容易了解
2.使用友善：通用的SQL語言使得操作關系型資料庫非常友善
3.易于維護：豐富的完整性(實體完整性、參照完整性和使用者定義的完整性)大大減低了資料備援和資料不一緻的機率；
關系型資料庫存在的問題：
1.網站的使用者并發性非常高，往往達到每秒上萬次讀寫請求，對于傳統關系型資料庫來說，硬碟I/O是一個很大的瓶頸；
2.網站每天産生的資料量是巨大的，對于關系型資料庫來說，在一張包含海量資料的表中查詢，效率是非常低的；
3.在基于web的結構當中，資料庫是最難進行橫向擴充的，當一個應用系統的使用者量和通路量與日俱增的時候，資料庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬體和服務節點來擴充性能和負載能力。當需要對資料庫系統進行更新和擴充時，往往需要停機維護和資料遷移。
4.性能欠佳：在關系型資料庫中，導緻性能欠佳的最主要原因是多表的關聯查詢，以及複雜的資料分析類型的複雜SQL報表查詢。為了保證資料庫的ACID特性，必須盡量按照其要求的範式進行設計，關系型資料庫中的表都是存儲一個格式化的資料結構。
資料庫事務必須具備ACID特性，ACID分别是Atomicity原子性，Consistency一緻性，
Isolation隔離性，Durability持久性。
當今十大主流的關系型資料庫：
Oracle，Microsoft SQL Server，MySQL，PostgreSQL，DB2，
Microsoft Access， SQLite，Teradata，MariaDB(MySQL的一個分支)，SAP
2.非關系型資料庫
非關系型資料庫：指非關系型的，分布式的，且一般不保證遵循ACID原則的資料存儲系統。
（嚴格上來說不是資料庫，而是 資料結構化存儲方法的集合）
非關系型資料庫結構：
非關系型資料庫以鍵值對存儲，且結構不固定，每一個元組可以有不一樣的字段，每個元組可以根據需要增加一些自己的鍵值對，不局限于固定的結構，可以減少一些時間和空間的開銷。
優點：
1.使用者可以根據需要去添加自己需要的字段，為了擷取使用者的不同資訊，不像關系型資料庫中，要對多表進行關聯查詢。僅需要根據id取出相應的value就可以完成查詢。
2.适用于SNS(Social Networking Services)中，例如facebook，微網誌。系統的更新，功能的增加，往往意味着資料結構巨大變動，這一點關系型資料庫難以應付，需要新的結構化資料存儲。由于不可能用一種資料結構化存儲應付所有的新的需求，是以，非關系型資料庫嚴格上不是一種資料庫，應該是一種資料結構化存儲方法的集合。
不足：
1.隻适合存儲一些較為簡單的資料；
2.對于需要進行較複雜查詢的資料，關系型資料庫顯的更為合适；
3.不适合 持久存儲海量資料；
非關系型資料庫的分類：
非關系型資料庫都是針對某些特定的應用需求出現的，是以，對于該類應用，具有極高的性能。依據結構化方法以及應用場合的不同，主要分為以下幾類：
面向高性能并發讀寫的key-value資料庫：
key-value資料庫的主要特點是具有極高的并發讀寫性能
Key-value資料庫是一種以鍵值對存儲資料的一種資料庫，類似Java中的map。可以将整個資料庫了解為一個大的map，每個鍵都會對應一個唯一的值。
主流代表：
Redis， Amazon DynamoDB， Memcached，MangoDB
Microsoft Azure Cosmos DB和Hazelcast
提問：屬于關系型資料庫的是？
A.Oracle
B.MySQL
C.Redis
D.MongoDB
答：
AB
資料庫的事務屬性：ACID原則
事務：資料庫中一個單獨的執行單元；
事務必須滿足4個屬性：
1.Atomicity 原子性
事務是一個不可分割的整體，為保證事務的總體目标，事務必須具有原子性；
當資料修改時，要麼全執行，要麼全不執行；即不允許事務部分完成，避免了隻執行這些操作的一部分而帶來的錯誤；
比如：網購付款環節，由于遭遇停電，環節出了差錯，不允許發生使用者已付款，但訂單未被生成的情況；原子性要求事務必須被完整執行；
2.Consistency 一緻性
一個事務執行前後，資料庫必須保持一緻性狀态；
如銀行轉帳，轉賬前後，兩個賬戶的金額總和必須保持一緻，不允許發生由于并發操作帶來的資料丢失、讀髒資料、産生幽靈資料；
3.Isolation 隔離性
當兩個或多個事務并發執行時，為保證資料的安全性，講一個事務内部的操作與事務操作隔離起來，不被其他正在進行的事務看到；
資料庫有4種類型的事務隔離級别：
1).不送出的讀 READ_UNCOMMITTED
2).送出的讀 READ_COMMITTED
3).可重複的讀 REPETABLE_READ
4).串行化 SERIALIZABLE
4.Durability 持久性（永久性）
事務完成後，DBMS保證他對資料庫中的資料的修改是永久性的，當系統或者媒體發生故障時，該修改也永久保持。持久性一般通過資料庫備份和恢複來保證；
綜上，資料庫事務屬性ACID都是由資料庫管理系統來進行保證，程式員在整個運作過程中，無需考慮實作ACID；
範式 Normal Form (NF)
轉自：http://blog.chinaunix.net/uid-10073362-id-225057.html
範式是符合某一種級别的關系模式的集合。
資料庫範式是資料庫設計中必不可少的知識；
沒有對範式的了解，就無法設計出高效率、優雅的資料庫，甚至設計出錯誤的資料庫。而想要了解并掌握範式卻并不是那麼容易。教科書中一般以關系代數的方法來解釋資料庫範式。這樣做雖然能夠十分準确的表達資料庫範式，但比較抽象，不太直覺，不便于了解，更難以記憶。
本章用較為直白的語言介紹範式，旨在便于了解和記憶，這樣做可能會出現一些不精确的表述。
首先要明白，範式的包含關系：
一個資料庫設計如果符合第二範式，一定也符合第一範式；
如果符合第三範式，一定也符合第二範式……
(1).1NF 第一範式
指資料表中每一列都是 【不可分】 的基本資料項；
重點是【不可分】（即原子性）：
這讓我想起自己以前設計一個“學生成績表”時所遇到的問題：
表格中：sno=1的學生有四門成績，那麼如何妥善把這四門成績放入表格？
當初的想法是：把四門成績全部擠在sno=1的這一行中；但結果可想而知，無法做到；
經過指點後才知，應該配置四個sno=1的行，分别把四門成績配置在這四行中。
最初的想法違背了第一範式“不可分”的原則，也就不叫關系型資料庫了。
————————————————————
(2).2NF 第二範式
必須先滿足1NF，且要求資料庫表中每個執行個體或行必須可以被唯一區分；
符合1NF，并且，非主屬性完全依賴于碼。（注意是完全依賴不能是部分依賴，設有函數依賴W→A，若存在XW為碼，有X→A成立，那麼稱W→A是局部依賴，否則就稱W→A是完全函數依賴）
一個學生上一門課，一定是特定某個老師教。是以 （學生，課程）－>老師；
一個學生上一門課，一定在特定某個教室。是以 （學生，課程）－>教室；
一個學生上一門課，他老師的職稱可以确定。是以 （學生，課程）－>老師職稱；
一個學生上一門課，一定是特定某個教材。是以 （學生，課程）－>教材
一個學生上一門課，一定在特定時間。是以 （學生，課程）－>上課時間
是以 （學生，課程） 是一個碼。
但，一個教材一定是由一個課程指定的（課程：一年級國文 指定了教材：《國小國文1》）；
那麼就有：
課程－>教材
回過頭看， （學生，課程） 是個碼，上方的結論中卻是：課程指定了教材；這就叫做不完全依賴，或者說部分依賴；
出現這樣的情況，就不滿足第二範式。
那應該怎麼解決呢？投影分解，将一個表分解成兩個或若幹個表：
把教材列放在另一張表，兩張表中都有課程列；
新關系通過學生表中的外關鍵字：課程 聯系，在需要時進行連接配接；
————————————————————
(3).3NF 第三範式
符合2NF，并且，消除傳遞依賴（也就是每個非主屬性都不傳遞依賴于候選鍵，判斷傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴于A。）
上面的“學生上課新表”符合2NF，但是它有傳遞依賴！在哪呢？
（學生，課程）－> 老師
（老師）－> 老師職稱
看上去，職稱和（學生，課程）沒有一點關系；
然而，（學生，課程）－> （老師）
是以這是一個依賴傳遞；
依賴傳遞帶來的問題：
1、老師更新了，變教授了，要改資料庫，表中有N條，改了N次……（修改異常）
2、沒人選這個老師的課了，老師的職稱也沒了記錄……（删除異常）
3、新來一個老師，還沒配置設定教什麼課，他的職稱記到哪？……（插入異常）
那應該怎麼解決呢？和上面一樣，投影分解：
第二範式（2NF）和第三範式（3NF）的概念很容易混淆，區分它們的關鍵點在于：
2NF：非主鍵列是否完全依賴于主鍵，還是依賴于主鍵的一部分；
3NF：非主鍵列是直接依賴于主鍵，還是直接依賴于非主鍵列。
簡單總結1/2/3範式：
第一範式（1NF）無重複的列（原子性）；原子性，字段不可再分割；
第二範式（2NF）屬性完全依賴于主鍵；完全依賴，沒有部分依賴；
第三範式（3NF）屬性不依賴于其它非主屬性；沒有傳遞依賴。
舉個例子：
◆ 第二範式（2NF）：
考慮一個訂單明細表：【OrderDetail】
（
OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName
）。
因為我們知道在一個訂單中可以訂購多種産品，是以單單一個 OrderID 是不足以成為主鍵的，主鍵應該是（
OrderID，ProductID
）；
顯而易見 Discount（折扣），Quantity（數量）完全依賴（取決）于主鍵（OderID，ProductID），而 UnitPrice（總價），ProductName（産品名） 隻依賴于 ProductID。是以 OrderDetail 表存在部分依賴，不符合 2NF。不符合 2NF 的設計容易産生備援資料。
可以把【OrderDetail】表拆分為：
【OrderDetail】（
OrderID，ProductID，Discount，Quantity
）和
【Product】（
ProductID，UnitPrice，ProductName
）
來消除原訂單表中UnitPrice，ProductName多次重複的情況。
OrderID，ProductID
→ 完全依賴的列
ProductID
→ ProductName,UnitPrice（部分依賴）
部分依賴：因為依賴的是主鍵中的一部分；
◆ 第三範式（3NF）：
考慮一個訂單表【Order】
（
OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity
）
主鍵是（
OrderID
）；
其中
OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity
等非主鍵列都完全依賴于主鍵（
OrderID
），是以符合 2NF；
不過問題是
CustomerName
（買家姓名），
CustomerAddr
（收獲位址），
CustomerCity
（收貨城市） 直接依賴的是
CustomerID
（非主鍵列），而不是直接依賴于主鍵，它傳遞依賴于主鍵，是以不符合 3NF。
通過拆分【Order】為
【Order】（
OrderID，OrderDate，CustomerID
）和
【Customer】（
CustomerID，CustomerName，CustomerAddr，CustomerCity
）
進而達到 3NF。
OrderID
→ 完全依賴的列
CustomerID
→
CustomerName
，
CustomerAddr
，
CustomerCity
（傳遞依賴）
傳遞依賴：因為依賴跟主鍵無關，隔着一個參數進行了依賴：
OrderID
→
CustomerID
→
CustomerName
，
CustomerAddr
，
CustomerCity
————————————————————
(4).BCNF
符合3NF，并且，主屬性不依賴于主屬性(也就是不存在任何字段對任一候選關鍵字段的傳遞函數依賴)
BC範式既檢查非主屬性，又檢查主屬性。當隻檢查非主屬性時，就成了第三範式。滿足BC範式的關系都必然滿足第三範式。
還可以這麼說：若一個關系達到了第三範式，并且它隻有一個候選碼，或者它的每個候選碼都是單屬性，則該關系自然達到BC範式。
給你舉個例子：假設倉庫管理關系表 (倉庫ID, 存儲物品ID, 管理者ID, 數量)，且有一個管理者隻在一個倉庫工作；一個倉庫可以存儲多種物品。
這個資料庫表中存在如下決定關系：
(倉庫ID, 存儲物品ID) →(管理者ID, 數量)
(管理者ID, 存儲物品ID) → (倉庫ID, 數量)
是以，(倉庫ID, 存儲物品ID)和(管理者ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵字段為數量，它是符合第三範式的。但是，由于存在如下決定關系：
(倉庫ID) → (管理者ID)
(管理者ID) → (倉庫ID)
即存在關鍵字段決定關鍵字段的情況，是以其不符合BCNF範式。它會出現如下異常情況：
(1) 删除異常：
當倉庫被清空後，所有"存儲物品ID"和"數量"資訊被删除的同時，"倉庫ID"和"管理者ID"資訊也被删除了。
(2) 插入異常：
當倉庫沒有存儲任何物品時，無法給倉庫配置設定管理者。
(3) 更新異常：
如果倉庫換了管理者，則表中所有行的管理者ID都要修改。
把倉庫管理關系表分解為二個關系表：
倉庫管理：StorehouseManage(倉庫ID, 管理者ID)；
倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。
這樣的資料庫表是符合BCNF範式的，消除了删除異常、插入異常和更新異常。
一般，一個資料庫設計符合3NF或BCNF就可以了。
————————————————————
(5).4NF 第四範式
在BC範式以上還有第四範式、第五範式。
·第四範式：要求把同一表内的多對多關系删除。
·第五範式：從最終結構重建立立原始結構。
其實資料庫設計範式這方面重點掌握的就是1NF、2NF、3NF、BCNF
四種範式之間存在如下關系：
這裡主要差別3NF和BCNF，一句話就是3NF是要滿足不存在非主屬性對候選碼的傳遞函數依賴，BCNF是要滿足不存在任一屬性（包含非主屬性和主屬性）對候選碼的傳遞函數依賴。