溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并發分布式等教程，一共30G，需要自己領取。
傳送門：https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q
作為一名開發人員，在日常的工作中會難以避免地接觸到數據庫，無論是基于文件的 sqlite 還是工程上使用非常廣泛的 MySQL、PostgreSQL，但是一直以來也沒有對數據庫有一個非常清晰并且成體系的認知，所以最近兩個月的時間看了幾本數據庫相關的書籍并且閱讀了 MySQL 的官方文檔，希望對各位了解數據庫的、不了解數據庫的有所幫助。
本文中對于數據庫的介紹以及研究都是在 MySQL 上進行的，如果涉及到了其他數據庫的內容或者實現會在文中單獨指出。
很多開發者在最開始時其實都對數據庫有一個比較模糊的認識，覺得數據庫就是一堆數據的集合，但是實際卻比這復雜的多，數據庫領域中有兩個詞非常容易混淆，也就是數據庫和實例：
數據庫：物理操作文件系統或其他形式文件類型的集合；
實例：MySQL 數據庫由后臺線程以及一個共享內存區組成；
對于數據庫和實例的定義都來自于?MySQL 技術內幕：InnoDB 存儲引擎?一書，想要了解 InnoDB 存儲引擎的讀者可以閱讀這本書籍。
在 MySQL 中，實例和數據庫往往都是一一對應的，而我們也無法直接操作數據庫，而是要通過數據庫實例來操作數據庫文件，可以理解為數據庫實例是數據庫為上層提供的一個專門用于操作的接口。
在 Unix 上，啟動一個 MySQL 實例往往會產生兩個進程，mysqld?就是真正的數據庫服務守護進程，而?mysqld_safe?是一個用于檢查和設置?mysqld?啟動的控制程序，它負責監控 MySQL 進程的執行，當?mysqld?發生錯誤時，mysqld_safe?會對其狀態進行檢查并在合適的條件下重啟。
MySQL 從第一個版本發布到現在已經有了 20 多年的歷史，在這么多年的發展和演變中，整個應用的體系結構變得越來越復雜：
最上層用于連接、線程處理的部分并不是 MySQL 『發明』的，很多服務都有類似的組成部分；第二層中包含了大多數 MySQL 的核心服務，包括了對 SQL 的解析、分析、優化和緩存等功能，存儲過程、觸發器和視圖都是在這里實現的；而第三層就是 MySQL 中真正負責數據的存儲和提取的存儲引擎，例如：InnoDB、MyISAM?等，文中對存儲引擎的介紹都是對 InnoDB 實現的分析。
在整個數據庫體系結構中，我們可以使用不同的存儲引擎來存儲數據，而絕大多數存儲引擎都以二進制的形式存儲數據；這一節會介紹 InnoDB 中對數據是如何存儲的。
在 InnoDB 存儲引擎中，所有的數據都被邏輯地存放在表空間中，表空間（tablespace）是存儲引擎中最高的存儲邏輯單位，在表空間的下面又包括段（segment）、區（extent）、頁（page）：
同一個數據庫實例的所有表空間都有相同的頁大小；默認情況下，表空間中的頁大小都為 16KB，當然也可以通過改變?innodb_page_size?選項對默認大小進行修改，需要注意的是不同的頁大小最終也會導致區大小的不同：
從圖中可以看出，在 InnoDB 存儲引擎中，一個區的大小最小為 1MB，頁的數量最少為 64 個。
MySQL 使用 InnoDB 存儲表時，會將表的定義和數據索引等信息分開存儲，其中前者存儲在?.frm?文件中，后者存儲在?.ibd?文件中，這一節就會對這兩種不同的文件分別進行介紹。
無論在 MySQL 中選擇了哪個存儲引擎，所有的 MySQL 表都會在硬盤上創建一個?.frm?文件用來描述表的格式或者說定義；.frm?文件的格式在不同的平臺上都是相同的。
CREATE?TABLE?test_frm( ????column1?CHAR(5), ????column2?INTEGER );
當我們使用上面的代碼創建表時，會在磁盤上的?datadir?文件夾中生成一個?test_frm.frm?的文件，這個文件中就包含了表結構相關的信息：
MySQL 官方文檔中的?11.1 MySQL .frm File Format?一文對于?.frm?文件格式中的二進制的內容有著非常詳細的表述，在這里就不展開介紹了。InnoDB 中用于存儲數據的文件總共有兩個部分，一是系統表空間文件，包括?ibdata1、ibdata2?等文件，其中存儲了 InnoDB 系統信息和用戶數據庫表數據和索引，是所有表公用的。
當打開?innodb_file_per_table?選項時，.ibd?文件就是每一個表獨有的表空間，文件存儲了當前表的數據和相關的索引數據。
與現有的大多數存儲引擎一樣，InnoDB 使用頁作為磁盤管理的最小單位；數據在 InnoDB 存儲引擎中都是按行存儲的，每個 16KB 大小的頁中可以存放 2-200 行的記錄。
當 InnoDB 存儲數據時，它可以使用不同的行格式進行存儲；MySQL 5.7 版本支持以下格式的行存儲方式：
Antelope 是 InnoDB 最開始支持的文件格式，它包含兩種行格式 Compact 和 Redundant，它最開始并沒有名字；Antelope 的名字是在新的文件格式 Barracuda 出現后才起的，Barracuda 的出現引入了兩種新的行格式 Compressed 和 Dynamic；InnoDB 對于文件格式都會向前兼容，而官方文檔中也對之后會出現的新文件格式預先定義好了名字：Cheetah、Dragon、Elk 等等。
兩種行記錄格式 Compact 和 Redundant 在磁盤上按照以下方式存儲：
Compact 和 Redundant 格式最大的不同就是記錄格式的第一個部分；在 Compact 中，行記錄的第一部分倒序存放了一行數據中列的長度（Length），而 Redundant 中存的是每一列的偏移量（Offset），從總體上上看，Compact 行記錄格式相比 Redundant 格式能夠減少 20% 的存儲空間。
當 InnoDB 使用 Compact 或者 Redundant 格式存儲極長的 VARCHAR 或者 BLOB 這類大對象時，我們并不會直接將所有的內容都存放在數據頁節點中，而是將行數據中的前 768 個字節存儲在數據頁中，后面會通過偏移量指向溢出頁。
但是當我們使用新的行記錄格式 Compressed 或者 Dynamic 時都只會在行記錄中保存 20 個字節的指針，實際的數據都會存放在溢出頁面中。
當然在實際存儲中，可能會對不同長度的 TEXT 和 BLOB 列進行優化，不過這就不是本文關注的重點了。
想要了解更多與 InnoDB 存儲引擎中記錄的數據格式的相關信息，可以閱讀?InnoDB Record Structure
頁是 InnoDB 存儲引擎管理數據的最小磁盤單位，而 B-Tree 節點就是實際存放表中數據的頁面，我們在這里將要介紹頁是如何組織和存儲記錄的；首先，一個 InnoDB 頁有以下七個部分：
每一個頁中包含了兩對 header/trailer：內部的 Page Header/Page Directory 關心的是頁的狀態信息，而 Fil Header/Fil Trailer 關心的是記錄頁的頭信息。
在頁的頭部和尾部之間就是用戶記錄和空閑空間了，每一個數據頁中都包含 Infimum 和 Supremum 這兩個虛擬的記錄（可以理解為占位符），Infimum 記錄是比該頁中任何主鍵值都要小的值，Supremum 是該頁中的最大值：
User Records 就是整個頁面中真正用于存放行記錄的部分，而 Free Space 就是空余空間了，它是一個鏈表的數據結構，為了保證插入和刪除的效率，整個頁面并不會按照主鍵順序對所有記錄進行排序，它會自動從左側向右尋找空白節點進行插入，行記錄在物理存儲上并不是按照順序的，它們之間的順序是由?next_record?這一指針控制的。
B+ 樹在查找對應的記錄時，并不會直接從樹中找出對應的行記錄，它只能獲取記錄所在的頁，將整個頁加載到內存中，再通過 Page Directory 中存儲的稀疏索引和?n_owned、next_record?屬性取出對應的記錄，不過因為這一操作是在內存中進行的，所以通常會忽略這部分查找的耗時。
InnoDB 存儲引擎中對數據的存儲是一個非常復雜的話題，這一節中也只是對表、行記錄以及頁面的存儲進行一定的分析和介紹，雖然作者相信這部分知識對于大部分開發者已經足夠了，但是想要真正消化這部分內容還需要很多的努力和實踐。
索引是數據庫中非常非常重要的概念，它是存儲引擎能夠快速定位記錄的秘密武器，對于提升數據庫的性能、減輕數據庫服務器的負擔有著非常重要的作用；索引優化是對查詢性能優化的最有效手段，它能夠輕松地將查詢的性能提高幾個數量級。
在上一節中，我們談了行記錄的存儲和頁的存儲，在這里我們就要從更高的層面看 InnoDB 中對于數據是如何存儲的；InnoDB 存儲引擎在絕大多數情況下使用 B+ 樹建立索引，這是關系型數據庫中查找最為常用和有效的索引，但是 B+ 樹索引并不能找到一個給定鍵對應的具體值，它只能找到數據行對應的頁，然后正如上一節所提到的，數據庫把整個頁讀入到內存中，并在內存中查找具體的數據行。
B+ 樹是平衡樹，它查找任意節點所耗費的時間都是完全相同的，比較的次數就是 B+ 樹的高度；在這里，我們并不會深入分析或者動手實現一個 B+ 樹，只是對它的特性進行簡單的介紹。
數據庫中的 B+ 樹索引可以分為聚集索引（clustered index）和輔助索引（secondary index），它們之間的最大區別就是，聚集索引中存放著一條行記錄的全部信息，而輔助索引中只包含索引列和一個用于查找對應行記錄的『書簽』。
InnoDB 存儲引擎中的表都是使用索引組織的，也就是按照鍵的順序存放；聚集索引就是按照表中主鍵的順序構建一顆 B+ 樹，并在葉節點中存放表中的行記錄數據。
CREATE?TABLE?users( ????id?INT?NOT?NULL, ????first_name?VARCHAR(20)?NOT?NULL, ????last_name?VARCHAR(20)?NOT?NULL, ????age?INT?NOT?NULL, ????PRIMARY?KEY(id), ????KEY(last_name,?first_name,?age) ????KEY(first_name) );
如果使用上面的 SQL 在數據庫中創建一張表，B+ 樹就會使用?id?作為索引的鍵，并在葉子節點中存儲一條記錄中的所有信息。
圖中對 B+ 樹的描述與真實情況下 B+ 樹中的數據結構有一些差別，不過這里想要表達的主要意思是：聚集索引葉節點中保存的是整條行記錄，而不是其中的一部分。
聚集索引與表的物理存儲方式有著非常密切的關系，所有正常的表應該有且僅有一個聚集索引（絕大多數情況下都是主鍵），表中的所有行記錄數據都是按照聚集索引的順序存放的。
當我們使用聚集索引對表中的數據進行檢索時，可以直接獲得聚集索引所對應的整條行記錄數據所在的頁，不需要進行第二次操作。
數據庫將所有的非聚集索引都劃分為輔助索引，但是這個概念對我們理解輔助索引并沒有什么幫助；輔助索引也是通過 B+ 樹實現的，但是它的葉節點并不包含行記錄的全部數據，僅包含索引中的所有鍵和一個用于查找對應行記錄的『書簽』，在 InnoDB 中這個書簽就是當前記錄的主鍵。
輔助索引的存在并不會影響聚集索引，因為聚集索引構成的 B+ 樹是數據實際存儲的形式，而輔助索引只用于加速數據的查找，所以一張表上往往有多個輔助索引以此來提升數據庫的性能。
一張表一定包含一個聚集索引構成的 B+ 樹以及若干輔助索引的構成的 B+ 樹。
如果在表?users?中存在一個輔助索引?(first_name, age)，那么它構成的 B+ 樹大致就是上圖這樣，按照?(first_name, age)?的字母順序對表中的數據進行排序，當查找到主鍵時，再通過聚集索引獲取到整條行記錄。
上圖展示了一個使用輔助索引查找一條表記錄的過程：通過輔助索引查找到對應的主鍵，最后在聚集索引中使用主鍵獲取對應的行記錄，這也是通常情況下行記錄的查找方式。
索引的設計其實是一個非常重要的內容，同時也是一個非常復雜的內容；索引的設計與創建對于提升數據庫的查詢性能至關重要，不過這不是本文想要介紹的內容，有關索引的設計與優化可以閱讀?數據庫索引設計與優化?一書，書中提供了一種非常科學合理的方法能夠幫助我們在數據庫中建立最適合的索引，當然作者也可能會在之后的文章中對索引的設計進行簡單的介紹和分析。
我們都知道鎖的種類一般分為樂觀鎖和悲觀鎖兩種，InnoDB 存儲引擎中使用的就是悲觀鎖，而按照鎖的粒度劃分，也可以分成行鎖和表鎖。
樂觀鎖和悲觀鎖其實都是并發控制的機制，同時它們在原理上就有著本質的差別；
樂觀鎖是一種思想，它其實并不是一種真正的『鎖』，它會先嘗試對資源進行修改，在寫回時判斷資源是否進行了改變，如果沒有發生改變就會寫回，否則就會進行重試，在整個的執行過程中其實都沒有對數據庫進行加鎖；
悲觀鎖就是一種真正的鎖了，它會在獲取資源前對資源進行加鎖，確保同一時刻只有有限的線程能夠訪問該資源，其他想要嘗試獲取資源的操作都會進入等待狀態，直到該線程完成了對資源的操作并且釋放了鎖后，其他線程才能重新操作資源；
雖然樂觀鎖和悲觀鎖在本質上并不是同一種東西，一個是一種思想，另一個是一種真正的鎖，但是它們都是一種并發控制機制。
樂觀鎖不會存在死鎖的問題，但是由于更新后驗證，所以當沖突頻率和重試成本較高時更推薦使用悲觀鎖，而需要非常高的響應速度并且并發量非常大的時候使用樂觀鎖就能較好的解決問題，在這時使用悲觀鎖就可能出現嚴重的性能問題；在選擇并發控制機制時，需要綜合考慮上面的四個方面（沖突頻率、重試成本、響應速度和并發量）進行選擇。
對數據的操作其實只有兩種，也就是讀和寫，而數據庫在實現鎖時，也會對這兩種操作使用不同的鎖；InnoDB 實現了標準的行級鎖，也就是共享鎖（Shared Lock）和互斥鎖（Exclusive Lock）；共享鎖和互斥鎖的作用其實非常好理解：
共享鎖（讀鎖）：允許事務對一條行數據進行讀取；
互斥鎖（寫鎖）：允許事務對一條行數據進行刪除或更新；
而它們的名字也暗示著各自的另外一個特性，共享鎖之間是兼容的，而互斥鎖與其他任意鎖都不兼容：
稍微對它們的使用進行思考就能想明白它們為什么要這么設計，因為共享鎖代表了讀操作、互斥鎖代表了寫操作，所以我們可以在數據庫中并行讀，但是只能串行寫，只有這樣才能保證不會發生線程競爭，實現線程安全。
無論是共享鎖還是互斥鎖其實都只是對某一個數據行進行加鎖，InnoDB 支持多種粒度的鎖，也就是行鎖和表鎖；為了支持多粒度鎖定，InnoDB 存儲引擎引入了意向鎖（Intention Lock），意向鎖就是一種表級鎖。
與上一節中提到的兩種鎖的種類相似的是，意向鎖也分為兩種：
意向共享鎖：事務想要在獲得表中某些記錄的共享鎖，需要在表上先加意向共享鎖；
意向互斥鎖：事務想要在獲得表中某些記錄的互斥鎖，需要在表上先加意向互斥鎖；
隨著意向鎖的加入，鎖類型之間的兼容矩陣也變得愈加復雜：
意向鎖其實不會阻塞全表掃描之外的任何請求，它們的主要目的是為了表示是否有人請求鎖定表中的某一行數據。
有的人可能會對意向鎖的目的并不是完全的理解，我們在這里可以舉一個例子：如果沒有意向鎖，當已經有人使用行鎖對表中的某一行進行修改時，如果另外一個請求要對全表進行修改，那么就需要對所有的行是否被鎖定進行掃描，在這種情況下，效率是非常低的；不過，在引入意向鎖之后，當有人使用行鎖對表中的某一行進行修改之前，會先為表添加意向互斥鎖（IX），再為行記錄添加互斥鎖（X），在這時如果有人嘗試對全表進行修改就不需要判斷表中的每一行數據是否被加鎖了，只需要通過等待意向互斥鎖被釋放就可以了。
到目前為止已經對 InnoDB 中鎖的粒度有一定的了解，也清楚了在對數據庫進行讀寫時會獲取不同的鎖，在這一小節將介紹鎖是如何添加到對應的數據行上的，我們會分別介紹三種鎖的算法：Record Lock、Gap Lock 和 Next-Key Lock。
記錄鎖（Record Lock）是加到索引記錄上的鎖，假設我們存在下面的一張表?users：
CREATE?TABLE?users( ????id?INT?NOT?NULL?AUTO_INCREMENT, ????last_name?VARCHAR(255)?NOT?NULL, ????first_name?VARCHAR(255), ????age?INT, ????PRIMARY?KEY(id), ????KEY(last_name), ????KEY(age) );
如果我們使用?id?或者?last_name?作為 SQL 中?WHERE?語句的過濾條件，那么 InnoDB 就可以通過索引建立的 B+ 樹找到行記錄并添加索引，但是如果使用?first_name?作為過濾條件時，由于 InnoDB 不知道待修改的記錄具體存放的位置，也無法對將要修改哪條記錄提前做出判斷就會鎖定整個表。
記錄鎖是在存儲引擎中最為常見的鎖，除了記錄鎖之外，InnoDB 中還存在間隙鎖（Gap Lock），間隙鎖是對索引記錄中的一段連續區域的鎖；當使用類似?SELECT * FROM users WHERE id BETWEEN 10 AND 20 FOR UPDATE;?的 SQL 語句時，就會阻止其他事務向表中插入?id = 15?的記錄，因為整個范圍都被間隙鎖鎖定了。
間隙鎖是存儲引擎對于性能和并發做出的權衡，并且只用于某些事務隔離級別。
雖然間隙鎖中也分為共享鎖和互斥鎖，不過它們之間并不是互斥的，也就是不同的事務可以同時持有一段相同范圍的共享鎖和互斥鎖，它唯一阻止的就是其他事務向這個范圍中添加新的記錄。
Next-Key 鎖相比前兩者就稍微有一些復雜，它是記錄鎖和記錄前的間隙鎖的結合，在?users?表中有以下記錄：
+------|-------------|--------------|-------+ |???id?|?last_name???|?first_name???|???age?| |------|-------------|--------------|-------| |????4?|?stark???????|?tony?????????|????21?| |????1?|?tom?????????|?hiddleston???|????30?| |????3?|?morgan??????|?freeman??????|????40?| |????5?|?jeff????????|?dean?????????|????50?| |????2?|?donald??????|?trump????????|????80?| +------|-------------|--------------|-------+
如果使用 Next-Key 鎖，那么 Next-Key 鎖就可以在需要的時候鎖定以下的范圍：
(-∞,?21] (21,?30] (30,?40] (40,?50] (50,?80] (80,?∞)
既然叫 Next-Key 鎖，鎖定的應該是當前值和后面的范圍，但是實際上卻不是，Next-Key 鎖鎖定的是當前值和前面的范圍。
當我們更新一條記錄，比如?SELECT * FROM users WHERE age = 30 FOR UPDATE;，InnoDB 不僅會在范圍?(21, 30]?上加 Next-Key 鎖，還會在這條記錄后面的范圍?(30, 40]?加間隙鎖，所以插入?(21, 40]?范圍內的記錄都會被鎖定。
Next-Key 鎖的作用其實是為了解決幻讀的問題，我們會在下一節談事務的時候具體介紹。
既然 InnoDB 中實現的鎖是悲觀的，那么不同事務之間就可能會互相等待對方釋放鎖造成死鎖，最終導致事務發生錯誤；想要在 MySQL 中制造死鎖的問題其實非常容易：
兩個會話都持有一個鎖，并且嘗試獲取對方的鎖時就會發生死鎖，不過 MySQL 也能在發生死鎖時及時發現問題，并保證其中的一個事務能夠正常工作，這對我們來說也是一個好消息。
在介紹了鎖之后，我們再來談談數據庫中一個非常重要的概念 —— 事務；相信只要是一個合格的軟件工程師就對事務的特性有所了解，其中被人經常提起的就是事務的原子性，在數據提交工作時，要么保證所有的修改都能夠提交，要么就所有的修改全部回滾。
但是事務還遵循包括原子性在內的 ACID 四大特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）；文章不會對這四大特性全部展開進行介紹，相信你能夠通過 Google 和數據庫相關的書籍輕松獲得有關它們的概念，本文最后要介紹的就是事務的四種隔離級別。
事務的隔離性是數據庫處理數據的幾大基礎之一，而隔離級別其實就是提供給用戶用于在性能和可靠性做出選擇和權衡的配置項。
ISO 和 ANIS SQL 標準制定了四種事務隔離級別，而 InnoDB 遵循了 SQL:1992 標準中的四種隔離級別：READ UNCOMMITED、READ COMMITED、REPEATABLE READ?和?SERIALIZABLE；每個事務的隔離級別其實都比上一級多解決了一個問題：
RAED UNCOMMITED：使用查詢語句不會加鎖，可能會讀到未提交的行（Dirty Read）；
READ COMMITED：只對記錄加記錄鎖，而不會在記錄之間加間隙鎖，所以允許新的記錄插入到被鎖定記錄的附近，所以再多次使用查詢語句時，可能得到不同的結果（Non-Repeatable Read）；
REPEATABLE READ：多次讀取同一范圍的數據會返回第一次查詢的快照，不會返回不同的數據行，但是可能發生幻讀（Phantom Read）；
SERIALIZABLE：InnoDB 隱式地將全部的查詢語句加上共享鎖，解決了幻讀的問題；
MySQL 中默認的事務隔離級別就是?REPEATABLE READ，但是它通過 Next-Key 鎖也能夠在某種程度上解決幻讀的問題。
接下來，我們將數據庫中創建如下的表并通過個例子來展示在不同的事務隔離級別之下，會發生什么樣的問題：
CREATE?TABLE?test( ????id?INT?NOT?NULL, ????UNIQUE(id) );
在一個事務中，讀取了其他事務未提交的數據。
當事務的隔離級別為?READ UNCOMMITED?時，我們在?SESSION 2?中插入的未提交數據在?SESSION 1?中是可以訪問的。
在一個事務中，同一行記錄被訪問了兩次卻得到了不同的結果。
當事務的隔離級別為?READ COMMITED?時，雖然解決了臟讀的問題，但是如果在?SESSION 1?先查詢了一行數據，在這之后?SESSION 2?中修改了同一行數據并且提交了修改，在這時，如果?SESSION 1?中再次使用相同的查詢語句，就會發現兩次查詢的結果不一樣。
不可重復讀的原因就是，在?READ COMMITED?的隔離級別下，存儲引擎不會在查詢記錄時添加行鎖，鎖定?id = 3?這條記錄。
在一個事務中，同一個范圍內的記錄被讀取時，其他事務向這個范圍添加了新的記錄。
重新開啟了兩個會話?SESSION 1?和?SESSION 2，在?SESSION 1?中我們查詢全表的信息，沒有得到任何記錄；在?SESSION 2?中向表中插入一條數據并提交；由于?REPEATABLE READ?的原因，再次查詢全表的數據時，我們獲得到的仍然是空集，但是在向表中插入同樣的數據卻出現了錯誤。
這種現象在數據庫中就被稱作幻讀，雖然我們使用查詢語句得到了一個空的集合，但是插入數據時卻得到了錯誤，好像之前的查詢是幻覺一樣。
在標準的事務隔離級別中，幻讀是由更高的隔離級別?SERIALIZABLE?解決的，但是它也可以通過 MySQL 提供的 Next-Key 鎖解決：
REPEATABLE READ?和?READ UNCOMMITED?其實是矛盾的，如果保證了前者就看不到已經提交的事務，如果保證了后者，就會導致兩次查詢的結果不同，MySQL 為我們提供了一種折中的方式，能夠在?REPEATABLE READ?模式下加鎖訪問已經提交的數據，其本身并不能解決幻讀的問題，而是通過文章前面提到的 Next-Key 鎖來解決。
原文：https://draveness.me/mysql-innodb
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
