邏輯圖三層 第一層:客戶端和服務器 第二層：查詢解析，分析，優化，緩存以及所有內置函數，所有夸存儲引擎的功能都在這一層實現:存儲過程和觸發器 第三層：存儲引擎 每個客戶端連接在服務器都有一個線程 MySQL5.5提供線程池， 可以使用池中少量的線程服務大量的連接 存儲引擎對于優化查詢有影響 事務日記 在提交前保存在日記中 MySQL鎖 表鎖， 行級鎖， 共享鎖， 排它鎖，| |||| 悲觀鎖， 樂觀鎖 間隙鎖 MVCC(MySQL的多版本并發控制): https://blog.csdn.net/XxieYyuHhui/article/details/78521997 InnoDB和XtraDB存儲引擎通過多版本并發控制解決幻讀的問題 MVCC策略支持高并發， 并通過間隙鎖防止幻讀 保存二個額外的版本號，使大多數讀操作都可以不用加鎖。（需要額外的存儲空間） 在同一事務中使用多種存儲引擎是不可靠的（非事務型的表不會回滾） InnoDB 聚簇索引 MyIsAM 不支持事務和行級鎖 ， (讀多寫少，表在創建并導入數據后不再修改，可以使用壓縮表, 減少空間占用和IO開銷) （不需要事務， 只需要select 和 insert） 死循環沒有調度點，被餓死，見上面的討論 goroutin里不能panic 因為協程里面發生panic會讓整個進程crash 聚簇索引的優化 mvcc為用戶提供快照讀， 一致非鎖定讀，也可以稱為快照讀，其實就是普通的讀取即普通SELECT語句 三大范式：不要冗余字段， 一對多的關系分表放， 屬性都跟主鍵有直接關系而不是間接關系 事務的四大特征 原子性(atomicity) : 整個事務中的所有操作視為一個整體, 要么全部成功, 要么全部失敗回滾 一致性(consistency): 在沒有提交前, 部分執行成功的語句不會影響外部 隔離性(isolation): 一個事務所做的修改在提交前, 對其它事務是不可見的 持久性(durability):事務提交后, 所做的修改會永久保存到數據庫中