誰能說說mangodb 和 hbase的區別

1.Mongodb bson文檔型數據庫，整個數據都存在磁盤中，hbase是列式數據庫，集群部署時每個familycolumn保存在單獨的hdfs文件中。

西鄉網站建設公司創新互聯,西鄉網站設計制作，有大型網站制作公司豐富經驗。已為西鄉成百上千家提供企業網站建設服務。企業網站搭建\成都外貿網站建設公司要多少錢，請找那個售后服務好的西鄉做網站的公司定做！

2.Mongodb 主鍵是“_id”,主鍵上面可以不建索引,記錄插入的順序和存放的順序一樣，hbase的主鍵就是row key，可以是任意字符串(最大長度是 64KB，實際應用中長度一般為 10-100bytes)，在hbase內部，row key保存為字節數組。存儲時，數據按照Row key的字典序(byte order)排序存儲。設計key時，要充分排序存儲這個特性，將經常一起讀取的行存儲放到一起。

字典序對int排序的結果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行鍵必須用0作左填充。

3.Mongodb支持二級索引，而hbase本身不支持二級索引

4.Mongodb支持集合查找，正則查找，范圍查找，支持skip和limit等等，是最像mysql的nosql數據庫，而hbase只支持三種查找：通過單個row key訪問，通過row key的range，全表掃描

5.mongodb的update是update-in-place，也就是原地更新，除非原地容納不下更新后的數據記錄。而hbase的修改和添加都是同一個命令：put，如果put傳入的row key已經存在就更新原記錄,實際上hbase內部也不是更新，它只是將這一份數據已不同的版本保存下來而已，hbase默認的保存版本的歷史數量是3。

6.mongodb的delete會將該行的數據標示為已刪除，因為mongodb在刪除記錄時并不是真把記錄從內存或文件中remove，而是將該刪除記錄數據置空（寫0或特殊數字加以標識）同時將該記錄所在地址放到一個list列表“釋放列表”中，這樣做的好就是就是如果有用戶要執行插入記錄操作時，mongodb會首先從該“釋放列表”中獲取size合適的“已刪除記錄”地址返回，這種方法會提升性能（避免了malloc內存操作），同時mongodb也使用了bucket size數組來定義多個大小size不同的列表，用于將要刪除的記錄根據其size大小放到合適的“釋放列表”中。Hbase的delete是先新建一個tombstonemarkers，然后讀的時候會和tombstonemarkers做merge，在 發生major compaction時delete的數據記錄才會真真刪除。

7.mongodb和hbase都支持mapreduce，不過mongodb的mapreduce支持不夠強大，如果沒有使用mongodb分片，mapreduce實際上不是并行執行的

8.mongodb支持shard分片，hbase根據row key自動負載均衡，這里shard key和row key的選取盡量用非遞增的字段，盡量用分布均衡的字段，因為分片都是根據范圍來選擇對應的存取server的，如果用遞增字段很容易熱點server的產生，由于是根據key的范圍來自動分片的，如果key分布不均衡就會導致有些key根本就沒法切分，從而產生負載不均衡。

9.mongodb的讀效率比寫高，hbase默認適合寫多讀少的情況，可以通過hfile.block.cache.size配置，該配置storefile的讀緩存占用Heap的大小百分比，0.2表示20%。該值直接影響數據讀的性能。如果寫比讀少很多，開到0.4-0.5也沒問題。如果讀寫較均衡，0.3左右。如果寫比讀多，果斷默認0.2吧。設置這個值的時候，你同時要參考hbase.regionserver.global.memstore.upperLimit，該值是memstore占heap的最大百分比，兩個參數一個影響讀，一個影響寫。如果兩值加起來超過80-90%，會有OOM的風險，謹慎設置。

10.hbase采用的LSM思想(Log-Structured Merge-Tree)，就是將對數據的更改hold在內存中，達到指定的threadhold后將該批更改merge后批量寫入到磁盤，這樣將單個寫變成了批量寫，大大提高了寫入速度，不過這樣的話讀的時候就費勁了，需要merge disk上的數據和memory中的修改數據，這顯然降低了讀的性能。mongodb采用的是mapfile+Journal思想，如果記錄不在內存，先加載到內存，然后在內存中更改后記錄日志，然后隔一段時間批量的寫入data文件，這樣對內存的要求較高，至少需要容納下熱點數據和索引。

Apache Cassandra數據庫的優缺點有哪些

Apache Cassandra數據庫的優缺點有哪些？

TAG標簽： 數據庫 Apache 優缺點 Cassandra

本文將超越眾所周知的一些細節，探討與 Cassandra 相關的不太明顯的細節。您將檢查 Cassandra 數據模型、存儲模式設計、架構，以及與 Cassandra 相關的潛在驚喜。

在數據庫歷史文章 “What Goes Around Comes Around”中，Michal Stonebraker 詳細描述了存儲技術是如何隨著時間的推移而發展的。實現關系模型之前，開發人員曾嘗試過其他模型，比如層次圖和有向圖。值得注意的是，基于 SQL 的關系模型（即使到現在也仍然是事實上的標準）已經盛行了大約 30 年。鑒于計算機科學的短暫歷史及其快速發展的步伐，這是一項非凡的成就。關系模型建立已久，以至于許多年來，解決方案架構師很容易為應用程序選擇數據存儲。他們的選擇總是關系數據庫。

諸如增加系統、移動設備、擴展的用戶在線狀態、云計算和多核系統的用戶群之類的開發已經導致產生越來越多的大型系統。Google 和 Amazon 之類的高科技公司都是首批觸及規模問題的公司。他們很快就發現關系數據庫并不足以支持大型系統。

為了避免這些挑戰，Google 和 Amazon 提出了兩個可供選擇的解決方案：Big Table 和 Dynamo，他們可以由此放松關系數據模型提供的保證，從而實現更高的可擴展性。Eric Brewer 的 “CAP Theorem”后來官方化了這些觀察結果。它宣稱，對于可擴展性系統，一致性、可用性和分區容錯性都是權衡因素，因為根本不可能構建包含所有這些屬性的系統。不久之后，根據 Google 和 Amazon 早期的工作，以及所獲得的對可擴展性系統的理解，計劃創建一種新的存儲系統。這些系統被命名為 “NoSQL” 系統。該名稱最初的意思是 “如果想縮放就不要使用 SQL”，后來被重新定義為 “不只是 SQL”，意思是說，除了基于 SQL 的解決方案外，還有其他的解決方案。

有許多 NoSQL 系統，而且每一個系統都緩和或改變了關系模型的某些方面。值得注意的是，沒有一個 NoSQL 解決方案適用于所有的場景。每一個解決方案都優于關系模型，且針對一些用例子集進行了縮放。我的早期文章 “在 Data Storage Haystack 中為您的應用程序尋找正確的數據解決方案” 討論了如何使應用程序需求和 NoSQL 解決方案相匹配。

Apache Cassandra是其中一個最早也是最廣泛使用的 NoSQL 解決方案。本文詳細介紹了 Cassandra，并指出了一些首次使用 Cassandra 時不容易發現的細節和復雜之處。

Apache Cassandra

Cassandra 是一個 NoSQL 列族 (column family) 實現，使用由 Amazon Dynamo 引入的架構方面的特性來支持 Big Table 數據模型。Cassandra 的一些優勢如下所示：

高度可擴展性和高度可用性，沒有單點故障

NoSQL 列族實現

非常高的寫入吞吐量和良好的讀取吞吐量

類似 SQL 的查詢語言（從 0.8 起），并通過二級索引支持搜索

可調節的一致性和對復制的支持

靈活的模式

這些優點很容易讓人們推薦使用 Cassandra，但是，對于開發人員來說，至關重要的一點是要深入探究 Cassandra 的細節和復雜之處，從而掌握該程序的復雜性。

什么是列？

列 有點用詞不當，使用名稱單元格 很可能更容易理解一些。我會堅持使用列，因為這是一種習慣用法。

Cassandra 數據模型包括列、行、列族和密鑰空間 (keyspace)。讓我們逐一進行詳細介紹它們。

?列：Cassandra 數據模型中最基本的單元，每一個列包括一個名稱、一個值和一個時間戳。在本文的討論中，我們忽略了時間戳，您可以將一個列表示為一個名稱值對（例如 author="Asimov"）。

?行：用一個名稱標記的列的集合。例如，清單 1 顯示了如何表示一個行：

清單 1. 行的示例

"Second Foundation"- {

author="Asimov",

publishedDate="..",

tag1="sci-fi", tag2="Asimov"

}

Cassandra 包括許多存儲節點，并且在單個存儲節點內存儲每一個行。在每一行內，Cassandra 總是存儲按照列名稱排序的列。使用這種排序順序，Cassandra 支持切片查詢，在該查詢中，給定了一個行，用戶可以檢索屬于給定的列名稱范圍內的列的子集。例如，范圍 tag0 到 tag9999 內的切片查詢會獲得所有名稱范圍在 tag0 和 tag9999 內的列。

?列族：用一個名稱標記的行的集合。清單 2 顯示了樣例數據的可能形式：

清單 2. 列族示例

Books-{

"Foundation"-{author="Asimov", publishedDate=".."},

"Second Foundation"-{author="Asimov", publishedDate=".."},

…

}

人們常說列族就像是關系模型中的一個表格。如下例所示，相似點將不復存在。

?密鑰空間：許多列族共同形成的一個組。它只是列族的一個邏輯組合，并為名稱提供獨立的范圍。

最后，超級列位于一個列族中，該列族對一個密鑰下的多個列進行分組。正如開發人員不贊成使用超級列一樣，在此，我對此也不作任何討論。

Cassandra 與 RDBMS 數據模型

根據以上對 Cassandra 數據模型的描述，數據被放入每一個列族的二維 (2D) 空間中。要想在列族中檢索數據，用戶需要兩個密鑰：行名稱和列名稱。從這個意義上來說，盡管還存在多處至關重要的差異，關系模型和 Cassandra 仍然非常相似。

?關系列均勻分布在表中的所有行之間。數據項之間通常有明顯的縱向關系，但這種情況并不適用于 Cassandra 列。這就是 Cassandra 使用各個數據項（列）來存儲列名稱的原因。

?有了關系模型，2D 數據空間就完整了。2D 空間內的每一個點至少應當擁有存儲在此處的 null 值。另外，這種情況不適用于 Cassandra，Cassandra 可以擁有只包括少數項的行，而其他行可以擁有數百萬個項。

?有了關系模型，就可以對模式進行預定義，而且在運行時不可以更改模式，而 Cassandra 允許用戶在運行時更改模式。

?Cassandra 始終存儲數據，這樣就可以根據其名稱對列進行排序。這使得使用切片查詢在列中搜索數據變得很容易，但在行中搜索數據變得很困難，除非您使用的是保序分區程序。

?另一個重要差異是，RDMBS 中的列名稱表示與數據有關的元數據，但絕不是數據。而在 Cassandra 中，列名稱可以包括數據。因此，Cassandra 行可以擁有數百萬個列，而關系模型通常只有數十個列。

?關系模型使用定義良好的不可變模式來支持復雜的查詢，這些查詢中包括 JOIN 和聚合等。使用關系模型，用戶無需擔心查詢就可定義數據模式。Cassandra 不支持 JOIN 和大多數 SQL 搜索方法。因此，模式必須滿足應用程序的查詢要求。

聚簇索引和非聚簇索引的區別是什么

一、含義不同：

聚簇索引（Clustered Index）并不是一種單獨的索引類型，而是一種數據存儲方式。當表有了聚簇索引的時候，表的數據行都存放在索引樹的葉子頁中。

非聚簇索引（NoClustered Index），又叫二級索引。二級索引的葉子節點中保存的不是指向行的物理指針，而是行的主鍵值。

二、應用不同：

在《數據庫原理》里面，對聚簇索引的解釋是:聚簇索引的順序就是數據的物理存儲順序，而對非聚簇索引的解釋是:索引順序與數據物理排列順序無關。正式因為如此，所以一個表最多只能有一個聚簇索引。

在SQL Server中，索引是通過二叉樹的數據結構來描述的，我們可以這么理解聚簇索引：索引的葉節點就是數據節點。而非聚簇索引的葉節點仍然是索引節點，只不過有一個指針指向對應的數據塊。

擴展資料：

因為聚簇和非聚簇索引本質上是數據存儲方式，需要依賴于載體，即以InnoDB引起來講解聚簇索引，以MyISAM來講解非聚簇索引。下述講解的圖都引用自《高性能MySQL》。

它的每個聚簇索引的葉子節點都包含主鍵值、事務ID、回滾指針(用于事務和MVCC)以及余下的列。從物理文件也可以看出 InnoDB的數據文件只有數據結構文件.frm和數據文件.ibd?其中.ibd中存放的是數據和索引信息 是存放在一起的。

參考資料來源：百度百科-聚簇索引

mysql innodb 索引到底是b+樹還是b樹？

先從數據結構的角度來答。

題主應該知道B-樹和B+樹最重要的一個區別就是B+樹只有葉節點存放數據，其余節點用來索引，而B-樹是每個索引節點都會有Data域。

這就決定了B+樹更適合用來存儲外部數據，也就是所謂的磁盤數據。

從Mysql（Inoodb）的角度來看，B+樹是用來充當索引的，一般來說索引非常大，尤其是關系性數據庫這種數據量大的索引能達到億級別，所以為了減少內存的占用，索引也會被存儲在磁盤上。

那么Mysql如何衡量查詢效率呢？磁盤IO次數，B-樹（B類樹）的特定就是每層節點數目非常多，層數很少，目的就是為了就少磁盤IO次數，當查詢數據的時候，最好的情況就是很快找到目標索引，然后讀取數據，使用B+樹就能很好的完成這個目的，但是B-樹的每個節點都有data域（指針），這無疑增大了節點大小，說白了增加了磁盤IO次數（磁盤IO一次讀出的數據量大小是固定的，單個數據變大，每次讀出的就少，IO次數增多，一次IO多耗時?。。鳥+樹除了葉子節點其它節點并不存儲數據，節點小，磁盤IO次數就少。這是優點之一。

另一個優點是什么，B+樹所有的Data域在葉子節點，一般來說都會進行一個優化，就是將所有的葉子節點用指針串起來。這樣遍歷葉子節點就能獲得全部數據，這樣就能進行區間訪問啦。

至于MongoDB為什么使用B-樹而不是B+樹，可以從它的設計角度來考慮，它并不是傳統的關系性數據庫，而是以Json格式作為存儲的nosql，目的就是高性能，高可用，易擴展。首先它擺脫了關系模型，上面所述的優點2需求就沒那么強烈了，其次Mysql由于使用B+樹，數據都在葉節點上，每次查詢都需要訪問到葉節點，而MongoDB使用B-樹，所有節點都有Data域，只要找到指定索引就可以進行訪問，無疑單次查詢平均快于Mysql（但側面來看Mysql至少平均查詢耗時差不多）。

總體來說，Mysql選用B+樹和MongoDB選用B-樹還是以自己的需求來選擇的。

MySQL性能調優 – 你必須了解的15個重要變量

前言:

MYSQL 應該是最流行了 WEB 后端數據庫。雖然 NOSQL 最近越來越多的被提到，但是相信大部分架構師還是會選擇 MYSQL 來做數據存儲。本文作者總結梳理MySQL性能調優的15個重要變量，又不足需要補充的還望大佬指出。

1.DEFAULT_STORAGE_ENGINE

如果你已經在用MySQL 5.6或者5.7，并且你的數據表都是InnoDB，那么表示你已經設置好了。如果沒有，確保把你的表轉換為InnoDB并且設置default_storage_engine為InnoDB。

為什么？簡而言之，因為InnoDB是MySQL(包括Percona Server和MariaDB)最好的存儲引擎 – 它支持事務，高并發，有著非常好的性能表現(當配置正確時)。這里有詳細的版本介紹為什么

2.INNODB_BUFFER_POOL_SIZE

這個是InnoDB最重要變量。實際上，如果你的主要存儲引擎是InnoDB，那么對于你，這個變量對于MySQL是最重要的。

基本上，innodb_buffer_pool_size指定了MySQL應該分配給InnoDB緩沖池多少內存，InnoDB緩沖池用來存儲緩存的數據，二級索引，臟數據(已經被更改但沒有刷新到硬盤的數據)以及各種內部結構如自適應哈希索引。

根據經驗，在一個獨立的MySQL服務器應該分配給MySQL整個機器總內存的80%。如果你的MySQL運行在一個共享服務器，或者你想知道InnoDB緩沖池大小是否正確設置，詳細請看這里。

3.INNODB_LOG_FILE_SIZE

InnoDB重做日志文件的設置在MySQL社區也叫做事務日志。直到MySQL 5.6.8事務日志默認值innodb_log_file_size=5M是唯一最大的InnoDB性能殺手。從MySQL 5.6.8開始，默認值提升到48M,但對于許多稍繁忙的系統，還遠遠要低。

根據經驗，你應該設置的日志大小能在你服務器繁忙時能存儲1-2小時的寫入量。如果不想這么麻煩，那么設置1-2G的大小會讓你的性能有一個不錯的表現。這個變量也相當重要，更詳細的介紹請看這里。

當然，如果你有大量的大事務更改，那么，更改比默認innodb日志緩沖大小更大的值會對你的性能有一定的提高，但是你使用的是autocommit，或者你的事務更改小于幾k，那還是保持默認的值吧。

4.INNODB_FLUSH_LOG_AT_TRX_COMMIT

默認下，innodb_flush_log_at_trx_commit設置為1表示InnoDB在每次事務提交后立即刷新同步數據到硬盤。如果你使用autocommit，那么你的每一個INSERT, UPDATE或DELETE語句都是一個事務提交。

同步是一個昂貴的操作(特別是當你沒有寫回緩存時)，因為它涉及對硬盤的實際同步物理寫入。所以如果可能，并不建議使用默認值。

兩個可選的值是0和2:

* 0表示刷新到硬盤，但不同步(提交事務時沒有實際的IO操作)

* 2表示不刷新和不同步(也沒有實際的IO操作)

所以你如果設置它為0或2，則同步操作每秒執行一次。所以明顯的缺點是你可能會丟失上一秒的提交數據。具體來說，你的事務已經提交了，但服務器馬上斷電了，那么你的提交相當于沒有發生過。

顯示的，對于金融機構，如銀行，這是無法忍受的。不過對于大多數網站，可以設置為innodb_flush_log_at_trx_commit=0|2，即使服務器最終崩潰也沒有什么大問題。畢竟，僅僅在幾年前有許多網站還是用MyISAM，當崩潰時會丟失30s的數據(更不要提那令人抓狂的慢修復進程)。

那么，0和2之間的實際區別是什么？性能明顯的差異是可以忽略不計，因為刷新到操作系統緩存的操作是非?？斓?。所以很明顯應該設置為0，萬一MySQL崩潰(不是整個機器)，你不會丟失任何數據，因為數據已經在OS緩存，最終還是會同步到硬盤的。

5.SYNC_BINLOG

已經有大量的文檔寫到sync_binlog，以及它和innodb_flush_log_at_trx_commit的關系，下面我們來簡單的介紹下：

a) 如果你的服務器沒有設置從服務器，而且你不做備份，那么設置sync_binlog=0將對性能有好處。

b) 如果你有從服務器并且做備份，但你不介意當主服務器崩潰時在二進制日志丟失一些事件，那么為了更好的性能還是設置為sync_binlog=0.

c) 如果你有從服務器并且備份，你非常在意從服務器的一致性，以及能及時恢復到一個時間點(通過使用最新的一致性備份和二進制日志將數據庫恢復到特定時間點的能力)，那么你應該設置innodb_flush_log_at_trx_commit=1，并且需要認真考慮使用sync_binlog=1。

問題是sync_binlog=1代價比較高 – 現在每個事務也要同步一次到硬盤。你可能會想為什么不把兩次同步合并成一次，想法正確 – 新版本的MySQL(5.6和5.7，MariaDB和Percona Server)已經能合并提交，那么在這種情況下sync_binlog=1的操作也不是這么昂貴了，但在舊的mysql版本中仍然會對性能有很大影響。

6.INNODB_FLUSH_METHOD

將innodb_flush_method設置為O_DIRECT以避免雙重緩沖.唯一一種情況你不應該使用O_DIRECT是當你操作系統不支持時。但如果你運行的是Linux，使用O_DIRECT來激活直接IO。

不用直接IO，雙重緩沖將會發生，因為所有的數據庫更改首先會寫入到OS緩存然后才同步到硬盤 – 所以InnoDB緩沖池和OS緩存會同時持有一份相同的數據。特別是如果你的緩沖池限制為總內存的50%，那意味著在寫密集的環境中你可能會浪費高達50%的內存。如果沒有限制為50%，服務器可能由于OS緩存的高壓力會使用到swap。

簡單地說，設置為innodb_flush_method=O_DIRECT。

7.INNODB_BUFFER_POOL_INSTANCES

MySQL 5.5引入了緩沖實例作為減小內部鎖爭用來提高MySQL吞吐量的手段。

在5.5版本這個對提升吞吐量幫助很小，然后在MySQL 5.6版本這個提升就非常大了，所以在MySQL5.5中你可能會保守地設置innodb_buffer_pool_instances=4，在MySQL 5.6和5.7中你可以設置為8-16個緩沖池實例。

你設置后觀察會覺得性能提高不大，但在大多數高負載情況下，它應該會有不錯的表現。

對了，不要指望這個設置能減少你單個查詢的響應時間。這個是在高并發負載的服務器上才看得出區別。比如多個線程同時做許多事情。

8.INNODB_THREAD_CONCURRENCY

InnoDB有一種方法來控制并行執行的線程數 – 我們稱為并發控制機制。大部分是由innodb_thread_concurrency值來控制的。如果設置為0，并發控制就關閉了，因此InnoDB會立即處理所有進來的請求(盡可能多的)。

在你有32CPU核心且只有4個請求時會沒什么問題。不過想像下你只有4CPU核心和32個請求時 – 如果你讓32個請求同時處理，你這個自找麻煩。因為這些32個請求只有4 CPU核心，顯然地會比平常慢至少8倍(實際上是大于8倍)，而然這些請求每個都有自己的外部和內部鎖，這有很大可能堆積請求。

下面介紹如何更改這個變量，在mysql命令行提示符執行：

對于大多數工作負載和服務器，設置為8是一個好開端，然后你可以根據服務器達到了這個限制而資源使用率利用不足時逐漸增加?？梢酝ㄟ^show engine innodb status\G來查看目前查詢處理情況，查找類似如下行：

9.SKIP_NAME_RESOLVE

這一項不得不提及，因為仍然有很多人沒有添加這一項。你應該添加skip_name_resolve來避免連接時DNS解析。

大多數情況下你更改這個會沒有什么感覺，因為大多數情況下DNS服務器解析會非?？?。不過當DNS服務器失敗時，它會出現在你服務器上出現“unauthenticated connections” ，而就是為什么所有的請求都突然開始慢下來了。

所以不要等到這種事情發生才更改?，F在添加這個變量并且避免基于主機名的授權。

10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX

* innodb_io_capacity：用來當刷新臟數據時，控制MySQL每秒執行的寫IO量。

* innodb_io_capacity_max: 在壓力下，控制當刷新臟數據時MySQL每秒執行的寫IO量

首先，這與讀取無關 – SELECT查詢執行的操作。對于讀操作，MySQL會盡最大可能處理并返回結果。至于寫操作，MySQL在后臺會循環刷新，在每一個循環會檢查有多少數據需要刷新，并且不會用超過innodb_io_capacity指定的數來做刷新操作。這也包括更改緩沖區合并（在它們刷新到磁盤之前，更改緩沖區是輔助臟頁存儲的關鍵）。

第二，我需要解釋一下什么叫“在壓力下”，MySQL中稱為”緊急情況”，是當MySQL在后臺刷新時，它需要刷新一些數據為了讓新的寫操作進來。然后，MySQL會用到innodb_io_capacity_max。

那么，應該設置innodb_io_capacity和innodb_io_capacity_max為什么呢？

最好的方法是測量你的存儲設置的隨機寫吞吐量，然后給innodb_io_capacity_max設置為你的設備能達到的最大IOPS。innodb_io_capacity就設置為它的50-75%，特別是你的系統主要是寫操作時。

通常你可以預測你的系統的IOPS是多少。例如由8 15k硬盤組成的RAID10能做大約每秒1000隨機寫操作，所以你可以設置innodb_io_capacity=600和innodb_io_capacity_max=1000。許多廉價企業SSD可以做4,000-10,000 IOPS等。

這個值設置得不完美問題不大。但是，要注意默認的200和400會限制你的寫吞吐量，因此你可能偶爾會捕捉到刷新進程。如果出現這種情況，可能是已經達到你硬盤的寫IO吞吐量，或者這個值設置得太小限制了吞吐量。

11.INNODB_STATS_ON_METADATA

如果你跑的是MySQL 5.6或5.7，你不需要更改innodb_stats_on_metadata的默認值，因為它已經設置正確了。

不過在MySQL 5.5或5.1，強烈建議關閉這個變量 – 如果是開啟，像命令show table status會立即查詢INFORMATION_SCHEMA而不是等幾秒再執行，這會使用到額外的IO操作。

從5.1.32版本開始，這個是動態變量，意味著你不需要重啟MySQL服務器來關閉它。

12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN INNODB_BUFFER_POOL_LOAD_AT_STARTUP

innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup這兩個變量與性能無關，不過如果你偶爾重啟mysql服務器(如生效配置)，那么就有關。當兩個都激活時，MySQL緩沖池的內容(更具體地說，是緩存頁)在停止MySQL時存儲到一個文件。當你下次啟動MySQL時，它會在后臺啟動一個線程來加載緩沖池的內容以提高預熱速度到3-5倍。

兩件事：

第一，它實際上沒有在關閉時復制緩沖池內容到文件，僅僅是復制表空間ID和頁面ID – 足夠的信息來定位硬盤上的頁面了。然后它就能以大量的順序讀非?？焖俚募虞d那些頁面，而不是需要成千上萬的小隨機讀。

第二，啟動時是在后臺加載內容，因為MySQL不需要等到緩沖池內容加載完成再開始接受請求(所以看起來不會有什么影響)。

從MySQL 5.7.7開始，默認只有25%的緩沖池頁面在mysql關閉時存儲到文件，但是你可以控制這個值 – 使用innodb_buffer_pool_dump_pct，建議75-100。

這個特性從MySQL 5.6才開始支持。

13.INNODB_ADAPTIVE_HASH_INDEX_PARTS

如果你運行著一個大量SELECT查詢的MySQL服務器(并且已經盡可能優化)，那么自適應哈希索引將下你的下一個瓶頸。自適應哈希索引是InnoDB內部維護的動態索引，可以提高最常用的查詢模式的性能。這個特性可以重啟服務器關閉，不過默認下在mysql的所有版本開啟。

這個技術非常復雜，在大多數情況下它會對大多數類型的查詢直到加速的作用。不過，當你有太多的查詢往數據庫，在某一個點上它會花過多的時間等待AHI鎖和閂鎖。

如果你的是MySQL 5.7，沒有這個問題 – innodb_adaptive_hash_index_parts默認設置為8，所以自適應哈希索引被切割為8個分區，因為不存在全局互斥。

不過在mysql 5.7前的版本，沒有AHI分區數量的控制。換句話說，有一個全局互斥鎖來保護AHI，可能導致你的select查詢經常撞墻。

所以如果你運行的是5.1或5.6，并且有大量的select查詢，最簡單的方案就是切換成同一版本的Percona Server來激活AHI分區。

14.QUERY_CACHE_TYPE

如果人認為查詢緩存效果很好，肯定應該使用它。好吧，有時候是有用的。不過這個只在你在低負載時有用，特別是在低負載下大多數是讀取，小量寫或者沒有。

如果是那樣的情況，設置query_cache_type=ON和query_cache_size=256M就好了。不過記住不能把256M設置更高的值了，否則會由于查詢緩存失效時，導致引起嚴重的服務器停頓。

如果你的MySQL服務器高負載動作，建議設置query_cache_size=0和query_cache_type=OFF，并重啟服務器生效。那樣Mysql就會停止在所有的查詢使用查詢緩存互斥鎖。

15.TABLE_OPEN_CACHE_INSTANCES

從MySQL 5.6.6開始，表緩存能分割到多個分區。

表緩存用來存放目前已打開表的列表，當每一個表打開或關閉互斥體就被鎖定 – 即使這是一個隱式臨時表。使用多個分區絕對減少了潛在的爭用。

從MySQL 5.7.8開始，table_open_cache_instances=16是默認的配置。

歡迎做Java的工程師朋友們私信我資料免費獲取免費的Java架構學習資料（里面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）

其中覆蓋了互聯網的方方面面，期間碰到各種產品各種場景下的各種問題，很值得大家借鑒和學習，擴展自己的技術廣度和知識面。

網站題目：nosql二級索引,mysql 二級索引是什么
本文路徑：http://m.2m8n56k.cn/article38/hoihpp.html

成都網站建設公司_創新互聯，為您提供企業建站、云服務器、網站導航、域名注冊、響應式網站、小程序開發

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：[email protected]。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯