架構師訓練營 week9 總結
9.1 数据库的基本原理
為什麼 PrepareStatement
預先提交帶佔位符的 SQL 到資料庫做預處理,提前生成執行計畫。真正執行時,引擎可以直接處理,效率更好
防止 SQL injection
聚簇索引与非聚簇索引
Ref:
https://cloud.tencent.com/developer/article/1541265
https://juejin.cn/post/6844903845554814983
聚簇索引:將數據存儲與索引放到了一塊,找到索引也就找到了數據
非聚簇索引:將數據存儲於索引分開結構,索引結構的葉子節點指向了數據的對應行,myisam通過key_buffer把索引先緩存到內存中,當需要訪問數據時(通過索引訪問數據),在內存中直接搜索索引,然後通過索引找到磁盤相應數據,這也就是為什麼索引不在key buffer命中時,速度慢的原因
聚簇索引的優勢
同一頁中會有多條行數據,訪問同一數據頁不同行記錄時,已經把頁加載到了Buffer中,再次訪問的時候,會在內存中完成訪問,不必訪問硬碟。這樣主鍵和行數據是一起被載入內存的,找到葉子節點就可以立刻將行數據返回了,如果按照主鍵Id來組織數據,獲得數據更快。
減少了當出現行移動或者數據頁分裂時輔助索引的維護工作,使用主鍵值當作指針會讓輔助索引佔用更多的空間,換來的好處是InnoDB在移動行時無須更新輔助索引中的這個"指針"
適合用在排序的場合
適合於用取出一定範圍數據的時候
可以把相關數據保存在一起。例如實現電子郵箱時,可以根據用戶 ID 來聚集數據,這樣只需要從磁盤讀取少數的數據頁就能獲取某個用戶的全部郵件。如果沒有使用聚簇索引,則每封郵件都可能導致一次磁盤 I/O。
聚簇索引的劣勢
維護索引很昂貴,特別是插入新行或者主鍵被更新導至要分頁(page split)的時候。
插入速度嚴重依賴於插入順序
更新主鍵的代價很高,因為將會導致被更新的行移動
二級索引訪問需要兩次索引查找,第一次找到主鍵值,第二次根據主鍵值找到行數據
採用聚簇索引插入新值比採用非聚簇索引插入新值的速度要慢很多
為什麼主鍵通常建議使用自增id
聚簇索引的數據的物理存放順序與索引順序是一致的,即:只要索引是相鄰的,那麼對應的數據一定也是相鄰地存放在磁盤上的。如果主鍵不是自增id,那麼可以想 象,它會幹些什麼,不斷地調整數據的物理地址、分頁,當然也有其他一些措施來減少這些操作,但卻無法徹底避免。但,如果是自增的,那就簡單了,它只需要一 頁一頁地寫,索引結構相對緊湊,磁盤碎片少,效率也高。
合理使用索引
不盲目加索引
刪除不用的索引
使用更小的 type 創建索引 (int < bigint, timestamp < datetime)
ACID
Atomicity
Transactions are often composed of multiple statements. Atomicity guarantees that each transaction is treated as a single "unit", which either succeeds completely, or fails completely
Consistency
Consistency ensures that a transaction can only bring the database from one valid state to another
Isolation
Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially.
Durability
Durability guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure
隔离级别
READ UNCOMMITTED(未提交读)
READ COMMITTED(提交读)
REPEATABLE READ(可重复读)
SERIALIZABLE(可串行化)
Ref https://www.cnblogs.com/xuanzhi201111/p/4103696.html
9.2 Java related
計算機領域的任何問題都可以透過中間層(虛擬層)來解決
Process vs Thread (ref: http://www.ruanyifeng.com/blog/2013/04/processes_and_threads.html, https://www.zhihu.com/question/25532384)
9.5 系统性能优化案例
高併發的風險
Network bandwidth
Server loading spike,
Database down
挑戰
Instantly high concurrency
秒殺器
活動開始前,不斷刷新頁面
秒殺系統:服務器和網路準備
架構目標
圖片網路帶寬
網站併發
設計原則
靜態化
併發控制,防秒殺器
簡化流程
前端優化
评论