優化器的特點
優化器並不關心表使用的是什麼儲存引擎，但儲存引擎對於優化查詢是有影響的
讀鎖和寫鎖
讀鎖是共享的，或者說是相遇不阻塞的。
寫鎖是排他的，意思是乙個寫鎖會阻塞其他的寫鎖和讀鎖，也就是在給定的時間裡，只有乙個使用者能執行寫入，並防止其他使用者讀取正在寫入的同一資源。
鎖的分別
鎖粒度 ：只對會修改的資料片進行精確的鎖定
表鎖 ：會鎖定整張表
行級鎖acid表示原子性、一致性、隔離性和永續性
原子性 ：乙個事務必須被視為乙個不可分割的最小工作單元，整個事務中的操作要麼全部提交成功，要麼全部是被回滾
一致性 ：資料庫總是從乙個一致性的狀態轉換到另外乙個一致性的狀態
隔離性 ：乙個事務在最終提交之前，對其他事務是不可見的
永續性 ：一旦事務提交，則所做的修改就會永遠儲存到資料庫中
隔離級別
read uncommitted(未提交讀) ：事務中的修改，即使沒有提交，對其他事務也都是可見的，事務可以讀取未提交的資料，被稱為髒讀
read committed(提交讀) ：乙個事務開始時，只能看見已經提交的事務所做的修改。乙個事務從開始直到提交之前，所做的任何修改對其他事務都是不可見的
repeatable read(可重複讀) : 保證了在同乙個事務中多次讀取同樣的記錄的結果是一致的
phantom read(幻讀) ：某個事務在讀取某個範圍的記錄時，另外乙個事務又在該範
圍內插入了新的記錄，當再次讀取該範圍的記錄時，會產生幻行
serializable(可序列化) ：強制事務序列執行，避免了幻讀的問題
死鎖的介紹
死鎖 ：是指兩個或多個事務在同一資源上相互占用，並請求鎖定對方占用的資源，從而導致惡性迴圈的現象，當多個事務檢視以不同的順序鎖定資源時，就可能會產生死鎖。多個事務同時鎖定同一資源時，也會產生死鎖
死鎖發生以後，只有部分或完全回滾其中乙個事務，才能打破死鎖
MySql的架構和歷史
架構為如下 儲存引擎 負責資料的儲存和提取，供了幾十個api供服務層進行呼叫。各個儲存引擎之間不會進行互動，只是供服務層進行呼叫。事務控制和鎖的管理也是在儲存引擎裡面進行。服務層 乙個sql過來之後，會在服務層進行解析，建立解析樹，呼叫底層的儲存引擎得到各種開銷資訊和統計資訊，進行各種優化，決定表的...
前端框架發展歷史
將乙個軟體分為三個部分，每乙個部分負責一部分功能 m model 模型 軟體中的資料 v view 檢視 軟體中的介面 c controller 控制器 軟體中的大腦，用於處理邏輯jq開發，原生js開發時，我們發現所有的業務邏輯和資料處理都壓在v身上 mvc引入幫我們解決了這個問題 mvc引入帶來模...
Mysql的架構和歷史（二）
事務 隔離級別 sql標準定義了四種隔離級別 read uncommitted 未提交讀 在這個級別中所有事務可以讀取到當前事務對資料所正在進行的修改操作。read committed 提交讀 該級別，所有事務只能讀取到事務提交之後的資料只要事務沒有提交的話，那麼其他事務是不可見的，這個級別也叫作不...