1. 程式人生 > >資料庫基礎、原理、優化操作及方案

資料庫基礎、原理、優化操作及方案

  資料庫檔案讀寫就要考慮到效率問題!在資料庫中提高效率用到什麼,是事務!如果一條條插入,其實每次插入都會維持一個事務,也就相當於檔案的開啟和關閉,10000次的開啟和關閉是很消耗效能的,所以要在插入前使用BEGIN TRANSACTION開啟事務,再10000條資料插入完成時用END TRANSACTION結束事務,這樣就相對於檔案只打開了一次,10000條批量操作完後,再關閉檔案!”

MySQL資料量大時,優化可以進行的操作:MySQL分庫分表,MySQL快取,MySQL索引,MySQL優化查詢語句? 其他資料庫也類似,只是有些資料庫的特性不一樣。

> SQL基礎及提高:
常用SQL語句大全總結- http://blog.csdn.net/wanghong5211/article/details/68687004

SQL語句的CRUD-- http://www.cnblogs.com/cunkouzh/p/5588319.html
資料庫- http://blog.csdn.net/x359981514/article/category/1269503
Android Cursor用法 - http://blog.csdn.net/baohanqing/article/details/19244911

SQL 基本知識- http://www.cnblogs.com/doubleyong/p/4312843.html
SQL關鍵字總結- http://www.cnblogs.com/ProgrammerGE/archive/2010/10/29/1864769.html
Sql語句常用關鍵字- http://blog.csdn.net/kenkao/article/details/4688336

SQL的多表操作- http://www.cnblogs.com/showonce/p/5947768.html
15 個常用的 SQL Server 高階語法- http://www.codeceo.com/article/15-sql-server-grammer.html

> 資料庫事務四大特性(ACID):原子性(Atomicity);一致性(Consistency);分離性(Isolation);永續性(Durability);

理解事務——原子性、一致性、隔離性和永續性- https://blog.csdn.net/chosen0ne/article/details/10036775

 保證事務的原子性是分散式事物的最大難點,在分散式環境下,保證事務原子性主要有兩種方案,一種是在提交命令發出後不回滾,儘可能保證提交成功;另一種是在提交命令發出後,根據響應結果判斷是提交成功還是該進行回滾。
  事務的一致性
在單機資料庫事務中,事務的一致性是指事務的任何操作都不會使得資料違反資料庫定義的約束、觸發器等規則。在分散式資料庫中,由於資料分佈在不同節點,有些約束難以保證,比如主鍵和唯一性約束,中信銀行當前實現的版本未從資料庫本身保證該約束的完整性,只能從使用規範角度進行約束,由應用保證主鍵和唯一索引的全域性唯一性。
  事務的隔離性
事務隔離性的本質就是如何正確處理讀寫衝突和寫寫衝突,這在分散式事務中又是一個難點,因為在我們的分散式事務控制方案中,可能會出現提交不同步的現象,這個時候就有可能出現“部分已經提交”的事務。一旦併發應用訪問“已經提交”節點中的資料,就需要根據GTID的狀態來判斷是“部分提交”還是“全部提交”,否則就出現了分散式資料庫中特有的一種“髒讀”。因此GTID方案可以確保分散式事務的隔離性。
  事務的永續性

和單機一樣,分散式事務也需要保證事務的永續性,通過單節點資料的持久化和全域性事務狀態的持久化來完成,資料的持久化由單節點資料庫保證,全域性事務狀態的持久化由全域性事務管理器負責,全域性事務管理器採用定時全量和實時增量方式實現事務狀態的持久化:將GTID申請和釋放的動作實時寫到磁碟,同時每隔一定時間將全域性事務管理中的活躍GTID列表以非同步方式寫到磁碟,通過定時的全量活躍GTID列表和實時的增量記錄,可以獲得任意時刻的活躍GTID列表。


  1.資料庫觸發器:CREATE TRIGGER trig_stu_update ON student FOR UPDATE AS begin end; CREATE TRIGGER trig_stu_delete ON student FOR DELETE AS begin end;
  2.資料庫複合索引(聚集、非聚集索引、唯一索引、複合索引、系統自建索引):建立複合索引應當包含少數幾個列,並且這些列經常在select查詢裡使用。
聚集、非聚集索引、唯一索引、複合索引、系統自建索引- http://sunct.iteye.com/blog/1933511
 單一索引是指索引列為一列的情況,即新建索引的語句只實施在一列上。 使用者可以在多個列上建立索引,這種索引叫做複合索引(組合索引)。
 同時有兩個概念叫做窄索引和寬索引,窄索引是指索引列為1-2列的索引,如果不特殊說明的話一般是指單一索引。寬索引也就是索引列超過2列的索引。 
設計索引的一個重要原則就是能用窄索引不用寬索引,因為窄索引往往比組合索引更有效。擁有更多的窄索引,將給優化程式提供更多的選擇餘地,這通常有助於提高效能。
  3.資料庫的資料來源元件:
資料來源控制元件包括那些所有實現 IDataSource 介面的控制元件。.NET Framework 包含以下資料來源控制元件:
 SqlDataSource:連線到任意 ADO.NET 資料提供程式的資料來源。
 ObjectDataSource:連線到自定義的資料訪問類。(這是大型專業 Web 應用程式傾向使用的資料來源控制元件)
 AccessDataSource:連線到 Access 資料庫檔案。用於小型網站,更好的小範圍資料解決方案是使用免費的 SQL Server Express。
 XmlDataSource:連線到 XML 檔案。
 SiteMapDataSource:連線到描述站點導航資訊的 web.sitemap 檔案。

> 資料庫優化方案:快取;資料庫表的大欄位剝離;恰當的使用索引;表庫的拆分;欄位冗餘;從磁碟上做文章;放棄關係資料庫的某些特性等;

主機效能;記憶體使用效能;網路傳輸效能;SQL語句執行效能。

資料庫優化方案- http://database.51cto.com/art/201407/445934.htm

資料庫水平切分的實現原理解析-分庫,分表,主從,叢集,負載均衡器- http://zhengdl126.iteye.com/blog/419850

Sharding-JDBC 原始碼分析- http://www.iocoder.cn/categories/Sharding-JDBC/?csdn&201

資料庫事務有四種隔離級別:未提交讀,提交讀,可重複讀,序列讀。

資料庫設計優化。sql優化。讀寫分離,分庫分表。

> MySQL分庫分表

  MySQL資料量大時,優化可以進行的操作:MySQL分庫分表,MySQL快取,MySQL索引,MySQL優化查詢語句? 其他資料庫也類似,只是有些資料庫的特性不一樣。

例項分析MySQL下的四種事務隔離級別- https://www.ziwenxie.site/2017/08/08/mysql-transaction-isolation/

   MySQL資料量大時,優化可以進行的操作:MySQL分庫分表,MySQL快取,MySQL索引,MySQL優化查詢語句? 其他資料庫也類似,只是有些資料庫的特性不一樣。

分庫分表中介軟體彙總- http://blog.csdn.net/aisiyantou/article/details/50769942

1、Cobar(阿里,目前已不在維護)使用淘寶中介軟體cobar實現mysql分庫分表- https://github.com/alibaba/cobar     
2、TDDL(阿里淘寶,需要用到阿里另外一個專案diamond配置中心)分散式資料層
3、ATLAS(奇虎360)負載均衡、讀寫分離,不支援分庫分表
4、MyCat(以Cobar基礎,號稱中國第一開源框架

開源的分庫分表中介軟體Sharding-JDBC,dubbox和elastic-job Kratos;
分庫分表用於應對當前網際網路常見的兩個場景——大資料量和高併發。
  通常分為垂直拆分和水平拆分兩種。
  垂直拆分是根據業務將一個庫(表)拆分為多個庫(表)。如:將經常和不常訪問的欄位拆分至不同的庫或表中。由於與業務關係密切,目前的分庫分表產品均使用水平拆分方式。
  水平拆分則是根據分片演算法將一個庫(表)拆分為多個庫(表)。如:按照ID的最後一位以3取餘,尾數是1的放入第1個庫(表),尾數是2的放入第2個
庫(表)等。
  單純的分表雖然可以解決資料量過大導致檢索變慢的問題,但無法解決過多併發請求訪問同一個庫,導致資料庫響應變慢的問題。所以通常水平拆分都至少要採用分庫的方式,用於一併解決大資料量和高併發的問題。這也是部分開源的分片資料庫中介軟體只支援分庫的原因。
  但分表也有不可替代的適用場景。最常見的分表需求是事務問題。同在一個庫則不需考慮分散式事務,善於使用同庫不同表可有效避免分散式事務帶來的麻煩。目前強一致性的分散式事務由於效能問題,導致使用起來並不一定比不分庫分錶快。目前採用最終一致性的柔性事務居多。分表的另一個存在的理由是,過多的資料庫例項不利於運維管理。
  無論使用哪種架構,核心邏輯均極為相似,除了協議實現層不同(JDBC或資料庫協議),都會分為分片規則配置、SQL解析、SQL改寫、SQL路由、SQL執行以及結果歸併等模組。
  結果歸併包括4類:普通遍歷類、排序類、聚合類和分組類。

大型網站就是要同時滿足高訪問量和高資料量的要求,核心是通過分散式系統解決資料的處理、儲存及訪問問題。
訊息中介軟體Notify;淘寶服務框架——HSF;淘寶分散式資料層TDDL

> 快取,用redis/memcache做Mysql快取層?
啟用MySQL查詢快取- http://blog.csdn.net/ClementAD/article/details/46806469
MYSQL 快取詳解 [myownstars] 經典部落格- http://www.cnblogs.com/zengkefu/p/5606342.html

> MySQL索引與優化
MySQL目前主要有以下幾種索引方法:B-Tree,Hash,R-Tree。http://www.cnblogs.com/luyucheng/p/6289048.html
mysql索引結構原理、效能分析與優化- http://www.tuicool.com/articles/ZRN3qu
  在MySQL中,索引屬於儲存引擎級別的概念,不同儲存引擎對索引的實現方式是不同的,MyISAM和InnoDB兩個儲存引擎的索引實現方式。
MyISAM的索引檔案僅僅儲存資料記錄的地址。在MyISAM中,主索引和輔助索引(Secondary key)在結構上沒有任何區別,只是主索引要求key是唯一的,而輔助索引的key可以重複。
  InnoDB表資料檔案本身就是主索引。InnoDB的輔助索引data域儲存相應記錄主鍵的值而不是地址。換句話說,InnoDB的所有輔助索引都引用主鍵作為data域。輔助索引搜尋需要檢索兩遍索引:首先檢索輔助索引獲得主鍵,然後用主鍵到主索引中檢索獲得記錄。

任何資料庫層面的優化都抵不上應用系統的優化.B+tree是B-tree的一個變種,大名鼎鼎的MySQL就普遍使用B+tree實現其索引結構。
MySQL索引原理及慢查詢優化- http://blog.jobbole.com/86594/
mysql索引總結----mysql 索引型別以及建立- http://blog.csdn.net/xluren/article/details/32746183
理解MySQL——索引與優化- http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html


> 查詢語句優化

善用Explain語句
Mysql常用30種SQL查詢語句優化方法- http://blog.csdn.net/youthsunshine/article/details/53465847

根據資料庫主鍵的欄位型別,咱們可以將主鍵分為兩類,分別為:
業務主鍵,即使用真實的業務資料作為主鍵,例如學號、課程編號等等,很少使用;
邏輯主鍵,即使用邏輯性的欄位作為主鍵,欄位沒有業務含含義,值是沒有都沒有關係,經常使用。

MySQL資料量大時,優化可以進行的操作:MySQL分庫分表,MySQL快取,MySQL索引,MySQL優化查詢語句? 其他資料庫也類似,只是有些資料庫的特性不一樣。