1. MySql的存儲引擎的不同
存儲引擎查看
MySQL給開發者提供了查詢存儲引擎的功能,我這裏使用的是MySQL5.1,可以使用:
SHOW ENGINES
如果要想查看數據庫默認使用哪個引擎,可以通過使用命令:
SHOW VARIABLES LIKE 'storage_engine';
來查看,查詢結果爲:
在MySQL中,不需要在整個服務器中使用同一種存儲引擎,針對具體的要求,可以對每一個表使用不同的存儲引擎。Support列的值表示某種引擎是否能使用:YES表示可以使用、NO表示不能使用、DEFAULT表示該引擎爲當前默認的存儲引擎 。
InnoDB存儲引擎
InnoDB是事務型數據庫的首選引擎,支持事務安全表(ACID),支持行鎖定和外鍵,上圖也看到了,InnoDB是默認的MySQL引擎。InnoDB主要特性有:
1、InnoDB給MySQL提供了具有提交、回滾和崩潰恢復能力的事物安全(ACID兼容)存儲引擎。InnoDB鎖定在行級並且也在SELECT語句中提供一個類似Oracle的非鎖定讀。這些功能增加了多用戶部署和性能。在SQL查詢中,可以自由地將InnoDB類型的表和其他MySQL的表類型混合起來,甚至在同一個查詢中也可以混合
2、InnoDB是爲處理巨大數據量的最大性能設計。它的CPU效率可能是任何其他基於磁盤的關係型數據庫引擎鎖不能匹敵的
3、InnoDB存儲引擎完全與MySQL服務器整合,InnoDB存儲引擎爲在主內存中緩存數據和索引而維持它自己的緩衝池。InnoDB將它的表和索引在一個邏輯表空間中,表空間可以包含數個文件(或原始磁盤文件)。這與MyISAM表不同,比如在MyISAM表中每個表被存放在分離的文件中。InnoDB表可以是任何尺寸,即使在文件尺寸被限制爲2GB的操作系統上
4、InnoDB支持外鍵完整性約束,存儲表中的數據時,每張表的存儲都按主鍵順序存放,如果沒有顯示在表定義時指定主鍵,InnoDB會爲每一行生成一個6字節的ROWID,並以此作爲主鍵
5、InnoDB被用在衆多需要高性能的大型數據庫站點上
InnoDB不創建目錄,使用InnoDB時,MySQL將在MySQL數據目錄下創建一個名爲ibdata1的10MB大小的自動擴展數據文件,以及兩個名爲ib_logfile0和ib_logfile1的5MB大小的日誌文件
MyISAM存儲引擎
MyISAM基於ISAM存儲引擎,並對其進行擴展。它是在Web、數據倉儲和其他應用環境下最常使用的存儲引擎之一。MyISAM擁有較高的插入、查詢速度,但不支持事物。MyISAM主要特性有:
1、大文件(達到63位文件長度)在支持大文件的文件系統和操作系統上被支持
2、當把刪除和更新及插入操作混合使用的時候,動態尺寸的行產生更少碎片。這要通過合併相鄰被刪除的塊,以及若下一個塊被刪除,就擴展到下一塊自動完成
3、每個MyISAM表最大索引數是64,這可以通過重新編譯來改變。每個索引最大的列數是16
4、最大的鍵長度是1000字節,這也可以通過編譯來改變,對於鍵長度超過250字節的情況,一個超過1024字節的鍵將被用上
5、BLOB和TEXT列可以被索引
6、NULL被允許在索引的列中,這個值佔每個鍵的0~1個字節
7、所有數字鍵值以高字節優先被存儲以允許一個更高的索引壓縮
8、每個MyISAM類型的表都有一個AUTO_INCREMENT的內部列,當INSERT和UPDATE操作的時候該列被更新,同時AUTO_INCREMENT列將被刷新。所以說,MyISAM類型表的AUTO_INCREMENT列更新比InnoDB類型的AUTO_INCREMENT更快
9、可以把數據文件和索引文件放在不同目錄
10、每個字符列可以有不同的字符集
11、有VARCHAR的表可以固定或動態記錄長度
12、VARCHAR和CHAR列可以多達64KB
使用MyISAM引擎創建數據庫,將產生3個文件。文件的名字以表名字開始,擴展名之處文件類型:frm文件存儲表定義、數據文件的擴展名爲.MYD(MYData)、索引文件的擴展名時.MYI(MYIndex)
MEMORY存儲引擎
MEMORY存儲引擎將表中的數據存儲到內存中,未查詢和引用其他表數據提供快速訪問。MEMORY主要特性有:
1、MEMORY表的每個表可以有多達32個索引,每個索引16列,以及500字節的最大鍵長度
2、MEMORY存儲引擎執行HASH和BTREE縮影
3、可以在一個MEMORY表中有非唯一鍵值
4、MEMORY表使用一個固定的記錄長度格式
5、MEMORY不支持BLOB或TEXT列
6、MEMORY支持AUTO_INCREMENT列和對可包含NULL值的列的索引
7、MEMORY表在所由客戶端之間共享(就像其他任何非TEMPORARY表)
8、MEMORY表內存被存儲在內存中,內存是MEMORY表和服務器在查詢處理時的空閒中,創建的內部表共享
9、當不再需要MEMORY表的內容時,要釋放被MEMORY表使用的內存,應該執行DELETE FROM或TRUNCATE TABLE,或者刪除整個表(使用DROP TABLE)
存儲引擎的選擇
不同的存儲引擎都有各自的特點,以適應不同的需求,如下表所示:
功 能 |
MYISAM |
Memory |
InnoDB |
Archive |
存儲限制 |
256TB |
RAM |
64TB |
None |
支持事物 |
No |
No |
Yes |
No |
支持全文索引 |
Yes |
No |
No |
No |
支持數索引 |
Yes |
Yes |
Yes |
No |
支持哈希索引 |
No |
Yes |
No |
No |
支持數據緩存 |
No |
N/A |
Yes |
No |
支持外鍵 |
No |
No |
Yes |
No |
如果要提供提交、回滾、崩潰恢復能力的事物安全(ACID兼容)能力,並要求實現併發控制,InnoDB是一個好的選擇
如果數據表主要用來插入和查詢記錄,則MyISAM引擎能提供較高的處理效率
如果只是臨時存放數據,數據量不大,並且不需要較高的數據安全性,可以選擇將數據保存在內存中的Memory引擎,MySQL中使用該引擎作爲臨時表,存放查詢的中間結果
如果只有INSERT和SELECT操作,可以選擇Archive,Archive支持高併發的插入操作,但是本身不是事務安全的。Archive非常適合存儲歸檔數據,如記錄日誌信息可以使用Archive
使用哪一種引擎需要靈活選擇,一個數據庫中多個表可以使用不同引擎以滿足各種性能和實際需求,使用合適的存儲引擎,將會提高整個數據庫的性能
2. 單個索引、聯合索引、主鍵索引
索引是一種特殊的文件(InnoDB數據表上的索引是表空間的一個組成部分),它們包含着對數據表裏所有記錄的引用指針。索引的遵循原則:1、最左側原則,表的最左側的一列,往往數據不會發生改變,不影響其他列的數據;2、命名短小原則,索引命名過長會使索引文件變大,損耗內存。
普通索引(由關鍵字KEY或INDEX定義得到索引):加快數據的查詢速度。
唯一索引(由關鍵字UNIQUE把它定義爲唯一索引):保證數據記錄的唯一性。
主鍵:一種特殊的唯一索引,在一張表中只能定義一個主鍵索引,用來標識唯一一條數據,用PRIMARY KEY創建。
聯合索引:索引可以覆蓋多個數據列,如像INDEX(columnA, columnB)索引,這就是聯合索引。
索引可以極大的提高查詢訪問速度,但是會降低插入,刪除,更新表的速度,因爲在執行寫操作的時候還要操作索引文件。
注意:索引是在存儲引擎中實現的,也就是說不同的存儲引擎,會使用不同的索引
MyISAM和InnoDB存儲引擎:只支持BTREE索引, 也就是說默認使用BTREE,不能夠更換
MEMORY/HEAP存儲引擎:支持HASH和BTREE索引
聯合索引使用結論:
1):查詢條件中出現聯合索引第一列,或者全部,則能利用聯合索引.
2):條件列中只要條件相連在一起,以本文例子來說就是:
last_name=’1′ and first_name=’1′與first_name=’1′ and last_name=’1′,無論前後,都會利用上聯合索引.
3):查詢條件中沒有出現聯合索引的第一列,而出現聯合索引的第二列,或者第三列,都不會利用聯合索引查詢.
單一列索引的應用結論:
1):只要條件列中出現索引列,無論在什麼位置,都能利用索引查詢.
兩者的共同點:
1):要想利用索引,都要符合SARG標準.
2) :都是爲了提高查詢速度.
3):都需要額外的系統開銷,磁盤空間.
補充說明: stmtText信息來產生,在查詢語句前面加上:SET STATISTICS PROFILE on.可以通過運行它,來觀察你的查詢是否合理,這樣才能真正做到優化.
優缺點比較:
1):索引所佔用空間:單一列索引相對要小.
2):索引創建時間:單一列索引相對短.
3):索引對insert,update,delete的影響程序:單一列索引要相對低.
4):在多條件查詢時,聯合索引效率要高.
3. Mysql怎麼分表,以及分表後如果想按條件分頁查詢怎麼辦(如果不是按分表字段來查詢的話,幾乎效率低下,無解)
例子:
select * from
(SELECT d2013.* FROM data_2013 d2013
WHERE ( d2013.point_id IN ('16') ) AND ( d2013.collected_time <= '2014-01-24+09:50' )
UNION
SELECT d2014.* FROM data_2014 d2014
WHERE ( d2014.point_id IN ('16') ) AND ( d2014.collected_time >= '2013-01-01+00:00' )
) d
INNER JOIN monitor_point p ON d.point_id = p.point_id
INNER JOIN hydro h ON h.hydro_id = p.hydro_id
INNER JOIN monitor_type t ON d.monitor_type_id = t.monitor_type_id
INNER JOIN agency a ON p.agency_id = a.id
ORDER BY d.collected_time
LIMIT 0,30
一些想法:
1.有損服務,只給他查一年內的數據,或者只存1kw條數據。建一個表存一年內的數據,每隔一個月把表最舊的數據遷到分表上面。如果需求方要查所有數據,讓他自己選年份去查。
2.先由關鍵字算出所有年份的總數total,根據前端傳來的頁面數請求(即limit,start),確定需要查詢的數據在哪一個年份,或者數據是多個年份組合出來。
假如
2012 25,2013 40,2014 15 ,共 80條
limit 0,20 =>落到2012年,那麼只需查2012就夠了;
limit 20,20 =>2012 後5條 +2013 15條 以此類推。。
如果再折騰一下,可以以關鍵字+年份爲key,把非當前年份的條數存個cache,減少計算次數
3.最後是無腦union了,應該會很慢
4.如果是針對特定的關鍵字做報表統計,一次性的那就隨意了
果斷的選了1,因爲老數據基本是沒什麼人關心的了。
4. 分表之後想讓一個id多個表是自增的,效率實現
1、mysql數據中記錄;
2、redis的incr;
3、使用隊列服務,如redis、memcached等等,將一定量的ID預分配在一個隊列裏,每次插入操作,先從隊列中獲取一個ID,若插入失敗的話,將該ID再次添加到隊列中,同時監控隊列數量,當小於閥值時,自動向隊列中添加元素。這種方式可以有規劃的對ID進行分配,還會帶來經濟效應,比如QQ號碼,各種靚號,明碼標價。如網站的userid, 允許uid登陸,推出各種靚號,明碼標價,對於普通的ID打亂後再隨機分配。
5. MySql的主從實時備份同步的配置,以及原理(從庫讀主庫的binlog),讀寫分離
一、主從數據庫的區別
從數據庫(Slave)是主數據庫的備份,當主數據庫(Master)變化時從數據庫要更新,這些數據庫軟件可以設計更新週期。這是提高信息安全的手段。主從數據庫服務器不在一個地理位置上,當發生意外時數據庫可以保存。
(1) 主從分工
其中Master負責寫操作的負載,也就是說一切寫的操作都在Master上進行,而讀的操作則分攤到Slave上進行。這樣一來的可以大大提高讀取的效率。在一般的互聯網應用中,經過一些數據調查得出結論,讀/寫的比例大概在 10:1左右 ,也就是說大量的數據操作是集中在讀的操作,這也就是爲什麼我們會有多個Slave的原因。但是爲什麼要分離讀和寫呢?熟悉DB的研發人員都知道,寫操作涉及到鎖的問題,不管是行鎖還是表鎖還是塊鎖,都是比較降低系統執行效率的事情。我們這樣的分離是把寫操作集中在一個節點上,而讀操作其其他的N個節點上進行,從另一個方面有效的提高了讀的效率,保證了系統的高可用性。
(2) 基本過程
1)、Mysql的主從同步就是當master(主庫)發生數據變化的時候,會實時同步到slave(從庫)。
2)、主從複製可以水平擴展數據庫的負載能力,容錯,高可用,數據備份。
3)、不管是delete、update、insert,還是創建函數、存儲過程,都是在master上,當master有操作的時候,slave會快速的接受到這些操作,從而做同步。
(3) 用途和條件
1)、mysql主從複製用途
●實時災備,用於故障切換
●讀寫分離,提供查詢服務
●備份,避免影響業務
2)、主從部署必要條件:
●主庫開啓binlog日誌(設置log-bin參數)
●主從server-id不同
●從庫服務器能連通主庫
二、主從同步的粒度、原理和形式:
(1)、 三種主要實現粒度
詳細的主從同步主要有三種形式:statement、row、mixed
1)、statement: 會將對數據庫操作的sql語句寫道binlog中
2)、row: 會將每一條數據的變化寫道binlog中。
3)、mixed: statement與row的混合。Mysql決定何時寫statement格式的binlog, 何時寫row格式的binlog。
(2)、主要的實現原理、具體操作、示意圖
1)、在master機器上的操作:
當master上的數據發生變化時,該事件變化會按照順序寫入bin-log中。當slave鏈接到master的時候,master機器會爲slave開啓binlog dump線程。當master的binlog發生變化的時候,bin-log dump線程會通知slave,並將相應的binlog內容發送給slave。
2)、在slave機器上操作:
當主從同步開啓的時候,slave上會創建兩個線程:I\O線程。該線程連接到master機器,master機器上的binlog dump 線程會將binlog的內容發送給該I\O線程。該I/O線程接收到binlog內容後,再將內容寫入到本地的relay log;sql線程。該線程讀取到I/O線程寫入的ralay log。並且根據relay log。並且根據relay log 的內容對slave數據庫做相應的操作。
3)、MySQL主從複製原理圖如下:
從庫生成兩個線程,一個I/O線程,一個SQL線程;
i/o線程去請求主庫 的binlog,並將得到的binlog日誌寫到relay log(中繼日誌) 文件中;
主庫會生成一個 log dump 線程,用來給從庫 i/o線程傳binlog;
SQL 線程,會讀取relay log文件中的日誌,並解析成具體操作,來實現主從的操作一致,而最終數據一致;
(2)、主從形式
mysql主從複製 靈活
● 一主一從
● 主主複製
● 一主多從---擴展系統讀取的性能,因爲讀是在從庫讀取的;
● 多主一從---5.7開始支持
● 聯級複製---
三、主從同步的延遲等問題、原因及解決方案:
(1)、mysql數據庫從庫同步的延遲問題
1)相關參數:
首先在服務器上執行show slave satus;可以看到很多同步的參數:
Master_Log_File: SLAVE中的I/O線程當前正在讀取的主服務器二進制日誌文件的名稱 Read_Master_Log_Pos: 在當前的主服務器二進制日誌中,SLAVE中的I/O線程已經讀取的位置 Relay_Log_File: SQL線程當前正在讀取和執行的中繼日誌文件的名稱 Relay_Log_Pos: 在當前的中繼日誌中,SQL線程已讀取和執行的位置 Relay_Master_Log_File: 由SQL線程執行的包含多數近期事件的主服務器二進制日誌文件的名稱 Slave_IO_Running: I/O線程是否被啓動併成功地連接到主服務器上 Slave_SQL_Running: SQL線程是否被啓動 Seconds_Behind_Master: 從屬服務器SQL線程和從屬服務器I/O線程之間的時間差距,單位以秒計。
從庫同步延遲情況出現的 ● show slave status顯示參數Seconds_Behind_Master不爲0,這個數值可能會很大 ● show slave status顯示參數Relay_Master_Log_File和Master_Log_File顯示bin-log的編號相差很大,說明bin-log在從庫上沒有及時同步,所以近期執行的bin-log和當前IO線程所讀的bin-log相差很大 ● mysql的從庫數據目錄下存在大量mysql-relay-log日誌,該日誌同步完成之後就會被系統自動刪除,存在大量日誌,說明主從同步延遲很厲害
(2)、MySql數據庫從庫同步的延遲問題
1)、MySQL數據庫主從同步延遲原理mysql主從同步原理:主庫針對寫操作,順序寫binlog,從庫單線程去主庫順序讀”寫操作的binlog”,從庫取到binlog在本地原樣執行(隨機寫),來保證主從數據邏輯上一致。mysql的主從複製都是單線程的操作,主庫對所有DDL和DML產生binlog,binlog是順序寫,所以效率很高,slave的Slave_IO_Running線程到主庫取日誌,效率比較高,下一步,問題來了,slave的Slave_SQL_Running線程將主庫的DDL和DML操作在slave實施。DML和DDL的IO操作是隨即的,不是順序的,成本高很多,還可能可slave上的其他查詢產生lock爭用,由於Slave_SQL_Running也是單線程的,所以一個DDL卡主了,需要執行10分鐘,那麼所有之後的DDL會等待這個DDL執行完纔會繼續執行,這就導致了延時。有朋友會問:“主庫上那個相同的DDL也需要執行10分,爲什麼slave會延時?”,答案是master可以併發,Slave_SQL_Running線程卻不可以。
2)、MySQL數據庫主從同步延遲是怎麼產生的?當主庫的TPS併發較高時,產生的DDL數量超過slave一個sql線程所能承受的範圍,那麼延時就產生了,當然還有就是可能與slave的大型query語句產生了鎖等待。首要原因:數據庫在業務上讀寫壓力太大,CPU計算負荷大,網卡負荷大,硬盤隨機IO太高次要原因:讀寫binlog帶來的性能影響,網絡傳輸延遲。
(3)、MySql數據庫從庫同步的延遲解決方案
1)、架構方面
1.業務的持久化層的實現採用分庫架構,mysql服務可平行擴展,分散壓力。
2.單個庫讀寫分離,一主多從,主寫從讀,分散壓力。這樣從庫壓力比主庫高,保護主庫。
3.服務的基礎架構在業務和mysql之間加入memcache或者redis的cache層。降低mysql的讀壓力。
4.不同業務的mysql物理上放在不同機器,分散壓力。
5.使用比主庫更好的硬件設備作爲slave總結,mysql壓力小,延遲自然會變小。
2)、硬件方面
1.採用好服務器,比如4u比2u性能明顯好,2u比1u性能明顯好。
2.存儲用ssd或者盤陣或者san,提升隨機寫的性能。
3.主從間保證處在同一個交換機下面,並且是萬兆環境。
總結,硬件強勁,延遲自然會變小。一句話,縮小延遲的解決方案就是花錢和花時間。
3)、mysql主從同步加速
1、sync_binlog在slave端設置爲0
2、–logs-slave-updates 從服務器從主服務器接收到的更新不記入它的二進制日誌。
3、直接禁用slave端的binlog
4、slave端,如果使用的存儲引擎是innodb,innodb_flush_log_at_trx_commit =2
4)、從文件系統本身屬性角度優化
master端修改linux、Unix文件系統中文件的etime屬性, 由於每當讀文件時OS都會將讀取操作發生的時間回寫到磁盤上,對於讀操作頻繁的數據庫文件來說這是沒必要的,只會增加磁盤系統的負擔影響I/O性能。可以通過設置文件系統的mount屬性,組織操作系統寫atime信息,在linux上的操作爲:打開/etc/fstab,加上noatime參數/dev/sdb1 /data reiserfs noatime 1 2然後重新mount文件系統#mount -oremount /data
5)、同步參數調整主庫是寫,對數據安全性較高,比如sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之類的設置是需要的而slave則不需要這麼高的數據安全,完全可以講sync_binlog設置爲0或者關閉binlog,innodb_flushlog也可以設置爲0來提高sql的執行效率
1、sync_binlog=1 oMySQL提供一個sync_binlog參數來控制數據庫的binlog刷到磁盤上去。默認,sync_binlog=0,表示MySQL不控制binlog的刷新,由文件系統自己控制它的緩存的刷新。這時候的性能是最好的,但是風險也是最大的。一旦系統Crash,在binlog_cache中的所有binlog信息都會被丟失。
如果sync_binlog>0,表示每sync_binlog次事務提交,MySQL調用文件系統的刷新操作將緩存刷下去。最安全的就是sync_binlog=1了,表示每次事務提交,MySQL都會把binlog刷下去,是最安全但是性能損耗最大的設置。這樣的話,在數據庫所在的主機操作系統損壞或者突然掉電的情況下,系統纔有可能丟失1個事務的數據。但是binlog雖然是順序IO,但是設置sync_binlog=1,多個事務同時提交,同樣很大的影響MySQL和IO性能。雖然可以通過group commit的補丁緩解,但是刷新的頻率過高對IO的影響也非常大。
對於高併發事務的系統來說,“sync_binlog”設置爲0和設置爲1的系統寫入性能差距可能高達5倍甚至更多。所以很多MySQL DBA設置的sync_binlog並不是最安全的1,而是2或者是0。這樣犧牲一定的一致性,可以獲得更高的併發和性能。默認情況下,並不是每次寫入時都將binlog與硬盤同步。因此如果操作系統或機器(不僅僅是MySQL服務器)崩潰,有可能binlog中最後的語句丟失了。要想防止這種情況,你可以使用sync_binlog全局變量(1是最安全的值,但也是最慢的),使binlog在每N次binlog寫入後與硬盤同步。即使sync_binlog設置爲1,出現崩潰時,也有可能表內容和binlog內容之間存在不一致性。
2、innodb_flush_log_at_trx_commit (這個很管用)抱怨Innodb比MyISAM慢 100倍?那麼你大概是忘了調整這個值。默認值1的意思是每一次事務提交或事務外的指令都需要把日誌寫入(flush)硬盤,這是很費時的。特別是使用電池供電緩存(Battery backed up cache)時。設成2對於很多運用,特別是從MyISAM錶轉過來的是可以的,它的意思是不寫入硬盤而是寫入系統緩存。日誌仍然會每秒flush到硬 盤,所以你一般不會丟失超過1-2秒的更新。設成0會更快一點,但安全方面比較差,即使MySQL掛了也可能會丟失事務的數據。而值2只會在整個操作系統 掛了時纔可能丟數據。
3、ls(1) 命令可用來列出文件的 atime、ctime 和 mtime。
atime 文件的access time 在讀取文件或者執行文件時更改的ctime 文件的create time 在寫入文件,更改所有者,權限或鏈接設置時隨inode的內容更改而更改mtime 文件的modified time 在寫入文件時隨文件內容的更改而更改ls -lc filename 列出文件的 ctimels -lu filename 列出文件的 atimels -l filename 列出文件的 mtimestat filename 列出atime,mtime,ctimeatime不一定在訪問文件之後被修改因爲:使用ext3文件系統的時候,如果在mount的時候使用了noatime參數那麼就不會更新atime信息。這三個time stamp都放在 inode 中.如果mtime,atime 修改,inode 就一定會改, 既然 inode 改了,那ctime也就跟着改了.之所以在 mount option 中使用 noatime, 就是不想file system 做太多的修改, 而改善讀取效能
(4)、MySql數據庫從庫同步其他問題及解決方案
1)、mysql主從複製存在的問題: ● 主庫宕機後,數據可能丟失 ● 從庫只有一個sql Thread,主庫寫壓力大,複製很可能延時2)、解決方法: ● 半同步複製---解決數據丟失的問題 ● 並行複製----解決從庫複製延遲的問題
3)、半同步複製mysql semi-sync(半同步複製)半同步複製: ● 5.5集成到mysql,以插件的形式存在,需要單獨安裝 ● 確保事務提交後binlog至少傳輸到一個從庫 ● 不保證從庫應用完這個事務的binlog ● 性能有一定的降低,響應時間會更長 ● 網絡異常或從庫宕機,卡主主庫,直到超時或從庫恢復4)、主從複製--異步複製原理、半同步複製和並行複製原理比較
a、異步複製原理:
b、半同步複製原理:
事務在主庫寫完binlog後需要從庫返回一個已接受,才放回給客戶端;5.5集成到mysql,以插件的形式存在,需要單獨安裝確保事務提交後binlog至少傳輸到一個從庫不保證從庫應用完成這個事務的binlog性能有一定的降低網絡異常或從庫宕機,卡主庫,直到超時或從庫恢復
c、並行複製mysql並行複製 ● 社區版5.6中新增 ● 並行是指從庫多線程apply binlog ● 庫級別並行應用binlog,同一個庫數據更改還是串行的(5.7版並行複製基於事務組)設置set global slave_parallel_workers=10;設置sql線程數爲10
原理:從庫多線程apply binlog在社區5.6中新增庫級別並行應用binlog,同一個庫數據更改還是串行的5.7版本並行複製基於事務組
6. 寫SQL語句。。。
略
7. 索引的數據結構,B+樹
mysql索引主要是基於Hash表和B+樹的數據結構,
首先,數據庫使用樹型結構來增加查詢效率,並保持有序。那麼,爲什麼不使用二叉樹來實現數據結構呢,二叉樹算法時間複雜度是lg(N),查詢速度和比較次數都是較小的。
實際上,查詢索引操作最耗資源的不在內存中,而是磁盤IO。索引是存在磁盤上的,當數據量比較大的時候,索引的大小可能達到幾個G。那麼,我們利用索引進行查詢的時候,不可能把索引直接加載到內存中,只能一次讀取一個磁盤頁,一個磁盤頁對應着一個節點,一次讀取操作時一個磁盤io。
在二叉樹查詢時,最壞的情況下查找的次數是樹的高度,即io次數爲樹的高度。B-樹就是比二叉樹“矮胖”的樹。
二叉樹的特徵如下:
1. 根節點至少有兩個子女
2. 每個中間節點包含k-1個元素和k個孩子,其中 m/2 <= k <= m
3. 每個葉子節點包含k-1個元素,其中 m/2 <= k <= m
4. 所有葉子節點位於同一層
5. 節點中的元素從小到大排列,正好是孩子節點的值域。(就是孩子節點的元素都比父節點中元素的最小值大,比父節點元素的最大值小)
B-樹查詢的次數並不比二叉樹的次數小,但是相比起磁盤io速度,內存中比較的耗時就不足爲提了。所以只要樹的高度足夠低,io次數少,就可以提升查找性能。而每個節點中有多個元素,都只在內存中操作。
而B+樹是基於B-樹的,增加了如下規則:
1. 有k個子樹的中間節點包含有k個元素(B樹中是k-1個元素),每個元素不保存數據,只用來索引,所有數據都保存在葉子節點。
2. 所有的葉子結點中包含了全部元素的信息,及指向含這些元素記錄的指針,且葉子結點本身依關鍵字的大小自小而大順序鏈接。
3. 所有的中間節點元素都同時存在於子節點,在子節點元素中是最大(或最小)元素。
所以,B+樹對比B-樹有如下好處:
io次數少:b+樹中間節點只存索引,不存在實際的數據,所以可以存儲更多的數據。索引樹更加的矮胖,io次數更少。
性能穩定:b+樹數據只存在於葉子節點,查詢性能穩定
範圍查詢簡單:b+樹不需要中序遍歷,遍歷鏈表即可。
8. 事務的四個特性,以及各自的特點(原子、隔離)等等,項目怎麼解決這些問題
參考:https://blog.csdn.net/u014378181/article/details/79236774
9. 數據庫的鎖:行鎖,表鎖;樂觀鎖,悲觀鎖
mysql爲什麼提供鎖:防止更新丟失,並不能單靠數據庫事務控制器來解決,需要應用程序對要更新的數據加必要的鎖來解決。
鎖,在現實生活中是爲我們想要隱藏於外界所使用的一種工具。在計算機中,是協調多個進程或縣城併發訪問某一資源的一種機制。在數據庫當中,除了傳統的計算資源(CPU、RAM、I/O等等)的爭用之外,數據也是一種供許多用戶共享訪問的資源。如何保證數據併發訪問的一致性、有效性,是所有數據庫必須解決的一個問題,鎖的衝突也是影響數據庫併發訪問性能的一個重要因素。從這一角度來說,鎖對於數據庫而言就顯得尤爲重要。
MySQL鎖
相對於其他的數據庫而言,MySQL的鎖機制比較簡單,最顯著的特點就是不同的存儲引擎支持不同的鎖機制。根據不同的存儲引擎,MySQL中鎖的特性可以大致歸納如下:
|
行鎖 |
表鎖 |
頁鎖 |
MyISAM |
|
√ |
|
BDB |
|
√ |
√ |
InnoDB |
√ |
√ |
|
開銷、加鎖速度、死鎖、粒度、併發性能
表鎖:
開銷小,加鎖快;不會出現死鎖;鎖定力度大,發生鎖衝突概率高,併發度最低
行鎖:
開銷大,加鎖慢;會出現死鎖;鎖定粒度小,發生鎖衝突的概率低,併發度高
頁鎖:
開銷和加鎖速度介於表鎖和行鎖之間;會出現死鎖;鎖定粒度介於表鎖和行鎖之間,併發度一般
從上述的特點課件,很難籠統的說哪種鎖最好,只能根據具體應用的特點來說哪種鎖更加合適。僅僅從鎖的角度來說的話:
表鎖更適用於以查詢爲主,只有少量按索引條件更新數據的應用;行鎖更適用於有大量按索引條件併發更新少量不同數據,同時又有併發查詢的應用。
深入瞭解:https://blog.csdn.net/mysteryhaohao/article/details/51669741
10. 數據庫事務的幾種粒度;
參考:https://blog.csdn.net/u014378181/article/details/79236774
11. 關係型和非關係型數據庫區別
一、關係型數據庫
關係型數據庫最典型的數據結構是表,由二維表及其之間的聯繫所組成的一個數據組織
優點:
1、易於維護:都是使用表結構,格式一致;
2、使用方便:SQL語言通用,可用於複雜查詢;
3、複雜操作:支持SQL,可用於一個表以及多個表之間非常複雜的查詢。
缺點:
1、讀寫性能比較差,尤其是海量數據的高效率讀寫;
2、固定的表結構,靈活度稍欠;
3、高併發讀寫需求,傳統關係型數據庫來說,硬盤I/O是一個很大的瓶頸。
二、非關係型數據庫
非關係型數據庫嚴格上不是一種數據庫,應該是一種數據結構化存儲方法的集合,可以是文檔或者鍵值對等。
優點:
1、格式靈活:存儲數據的格式可以是key,value形式、文檔形式、圖片形式等等,文檔形式、圖片形式等等,使用靈活,應用場景廣泛,而關係型數據庫則只支持基礎類型。
2、速度快:nosql可以使用硬盤或者隨機存儲器作爲載體,而關係型數據庫只能使用硬盤;
3、高擴展性;
4、成本低:nosql數據庫部署簡單,基本都是開源軟件。
缺點:
1、不提供sql支持,學習和使用成本較高;
2、無事務處理;
3、數據結構相對複雜,複雜查詢方面稍欠。
非關係型數據庫的分類和比較:
1、文檔型
2、key-value型
3、列式數據庫
4、圖形數據庫