本文目錄一覽：
MYSQL使用基礎、進階分享
MySQL是一個關係型數據庫管理系統，由瑞典MySQL AB公司開發，屬於Oracle旗下產品，是最流行的關係型數據庫管理系統之一。
端口是3306。
表很多時，使用linux腳本，需要根據需要修改一下：
和創建一樣，可以加上 if exists
可兩篇文章：
如：
用於在已有的表中添加、刪除或修改列。
添加 ADD
或
默認是添加到最後，但可以指定位置。 FIRST ：添加最前
AFTER 字段名 ：添加指定字段之後
例子：
刪除 DROP
修改 MODIFY 主要修改原列的類型或約束條件 同樣可以用 FIRST 和 AFTER 字段名 ，代表的是修改到哪裡。
修改字段名 CHANGE
可以把表2的數據複製到表1中，但 不能複製約束性條件 。
單行
多行，注意 只有一個VALUES ：
不寫 (行1, 行2…) 這一部分的話，默認一一對應
除了以上方法外，還可以用SET為每一行附上相應的值。
假如沒有篩選的話，就給全部都修改了。可以用 WHERE 篩選。
假如 沒有篩選的話，就給全部刪除了 。相當於清空。
清空
先把表刪除，然後再建一個。與 DELETE FROM 相比， TRUNCATE 的效率更快，因為 DELETE FROM 是把記錄逐條刪除的。
查詢執行的順序
FROM — WHERE — SELECT — GROUP BY — HAVING — ORDER BY — LIMIT
注意
當數據很大，上百萬的時候，使用LIMIT … OFFSET ..的方式進行分頁十分浪費資源且耗時長。最好是結合WHERE使用，如：
REGEXP 使用正則表達進行匹配。 查詢時，需要搭配WHERE或HAVING使用 。
兩個表之間有交集且要用到兩個表的數據時，可以使用內連接查詢。
LEFT JOIN 關鍵字從左表（table1）返回所有的行，即使右表（table2）中沒有匹配。如果右表中沒有匹配，則結果為 NULL。
用法：
RIGHT JOIN 關鍵字從右表（table2）返回所有的行，即使左表（table1）中沒有匹配。如果左表中沒有匹配，則結果為 NULL。 把LEFT JOIN的表1、表2調換順序，就是REGHT JOIN 。
FULL OUTER JOIN 關鍵字只要左表（table1）和右表（table2）其中一個表中存在匹配，則返回行. 相當於結合了 LEFT JOIN 和 RIGHT JOIN 的結果。
但 MySQL中不支持 FULL OUTER JOIN 。
即SELECT嵌套。
IN 一個查詢結果作為另一個查詢的條件。 如：
EXISTS 用於判斷查詢子句是否有記錄，如果有一條或多條記錄存在返回 True，否則返回 False。True時執行。 如：
索引的本質是一種排好序的數據結構。利用索引可以提高查詢速度。
常見的索引有：
MySQL通過外鍵約束來保證表與表之間的數據的完整性和準確性。 外鍵的使用條件：
外鍵的好處：可以使得兩張表關聯，保證數據的一致性和實現一些級聯操作。
對已有的兩個表增加外鍵 比如：主表為A，子表為B，外鍵為aid，外鍵約束名字為a_fk_b
為子表添加一個字段，當做外鍵
為子表添加外鍵約束條件
假如刪除記錄報錯： [Err] 1451 -Cannot deleteorupdatea parent row: aforeignkeyconstraintfails (…)
這是因為MySQL中設置了foreign key關聯，造成無法更新或刪除數據。可以通過設置 FOREIGN_KEY_CHECKS 變量來避免這種情況。 第一步：禁用外鍵約束，我們可以使用： SETFOREIGN_KEY_CHECKS=0; 第二步：刪除數據 第三步：啟動外鍵約束，我們可以使用： SETFOREIGN_KEY_CHECKS=1; 查看當前FOREIGN_KEY_CHECKS的值，可用如下命令： SELECT @@FOREIGN_KEY_CHECKS;
使用 UNION 來組合兩個查詢，如果第一個查詢返回 M 行，第二個查詢返回 N 行，那麼組合查詢的結果一般為 M+N 行。
每個查詢必須包含相同的列、表達式和聚集函數。
默認會去除相同行，如果需要 保留 相同行，使用 UNION ALL 。
只能包含一個 ORDER BY 子句，並且必須位於語句的最後 。
內置函數很多, 見: MySQL 函數
我們一般使用 START TRANSACTION 或 BEGIN 開啟事務, COMMIT 提交事務中的命令, SAVEPOINT : 相當於設置一個還原點, ROLLBACK TO : 回滾到某個還原點下
一般的使用格式如下:
開啟事務時, 默認加鎖
根據類型可分為共享鎖（SHARED LOCK）和排他鎖（EXCLUSIVE LOCK）或者叫讀鎖（READ LOCK）和寫鎖（WRITE LOCK）。
根據粒度劃分又分表鎖和行鎖。表鎖由數據庫服務器實現，行鎖由存儲引擎實現。
除此之外,我們可以顯示加鎖
加鎖時, 如果沒有索引，會鎖表，如果加了索引，就會鎖行
InnoDB默認支持行鎖，獲取鎖是分步的，並不是一次性獲取所有的鎖，因此在鎖競爭的時候就會出現死鎖的情況
解決方法:
即ACID特性:
由於並發事務會引發上面這些問題, 我們可以設置事務的隔離級別解決上面的問題.
MySQL的默認隔離級別（可重複讀）
查看當前會話隔離級別
方式1
方式2
設置隔離級別
主從集群的示意圖如下:
主要涉及三個線程： binlog 線程、 I/O 線程和 SQL 線程。
同步流程:
由於MySQL主從集群只會從主節點同步到從節點, 不會反過來同步, 所以需要讀寫分離
讀寫分離需要在業務層面實現 , 寫數據只能在主節點上完成, 而讀數據可以在主節點或從節點上完成
索引是幫助MySQL高效獲取數據的排好序的數據結構
MySQL的索引有
推薦兩個在線工具:
簡單來說, B樹是在紅黑樹(一個平衡二叉樹)的基礎上將一個節點存放多個值, 實現的, 降低了樹的高度, 每個節點都存放索引及對應數據指針, 同一層的節點是遞增的
而B+樹在B樹的基礎上進行優化, 非葉子節點存放 子節點的開始的索引, 葉子節點存放索引和數據的指針, 且葉子節點之間有雙向的指針
如下示意圖:
不同的引擎, 主鍵索引存放的數據也不一樣, 比如常見的 MyISAM 和 InnoDB
MyISAM 的B+樹葉子節點存放表數據的指針, InnoDB 的B+樹葉子節點存放處主鍵外的數據
其他的:
即多個列組成一個索引, 語法:
由於聯合索引的B+樹的結構, 根據列建立, 所以我們的查找條件也要根據索引列的順序( where column1=x, column2=y,columnN… ), 否則會全表掃描
如果你對列進行了 （+，-，*，/，!） , 那麼都將不會走索引。
OR 引起的索引失效
OR 導致索引是在特定情況下的，並不是所有的 OR 都是使索引失效，如果OR連接的是 同 一個字段，那麼索引 不會失效 ， 反之索引失效 。
這個我相信大家都明白，模糊搜索如果你前綴也進行模糊搜索，那麼不會走索引。
這兩種用法，也將使索引失效。另 IN 會走索引，但是當IN的取值範圍較大時會導致索引失效，走全表掃描, 見: MySQL中使用IN會不會走索引
不走索引。
走索引。
所以設計表的時候, 建議不可為空, 而是將默認值設置為 “” ( NOT NULL DEFAULT “” )
「春招系列」MySQL面試核心25問（附答案）
篇幅所限本文只寫了MySQL25題，像其他的Redis，SSM框架，算法，計網等技術棧的面試題後面會持續更新，個人整理的1000餘道面試八股文會放在文末給大家白嫖，最近有面試需要刷題的同學可以直接翻到文末領取。
如果表使用自增主鍵，那麼每次插入新的記錄，記錄就會順序添加到當前索引節點的後續位置，當一頁寫滿，就會自動開闢一個新的頁。如果使用非自增主鍵（如果身份證號或學號等），由於每次插入主鍵的值近似於隨機，因此每次新紀錄都要被插到現有索引頁得中間某個位置， 頻繁的移動、分頁操作造成了大量的碎片，得到了不夠緊湊的索引結構，後續不得不通過OPTIMIZE TABLE（optimize table）來重建表並優化填充頁面。
Server層按順序執行sql的步驟為：
簡單概括：
可以分為服務層和存儲引擎層兩部分，其中：
服務層包括連接器、查詢緩存、分析器、優化器、執行器等 ，涵蓋MySQL的大多數核心服務功能，以及所有的內置函數（如日期、時間、數學和加密函數等），所有跨存儲引擎的功能都在這一層實現，比如存儲過程、觸發器、視圖等。
存儲引擎層負責數據的存儲和提取 。其架構模式是插件式的，支持InnoDB、MyISAM、Memory等多個存儲引擎。現在最常用的存儲引擎是InnoDB，它從MySQL 5.5.5版本開始成為了默認的存儲引擎。
Drop、Delete、Truncate都表示刪除，但是三者有一些差別：
Delete 用來刪除表的全部或者一部分數據行，執行Delete之後，用戶需要提交(commmit)或者回滾(rollback)來執行刪除或者撤銷刪除，會觸發這個表上所有的delete觸發器。
Truncate 刪除表中的所有數據，這個操作不能回滾，也不會觸發這個表上的觸發器，TRUNCATE比Delete更快，佔用的空間更小。
Drop 命令從數據庫中刪除表，所有的數據行，索引和權限也會被刪除，所有的DML觸發器也不會被觸發，這個命令也不能回滾。
因此，在不再需要一張表的時候，用Drop；在想刪除部分數據行時候，用Delete；在保留表而刪除所有數據的時候用Truncate。
隔離級別臟讀不可重複讀幻影讀 READ-UNCOMMITTED 未提交讀 READ-COMMITTED 提交讀 REPEATABLE-READ 重複讀 SERIALIZABLE 可串行化讀
MySQL InnoDB 存儲引擎的默認支持的隔離級別是 REPEATABLE-READ （可重讀）
這裡需要注意的是 ：與 SQL 標準不同的地方在於InnoDB 存儲引擎在 REPEATABLE-READ（可重讀）事務隔離級別 下使用的是 Next-Key Lock 鎖 算法，因此可以避免幻讀的產生，這與其他數據庫系統(如 SQL Server)是不同的。所以 說InnoDB 存儲引擎的默認支持的隔離級別是 REPEATABLE-READ（可重讀） 已經可以完全保證事務的隔離性要 求，即達到了 SQL標準的SERIALIZABLE(可串行化)隔離級別。
因為隔離級別越低，事務請求的鎖越少，所以大部分數據庫系統的隔離級別都是READ-COMMITTED(讀取提交內 容):，但是你要知道的是InnoDB 存儲引擎默認使用 REPEATABLE-READ（可重讀）並不會有任何性能損失 。
InnoDB 存儲引擎在分布式事務 的情況下一般會用到SERIALIZABLE(可串行化)隔離級別。
主要原因：B+樹只要遍歷葉子節點就可以實現整棵樹的遍歷，而且在數據庫中基於範圍的查詢是非常頻繁的，而B樹只能中序遍歷所有節點，效率太低。
文件與數據庫都是需要較大的存儲，也就是說，它們都不可能全部存儲在內存中，故需要存儲到磁盤上。而所謂索引，則為了數據的快速定位與查找，那麼索引的結構組織要盡量減少查找過程中磁盤I/O的存取次數，因此B+樹相比B樹更為合適。數據庫系統巧妙利用了局部性原理與磁盤預讀原理，將一個節點的大小設為等於一個頁，這樣每個節點只需要一次I/O就可以完全載入，而紅黑樹這種結構，高度明顯要深的多，並且由於邏輯上很近的節點(父子)物理上可能很遠，無法利用局部性。
最重要的是，B+樹還有一個最大的好處：方便掃庫。
B樹必須用中序遍歷的方法按序掃庫，而B+樹直接從葉子結點挨個掃一遍就完了，B+樹支持range-query非常方便，而B樹不支持，這是數據庫選用B+樹的最主要原因。
B+樹查找效率更加穩定，B樹有可能在中間節點找到數據，穩定性不夠。
B+tree的磁盤讀寫代價更低：B+tree的內部結點並沒有指向關鍵字具體信息的指針(紅色部分)，因此其內部結點相對B 樹更小。如果把所有同一內部結點的關鍵字存放在同一塊盤中，那麼盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的需要查找的關鍵字也就越多，相對來說IO讀寫次數也就降低了；
B+tree的查詢效率更加穩定：由於內部結點並不是最終指向文件內容的結點，而只是葉子結點中關鍵字的索引，所以，任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當；
視圖是一種虛擬的表，通常是有一個表或者多個表的行或列的子集，具有和物理表相同的功能 游標是對查詢出來的結果集作為一個單元來有效的處理。一般不使用游標，但是需要逐條處理數據的時候，游標顯得十分重要。
而在 MySQL 中，恢復機制是通過回滾日誌（undo log）實現的，所有事務進行的修改都會先記錄到這個回滾日誌中，然後在對數據庫中的對應行進行寫入。當事務已經被提交之後，就無法再次回滾了。
回滾日誌作用：1)能夠在發生錯誤或者用戶執行 ROLLBACK 時提供回滾相關的信息 2) 在整個系統發生崩潰、數據庫進程直接被殺死後，當用戶再次啟動數據庫進程時，還能夠立刻通過查詢回滾日誌將之前未完成的事務進行回滾，這也就需要回滾日誌必須先於數據持久化到磁盤上，是我們需要先寫日誌後寫數據庫的主要原因。
InnoDB
MyISAM
總結
數據庫並發會帶來臟讀、幻讀、丟棄更改、不可重複讀這四個常見問題，其中：
臟讀 ：在第一個修改事務和讀取事務進行的時候，讀取事務讀到的數據為100，這是修改之後的數據，但是之後該事務滿足一致性等特性而做了回滾操作，那麼讀取事務得到的結果就是臟數據了。
幻讀 ：一般是T1在某個範圍內進行修改操作（增加或者刪除），而T2讀取該範圍導致讀到的數據是修改之間的了，強調範圍。
丟棄修改 ：兩個寫事務T1 T2同時對A=0進行遞增操作，結果T2覆蓋T1，導致最終結果是1 而不是2，事務被覆蓋
不可重複讀 ：T2 讀取一個數據，然後T1 對該數據做了修改。如果 T2 再次讀取這個數據，此時讀取的結果和第一次讀取的結果不同。
第一個事務首先讀取var變量為50，接着準備更新為100的時，並未提交，第二個事務已經讀取var為100，此時第一個事務做了回滾。最終第二個事務讀取的var和數據庫的var不一樣。
T1 讀取某個範圍的數據，T2 在這個範圍內插入新的數據，T1 再次讀取這個範圍的數據，此時讀取的結果和和第一次讀取的結果不同。
T1 和 T2 兩個事務都對一個數據進行修改，T1 先修改，T2 隨後修改，T2 的修改覆蓋了 T1 的修改。例如：事務1讀取某表中的數據A=50，事務2也讀取A=50，事務1修改A=A+50，事務2也修改A=A+50，最終結果A=100，事務1的修改被丟失。
T2 讀取一個數據，T1 對該數據做了修改。如果 T2 再次讀取這個數據，此時讀取的結果和第一次讀取的結果不同。
悲觀鎖，先獲取鎖，再進行業務操作，一般就是利用類似 SELECT … FOR UPDATE 這樣的語句，對數據加鎖，避免其他事務意外修改數據。當數據庫執行SELECT … FOR UPDATE時會獲取被select中的數據行的行鎖，select for update獲取的行鎖會在當前事務結束時自動釋放，因此必須在事務中使用。
樂觀鎖，先進行業務操作，只在最後實際更新數據時進行檢查數據是否被更新過。Java 並發包中的 AtomicFieldUpdater 類似，也是利用 CAS 機制，並不會對數據加鎖，而是通過對比數據的時間戳或者版本號，來實現樂觀鎖需要的版本判斷。
分庫與分表的目的在於，減小數據庫的單庫單表負擔，提高查詢性能，縮短查詢時間。
通過分表 ，可以減少數據庫的單表負擔，將壓力分散到不同的表上，同時因為不同的表上的數據量少了，起到提高查詢性能，縮短查詢時間的作用，此外，可以很大的緩解表鎖的問題。分表策略可以歸納為垂直拆分和水平拆分:
水平分表 ：取模分表就屬於隨機分表，而時間維度分表則屬於連續分表。如何設計好垂直拆分，我的建議：將不常用的字段單獨拆分到另外一張擴展表. 將大文本的字段單獨拆分到另外一張擴展表, 將不經常修改的字段放在同一張表中，將經常改變的字段放在另一張表中。對於海量用戶場景，可以考慮取模分表，數據相對比較均勻，不容易出現熱點和並發訪問的瓶頸。
庫內分表 ，僅僅是解決了單表數據過大的問題，但並沒有把單表的數據分散到不同的物理機上，因此並不能減輕 MySQL 服務器的壓力，仍然存在同一個物理機上的資源競爭和瓶頸，包括 CPU、內存、磁盤 IO、網絡帶寬等。
分庫與分錶帶來的分布式困境與應對之策 數據遷移與擴容問題—-一般做法是通過程序先讀出數據，然後按照指定的分表策略再將數據寫入到各個分表中。分頁與排序問題—-需要在不同的分表中將數據進行排序並返回，並將不同分表返回的結果集進行匯總和再次排序，最後再返回給用戶。
不可重複讀的重點是修改，幻讀的重點在於新增或者刪除。
視圖是虛擬的表，與包含數據的表不一樣，視圖只包含使用時動態檢索數據的查詢；不包含任何列或數據。使用視圖可以簡化複雜的 sql 操作，隱藏具體的細節，保護數據；視圖創建後，可以使用與表相同的方式利用它們。
視圖不能被索引，也不能有關聯的觸發器或默認值，如果視圖本身內有order by 則對視圖再次order by將被覆蓋。
創建視圖：create view xxx as xxxx
對於某些視圖比如未使用聯結子查詢分組聚集函數Distinct Union等，是可以對其更新的，對視圖的更新將對基表進行更新；但是視圖主要用於簡化檢索，保護數據，並不用於更新，而且大部分視圖都不可以更新。
B+tree的磁盤讀寫代價更低，B+tree的查詢效率更加穩定 數據庫索引採用B+樹而不是B樹的主要原因：B+樹只要遍歷葉子節點就可以實現整棵樹的遍歷，而且在數據庫中基於範圍的查詢是非常頻繁的，而B樹只能中序遍歷所有節點，效率太低。
B+樹的特點
在最頻繁使用的、用以縮小查詢範圍的字段,需要排序的字段上建立索引。不宜：1）對於查詢中很少涉及的列或者重複值比較多的列 2）對於一些特殊的數據類型，不宜建立索引，比如文本字段（text）等。
如果一個索引包含（或者說覆蓋）所有需要查詢的字段的值，我們就稱 之為“覆蓋索引”。
我們知道在InnoDB存儲引 擎中，如果不是主鍵索引，葉子節點存儲的是主鍵+列值。最終還是要“回表”，也就是要通過主鍵再查找一次,這樣就 會比較慢。覆蓋索引就是把要查詢出的列和索引是對應的，不做回表操作！
舉例 ：
學號姓名性別年齡系別專業 20020612李輝男20計算機軟件開發 20060613張明男18計算機軟件開發 20060614王小玉女19物理力學 20060615李淑華女17生物動物學 20060616趙靜男21化學食品化學 20060617趙靜女20生物植物學
主鍵為候選鍵的子集，候選鍵為超鍵的子集，而外鍵的確定是相對於主鍵的。
超詳細MySQL數據庫優化
數據庫優化一方面是找出系統的瓶頸,提高MySQL數據庫的整體性能,而另一方面需要合理的結構設計和參數調整,以提高用戶的相應速度,同時還要儘可能的節約系統資源,以便讓系統提供更大的負荷.
1. 優化一覽圖
2. 優化
筆者將優化分為了兩大類,軟優化和硬優化,軟優化一般是操作數據庫即可,而硬優化則是操作服務器硬件及參數設置.
2.1 軟優化
2.1.1 查詢語句優化
1.首先我們可以用EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執行信息.
2.例:
顯示:
其中會顯示索引和查詢數據讀取數據條數等信息.
2.1.2 優化子查詢
在MySQL中,盡量使用JOIN來代替子查詢.因為子查詢需要嵌套查詢,嵌套查詢時會建立一張臨時表,臨時表的建立和刪除都會有較大的系統開銷,而連接查詢不會創建臨時表,因此效率比嵌套子查詢高.
2.1.3 使用索引
索引是提高數據庫查詢速度最重要的方法之一,關於索引可以參高筆者MySQL數據庫索引一文,介紹比較詳細,此處記錄使用索引的三大注意事項:
2.1.4 分解表
對於字段較多的表,如果某些字段使用頻率較低,此時應當,將其分離出來從而形成新的表,
2.1.5 中間表
對於將大量連接查詢的表可以創建中間表,從而減少在查詢時造成的連接耗時.
2.1.6 增加冗餘字段
類似於創建中間表,增加冗餘也是為了減少連接查詢.
2.1.7 分析表,,檢查表,優化表
分析表主要是分析表中關鍵字的分布,檢查表主要是檢查表中是否存在錯誤,優化表主要是消除刪除或更新造成的表空間浪費.
1. 分析表: 使用 ANALYZE 關鍵字,如ANALYZE TABLE user;
2. 檢查表: 使用 CHECK關鍵字,如CHECK TABLE user [option]
option 只對MyISAM有效,共五個參數值:
3. 優化表:使用OPTIMIZE關鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不寫入日誌.,優化表只對VARCHAR,BLOB和TEXT有效,通過OPTIMIZE TABLE語句可以消除文件碎片,在執行過程中會加上只讀鎖.
2.2 硬優化
2.2.1 硬件三件套
1.配置多核心和頻率高的cpu,多核心可以執行多個線程.
2.配置大內存,提高內存,即可提高緩存區容量,因此能減少磁盤I/O時間,從而提高響應速度.
3.配置高速磁盤或合理分布磁盤:高速磁盤提高I/O,分布磁盤能提高並行操作的能力.
2.2.2 優化數據庫參數
優化數據庫參數可以提高資源利用率,從而提高MySQL服務器性能.MySQL服務的配置參數都在my.cnf或my.ini,下面列出性能影響較大的幾個參數.
2.2.3 分庫分表
因為數據庫壓力過大，首先一個問題就是高峰期系統性能可能會降低，因為數據庫負載過高對性能會有影響。另外一個，壓力過大把你的數據庫給搞掛了怎麼辦？所以此時你必須得對系統做分庫分表 + 讀寫分離，也就是把一個庫拆分為多個庫，部署在多個數據庫服務上，這時作為主庫承載寫入請求。然後每個主庫都掛載至少一個從庫，由從庫來承載讀請求。
2.2.4 緩存集群
如果用戶量越來越大，此時你可以不停的加機器，比如說系統層面不停加機器，就可以承載更高的並發請求。然後數據庫層面如果寫入並發越來越高，就擴容加數據庫服務器，通過分庫分表是可以支持擴容機器的，如果數據庫層面的讀並發越來越高，就擴容加更多的從庫。但是這裡有一個很大的問題：數據庫其實本身不是用來承載高並發請求的，所以通常來說，數據庫單機每秒承載的並發就在幾千的數量級，而且數據庫使用的機器都是比較高配置，比較昂貴的機器，成本很高。如果你就是簡單的不停的加機器，其實是不對的。所以在高並發架構里通常都有緩存這個環節，緩存系統的設計就是為了承載高並發而生。所以單機承載的並發量都在每秒幾萬，甚至每秒數十萬，對高並發的承載能力比數據庫系統要高出一到兩個數量級。所以你完全可以根據系統的業務特性，對那種寫少讀多的請求，引入緩存集群。具體來說，就是在寫數據庫的時候同時寫一份數據到緩存集群里，然後用緩存集群來承載大部分的讀請求。這樣的話，通過緩存集群，就可以用更少的機器資源承載更高的並發。
一個完整而複雜的高並發系統架構中，一定會包含：各種複雜的自研基礎架構系統。各種精妙的架構設計.因此一篇小文頂多具有拋磚引玉的效果,但是數據庫優化的思想差不多就這些了.
北大青鳥java培訓：mysql數據庫的優化方法？
我們都知道，服務器數據庫的開發一般都是通過java或者是PHP語言來編程實現的，而為了提高我們數據庫的運行速度和效率，數據庫優化也成為了我們每日的工作重點，今天，福建IT培訓就一起來了解一下mysql服務器數據庫的優化方法。
為什麼要了解索引真實案例案例一：大學有段時間學習爬蟲，爬取了知乎300w用戶答題數據，存儲到mysql數據中。
那時不了解索引，一條簡單的“根據用戶名搜索全部回答的sql“需要執行半分鐘左右，完全滿足不了正常的使用。
案例二：近線上應用的數據庫頻頻出現多條慢sql風險提示，而工作以來，對數據庫優化方面所知甚少。
例如一個用戶數據頁面需要執行很多次數據庫查詢，性能很慢，通過增加超時時間勉強可以訪問，但是性能上需要優化。
索引的優點合適的索引，可以大大減小mysql服務器掃描的數據量，避免內存排序和臨時表，提高應用程序的查詢性能。
索引的類型mysql數據中有多種索引類型，primarykey，unique，normal，但底層存儲的數據結構都是BTREE;有些存儲引擎還提供hash索引，全文索引。
BTREE是常見的優化要面對的索引結構，都是基於BTREE的討論。
B-TREE查詢數據簡單暴力的方式是遍歷所有記錄;如果數據不重複，就可以通過組織成一顆排序二叉樹，通過二分查找算法來查詢，大大提高查詢性能。
而BTREE是一種更強大的排序樹，支持多個分支，高度更低，數據的插入、刪除、更新更快。
現代數據庫的索引文件和文件系統的文件塊都被組織成BTREE。
btree的每個節點都包含有key，data和只想子節點指針。
btree有度的概念d=1。
假設btree的度為d，則每個內部節點可以有n=[d+1，2d+1)個key，n+1個子節點指針。
樹的大高度為h=Logb[(N+1)/2]。
索引和文件系統中，B-TREE的節點常設計成接近一個內存頁大小(也是磁盤扇區大小)，且樹的度非常大。
這樣磁盤I/O的次數，就等於樹的高度h。
假設b=100，一百萬個節點的樹，h將只有3層。
即，只有3次磁盤I/O就可以查找完畢，性能非常高。
索引查詢建立索引後，合適的查詢語句才能大發揮索引的優勢。
另外，由於查詢優化器可以解析客戶端的sql語句，會調整sql的查詢語句的條件順序去匹配合適的索引。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/248471.html
微信掃一掃 
支付寶掃一掃 