mysql緩存實例（mysql一級緩存）

本文目錄一覽：

• 1、使用mysql怎麼進行處理緩存的
• 2、mysql不用nosql怎麼緩存
• 3、MySQL性能調優 – 你必須了解的15個重要變量
• 4、如何使用redis做mysql的緩存

使用mysql怎麼進行處理緩存的

我們都知道 MySQL 的 Table Cache 是表定義的緩存，江湖上流傳着各種對這個參數的調優方法。

table cache 的作用，就是節約讀取表結構文件的開銷。對於table cache 是否命中，其實table cache 是針對於線程的，每個線程有自己的緩存，只緩存本線程的表結構定義。不過我們發現，strace 中沒有關於表結構文件的 open 操作（只有 stat 操作，定位表結構文件是否存在），也就是說 table cache 不命中，不一定需要讀取表結構文件。這種感覺好像是：在不命中 table cache 時，命中了另外一個表結構緩存。

運維建議：

我們讀一下 MySQL 的文檔，關於 table_open_cache 的建議值公式：建議值 = 最大並發數 * join 語句涉及的表的最大個數。

通過實驗我們容易理解：table_cache 是針對於線程的，所以需要最大並發數個緩存。另外，一個語句 join 涉及的表，需要同時在緩存中存在。所以最小的緩存大小，等於語句 join 涉及的表的最大個數。將這兩個數相乘，就得到了 MySQL 的建議值公式。

mysql不用nosql怎麼緩存

有兩種方法，一種方法使用mysql的check table和repair table 的sql語句，另一種方法是使用MySQL提供的多個myisamchk, isamchk數據檢測恢復工具。前者使用起來比較簡便。推薦使用。

1. check table 和 repair table

登陸mysql 終端：

mysql -uxxxxx -p dbname

check table tabTest;

如果出現的結果說Status是OK，則不用修復，如果有Error，可以用：

repair table tabTest;

進行修復，修復之後可以在用check table命令來進行檢查。在新版本的phpMyAdmin裏面也可以使用check/repair的功能。

2. myisamchk, isamchk

其中myisamchk適用於MYISAM類型的數據表，而isamchk適用於ISAM類型的數據表。這兩條命令的主要參數相同，一般新的系統都使用MYISAM作為缺省的數據表類型，這裡以myisamchk為例子進行說明。當發現某個數據表出現問題時可以使用：

myisamchk tablename.MYI

進行檢測，如果需要修復的話，可以使用：

myisamchk -of tablename.MYI

關於myisamchk的詳細參數說明，可以參見它的使用幫助。需要注意的時在進行修改時必須確保MySQL服務器沒有訪問這個數據表，保險的情況下是最好在進行檢測時把MySQL服務器Shutdown掉。

另外可以把下面的命令放在你的rc.local裏面啟動MySQL服務器前：

[ -x /tmp/mysql.sock ] /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI

其中的/tmp/mysql.sock是MySQL監聽的Sock文件位置，對於使用RPM安裝的用戶應該是/var/lib/mysql/mysql.sock，對於使用源碼安裝則是/tmp/mysql.sock可以根據自己的實際情況進行變更，而pathtochk則是myisamchk所在的位置，DATA_DIR是你的MySQL數據庫存放的位置。

需要注意的時，如果你打算把這條命令放在你的rc.local裏面，必須確認在執行這條指令時MySQL服務器必須沒有啟動！檢測修復所有數據庫(表)

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」 ，而就是為什麼所有的請求都突然開始慢下來了。

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

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 – 足夠的信息來定位硬盤上的頁面了。然後它就能以大量的順序讀非常快速的加載那些頁面，而不是需要成千上萬的小隨機讀。

第二，啟動時是在後台加載內容，因為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等多個知識點的架構資料）

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

如何使用redis做mysql的緩存

1，redis是一種內存性的數據存儲服務，所以它的速度要比mysql快。

2，redis只支持String,hashmap,set,sortedset等基本數據類型，但是不支持聯合查詢，所以它適合做緩存。

3，有時候緩存的數據量非常大，如果這個時候服務宕機了，且開啟了redis的持久化功能，重新啟動服務，數據基本上不會丟。

4，redis可以做內存共享，因為它可以被多個不同的客戶端連接。

5，做為mysql等數據庫的緩存，是把部分熱點數據先存儲到redis中，或第一次用的時候加載到redis中，下次再用的時候，直接從redis中取。

6，redis中的數據可以設置過期時間expire，如果這個數據在一定時間內沒有被延長這個時間，那個一定時間之後這個數據就會從redis清除。

所以，redis只是用來緩存數據庫中經常被訪問的數據，可以增加訪問速度和並發量。而mysql只是提供一種數據備份和數據源的作用。