MySQL查詢緩存的小知識
前言
我們知道,緩存的設(shè)計(jì)思想在RDBMS數(shù)據(jù)庫中無處不在,就拿號稱2500w行代碼,bug堆積如山的Oracle數(shù)據(jù)庫來說,SQL的執(zhí)行計(jì)劃可以緩存在library cache中避免再次執(zhí)行相同SQL發(fā)生硬解析(語法分析->語義分析->生成執(zhí)行計(jì)劃),SQL執(zhí)行結(jié)果緩存在RESULT CACHE內(nèi)存組件中,有效的將物理IO轉(zhuǎn)化成邏輯IO,提高SQL執(zhí)行效率。
MySQL的QueryCache跟Oracle類似,緩存的是SQL語句文本以及對應(yīng)的結(jié)果集,看起來是一個(gè)很棒的Idea,那為什么從MySQL 4.0推出之后,5.6中默認(rèn)禁用,5.7中被deprecated(廢棄)以及8.0版本被Removed,今天就聊聊MySQL QueryCache的前世今生。
QueryCache介紹
MySQL查詢緩(QC:QueryCache)在MySQL 4.0.1中引入,查詢緩存存儲(chǔ)SELECT語句的文本以及發(fā)送給客戶機(jī)的結(jié)果集,如果再次執(zhí)行相同的SQL,Server端將從查詢緩存中檢索結(jié)果返回給客戶端,而不是再次解析執(zhí)行SQL,查詢緩存在session之間共享,因此,一個(gè)客戶端生成的緩存結(jié)果集,可以響應(yīng)另一個(gè)客戶端執(zhí)行同樣的SQL。
回到開頭的問題,如何判斷SQL是否共享?
通過SQL文本是否完全一致來判斷,包括大小寫,空格等所有字符完全一模一樣才可以共享,共享好處是可以避免硬解析,直接從QC獲取結(jié)果返回給客戶端,下面的兩個(gè)SQL是不共享滴,因?yàn)橐粋€(gè)是from,另一個(gè)是From。
--SQL 1 select id, balance from account where id = 121; --SQL 2 select id, balance From account where id = 121;
下面是Oracle數(shù)據(jù)庫通過SQL_TEXT生成sql_id的算法,如果sql_id不一樣說明就不是同一個(gè)SQL,就不共享,就會(huì)發(fā)生硬解析。
#!/usr/bin/perl -w use Digest::MD5 qw(md5 md5_hex md5_base64); use Math::BigInt; my $stmt = "select id, balance from account where id = 121\0"; my $hash = md5 $stmt; my($a,$b,$msb,$lsb) = unpack("V*",$hash); my $sqln = $msb*(2**32)+$lsb; my $stop = log($sqln) / log(32) + 1; my $sqlid = ''; my $charbase32 = '0123456789abcdfghjkmnpqrstuvwxyz'; my @chars = split '', $charbase32; for($i=0; $i < $stop-1; $i++){ my $x = Math::BigInt->new($sqln); my $seq = $x->bdiv(32**$i)->bmod(32); $sqlid = $chars[$seq].$sqlid; } print "SQL is:\n $stmt \nSQL_ID is\n $sqlid\n";
大家可以發(fā)現(xiàn)SQL 1和SQL 2通過代碼生成的sql_id值是不一樣,所以不共享。
SQL is: select id, balance from account where id = 121 SQL_ID is dm5c6ck1g7bds SQL is: select id, balance From account where id = 121 SQL_ID is 6xb8gvs5cmc9b
如果讓你比較兩個(gè)Java代碼文件的內(nèi)容的有何差異,只需要將這段代碼理解透了,就可以改造實(shí)現(xiàn)自己的業(yè)務(wù)邏輯。
QueryCache配置
mysql> show variables like '%query_cache%'; +------------------------------+----------+ | Variable_name | Value | +------------------------------+----------+ | have_query_cache | YES | | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 16777216 | | query_cache_type | OFF | | query_cache_wlock_invalidate | OFF |
Variable_name | Description |
---|---|
have_query_cache | 查詢緩存是否可用,YES-可用;NO-不可用,如果用標(biāo)準(zhǔn)二進(jìn)制MySQL,值總是YES。 |
query_cache_limit | 控制單個(gè)查詢結(jié)果集的最大尺寸,默認(rèn)是1MB。 |
query_cache_min_res_unit | 查詢緩存分片數(shù)據(jù)塊的大小,默認(rèn)是4KB,可以滿足大部分業(yè)務(wù)場景。 |
query_cache_size | 查詢緩存大小,單位Bytes,設(shè)置為0是禁用QueryCache,注意:不要將緩存的大小設(shè)置得太大,由于在更新過程中需要線程鎖定QueryCache,因此對于非常大的緩存,您可能會(huì)看到鎖爭用問題。 |
query_cache_type | 當(dāng)query_cache_size>0;該變量影響qc如何工作,有三個(gè)取值0,1,2,0:禁止緩存或檢索緩存結(jié)果;1:啟用緩存,SELECT SQL_NO_CACHE的語句除外;2:只緩存以SELECT SQL_CACHE開頭的語句。 |
query_cache_min_res_unit說明
默認(rèn)大小是4KB,如果有很多查詢結(jié)果很小,那么默認(rèn)數(shù)據(jù)塊大小可能會(huì)導(dǎo)致內(nèi)存碎片,由于內(nèi)存不足,碎片可能會(huì)強(qiáng)制查詢緩存從緩存中刪除查詢。
在這種情況下,可以減小query_cache_min_res_unit的值,由于修剪而刪除的空閑塊和查詢的數(shù)量由Qcache_free_blocks和Qcache_lowmem_prunes狀態(tài)變量的值給出,如果大量的查詢有較大的結(jié)果集,可以增大該參數(shù)的值來提高性能。
通常開啟QueryCache方式
# 修改MySQL配置文件/etc/my.cnf,添加如下配置,重啟MySQL server即可。 [mysqld] query_cache_size = 32M query_cache_type = 1
QueryCache使用
先搞點(diǎn)測試數(shù)據(jù),分別對禁用和開啟QueryCache下的場景進(jìn)行測試。
--創(chuàng)建一個(gè)用戶表users,并且插入100w數(shù)據(jù)。 CREATE TABLE `users` ( `id` bigint NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL DEFAULT '' COMMENT '姓名', `age` tinyint NOT NULL DEFAULT '0' COMMENT 'age', `gender` char(1) NOT NULL DEFAULT 'M' COMMENT '性別', `phone` varchar(16) NOT NULL DEFAULT '' COMMENT '手機(jī)號', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創(chuàng)建時(shí)間', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改時(shí)間', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用戶信息表'; select count(*) from users; +----------+ | count(*) | +----------+ | 1000000 |
禁用queryCache場景
在不使用QueryCache的時(shí)候,每次執(zhí)行相同的查詢語句,都要發(fā)生一次硬解析,消耗大量的資源。
#禁用QueryCache的配置 query_cache_size = 0 query_cache_type = 0
重復(fù)執(zhí)行下面查詢,觀察執(zhí)行時(shí)間。
--第一次執(zhí)行查詢語句 mysql> select * from users order by create_time desc limit 10; +---------+------------+-----+--------+-------------+---------------------+---------------------+ | id | name | age | gender | phone | create_time | update_time | +---------+------------+-----+--------+-------------+---------------------+---------------------+ | 997855 | User997854 | 54 | M | 15240540354 | 2020-12-15 14:34:50 | 2020-12-15 14:34:50 | ....... 10 rows in set (0.89 sec) --第二次執(zhí)行同樣的查詢語句 mysql> select * from users order by create_time desc limit 10; +---------+------------+-----+--------+-------------+---------------------+---------------------+ | id | name | age | gender | phone | create_time | update_time | +---------+------------+-----+--------+-------------+---------------------+---------------------+ | 997855 | User997854 | 54 | M | 15240540354 | 2020-12-15 14:34:50 | 2020-12-15 14:34:50 | ....... 10 rows in set (0.90 sec) -- profile跟蹤情況 mysql> show profile cpu,block io for query 1; +----------------------+----------+----------+------------+--------------+---------------+ | Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | +----------------------+----------+----------+------------+--------------+---------------+ | preparing | 0.000022 | 0.000017 | 0.000004 | 0 | 0 | | Sorting result | 0.000014 | 0.000009 | 0.000005 | 0 | 0 | | executing | 0.000011 | 0.000007 | 0.000004 | 0 | 0 | | Sending data | 0.000021 | 0.000016 | 0.000004 | 0 | 0 | | Creating sort index | 0.906290 | 0.826584 | 0.000000 | 0 | 0 |
可以看到,多次執(zhí)行同樣的SQL查詢語句,執(zhí)行時(shí)間都是0.89s左右,幾乎沒有差別,同時(shí)時(shí)間主要消耗在Creating sort index階段。
開啟queryCache場景
開啟查詢緩存時(shí),查詢語句第一次被執(zhí)行時(shí)會(huì)將SQL文本及查詢結(jié)果緩存在QC中,下一次執(zhí)行同樣的SQL執(zhí)行從QC中獲取數(shù)據(jù)返回給客戶端即可。
#禁用QueryCache的配置 query_cache_size = 32M query_cache_type = 1
--第一次執(zhí)行查詢語句 mysql> select * from users order by create_time desc limit 10; +---------+------------+-----+--------+-------------+---------------------+---------------------+ | id | name | age | gender | phone | create_time | update_time | +---------+------------+-----+--------+-------------+---------------------+---------------------+ | 997855 | User997854 | 54 | M | 15240540354 | 2020-12-15 14:34:50 | 2020-12-15 14:34:50 | ....... 10 rows in set (0.89 sec) --第二次執(zhí)行查詢語句 mysql> select * from users order by create_time desc limit 10; +---------+------------+-----+--------+-------------+---------------------+---------------------+ | id | name | age | gender | phone | create_time | update_time | +---------+------------+-----+--------+-------------+---------------------+---------------------+ | 997855 | User997854 | 54 | M | 15240540354 | 2020-12-15 14:34:50 | 2020-12-15 14:34:50 | ....... 10 rows in set (0.00 sec) -- profile跟蹤數(shù)據(jù) mysql> show profile cpu,block io for query 3; +--------------------------------+----------+----------+------------+--------------+---------------+ | Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | +--------------------------------+----------+----------+------------+--------------+---------------+ | Waiting for query cache lock | 0.000016 | 0.000015 | 0.000001 | 0 | 0 | | checking query cache for query | 0.000007 | 0.000007 | 0.000000 | 0 | 0 | | checking privileges on cached | 0.000004 | 0.000003 | 0.000000 | 0 | 0 | | checking permissions | 0.000034 | 0.000033 | 0.000001 | 0 | 0 | | sending cached result to clien | 0.000018 | 0.000017 | 0.000001 | 0 | 0 |
可以看到,第一次執(zhí)行QueryCache里沒有緩存SQL文本及數(shù)據(jù),執(zhí)行時(shí)間0.89s,由于開啟了QC,SQL文本及執(zhí)行結(jié)果被緩存在QC中,第二次執(zhí)行執(zhí)行同樣的SQL查詢語句,直接命中QC且返回?cái)?shù)據(jù),不需要發(fā)生硬解析,所以執(zhí)行時(shí)間降低為0s,從profile里看到sending cached result to client直接發(fā)送QC中的數(shù)據(jù)返回給客戶端。
查詢緩存命中率
查詢緩存相關(guān)的status變量
mysql>SHOW GLOBAL STATUS LIKE 'QCache\_%'; +-------------------------+----------+ | Variable_name | Value | +-------------------------+----------+ | Qcache_free_blocks | 1 | --查詢緩存中可用內(nèi)存塊的數(shù)目。 | Qcache_free_memory | 33268592 | --查詢緩存的可用內(nèi)存量。 | Qcache_hits | 121 | --從QC中獲取結(jié)果集的次數(shù)。 | Qcache_inserts | 91 | --將查詢結(jié)果集添加到QC的次數(shù),意味著查詢已經(jīng)不在QC中。 | Qcache_lowmem_prunes | 0 | --由于內(nèi)存不足而從查詢緩存中刪除的查詢數(shù)。 | Qcache_not_cached | 0 | --未緩存的查詢數(shù)目。 | Qcache_queries_in_cache | 106 | --在查詢緩存中注冊的查詢數(shù)。 | Qcache_total_blocks | 256 | --查詢緩存中的塊總數(shù)。
查詢緩存命中率及平均大小
Qcache_hits Query cache hit rate = ------------------------------------------------ x 100% Qcache_hits + Qcache_inserts + Qcache_not_cached query_cache_size = Qcache_free_memory Query Cache Avg Query Size = --------------------------------------- Qcache_queries_in_cache
更新操作對QC影響
舉個(gè)例子,支付系統(tǒng)的里轉(zhuǎn)賬邏輯,先要鎖定賬戶再修改余額,主要步驟如下:
Query_ID | Query | Description |
1 | reset query cache | 清空查詢緩存。 |
2 | select balance from account where id = 121 | 第一次執(zhí)行,未命中QC,添加到QC。 |
3 | select balance from account where id = 121 | 命中QC,直接返回結(jié)果。 |
4 | update account set balance = balance - 1000 where id = 121 | 更新,鎖定query cche進(jìn)行更新,緩存數(shù)據(jù)失效。 |
5 | select balance from account where id = 121 | 緩存已失效,未命中,添加到QC。 |
6 | select balance from account where id = 121 | 命中QC,直接返回結(jié)果。 |
為何放棄QueryCache
一般業(yè)務(wù)場景
適合QueryCache的場景
首先,查詢緩存QC的大小只有幾MB,不適合將緩存設(shè)置得太大,由于在更新過程中需要線程鎖定QueryCache,因此對于非常大的緩存,可能會(huì)看到鎖爭用問題。那么,哪些情況有助于從查詢緩存中獲益呢?以下是理想條件:
- 相同的查詢是由相同或多個(gè)客戶機(jī)重復(fù)發(fā)出的。
- 被訪問的底層數(shù)據(jù)本質(zhì)上是靜態(tài)或半靜態(tài)的。
- 查詢有可能是資源密集型和/或構(gòu)建簡短但計(jì)算復(fù)雜的結(jié)果集,同時(shí)結(jié)果集比較小。
- 并發(fā)性和查詢QPS都不高。
這4種情況只是理想情況下,實(shí)際的業(yè)務(wù)系統(tǒng)都是有CRUD操作的,數(shù)據(jù)更新比較頻繁,查詢接口的QPS比較高,所以能滿足上面的理想情況下的業(yè)務(wù)場景實(shí)在很少,我能想到就是配置表,數(shù)據(jù)字典表這些基本都是靜態(tài)或半靜態(tài)的,可以時(shí)通過QC來提高查詢效率。
不適合QueryCache的場景
如果表數(shù)據(jù)變化很快,則查詢緩存將失效,并且由于不斷從緩存中刪除查詢,從而使服務(wù)器負(fù)載升高,處理速度變得更慢,如果數(shù)據(jù)每隔幾秒鐘更新一次或更加頻繁,則查詢緩存不太可能合適。
同時(shí),查詢緩存使用單個(gè)互斥體來控制對緩存的訪問,實(shí)際上是給服務(wù)器SQL處理引擎強(qiáng)加了一個(gè)單線程網(wǎng)關(guān),在查詢QPS比較高的情況下,可能成為一個(gè)性能瓶頸,會(huì)嚴(yán)重降低查詢的處理速度。因此,MySQL 5.6中默認(rèn)禁用了查詢緩存。
刪除QueryCache
The query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0. Deprecation includes query_cache_type,可以看到從MySQL 5.6的默認(rèn)禁用,5.7的廢棄以及8.0的徹底刪除,Oracle也是綜合了各方面考慮做出了這樣的選擇。
上面聊了下適合和不適合的QueryCache的業(yè)務(wù)場景,發(fā)現(xiàn)這個(gè)特性對業(yè)務(wù)場景要求過于苛刻,與實(shí)際業(yè)務(wù)很難吻合,而且開啟之后,對數(shù)據(jù)庫并發(fā)度和處理能力都會(huì)降低很多,下面總結(jié)下為何MySQL從Disabled->Deprecated->Removed QueryCache的主要原因。
同時(shí)查詢緩存碎片化還會(huì)導(dǎo)致服務(wù)器的負(fù)載升高,影響數(shù)據(jù)庫的穩(wěn)定性,在Oracle官方搜索QueryCache可以發(fā)現(xiàn),有很多Bug存在,這也就決定了MySQL 8.0直接果斷的Remove了該特性。
總結(jié)
上面為大家介紹了MySQL QueryCache從推出->禁用->廢棄->刪除的心路歷程,設(shè)計(jì)之初是為了減少重復(fù)SQL查詢帶來的硬解析開銷,同時(shí)將物理IO轉(zhuǎn)化為邏輯IO,來提高SQL的執(zhí)行效率,但是MySQL經(jīng)過了多個(gè)版本的迭代,同時(shí)在硬件存儲(chǔ)發(fā)展之快的今天,QC幾乎沒有任何收益,而且還會(huì)降低數(shù)據(jù)庫并發(fā)處理能力,最終在8.0版本直接Removd掉了。
其實(shí)緩存設(shè)計(jì)思想在硬件和軟件領(lǐng)域無處不在,硬件方面:RAID卡,CPU都有自己緩存,軟件方面就太多了,OS的cache,數(shù)據(jù)庫的buffer pool以及Java程序的緩存,作為一名研發(fā)工程師,需要根據(jù)業(yè)務(wù)場景選擇合適緩存方案是非常重要的,如果都不合適,就需進(jìn)行定制化開發(fā)緩存,來更好的Match自己的業(yè)務(wù)場景,今天就聊這么多,希望對大家有所幫助。
我是敖丙,你知道的越多,你不知道的越多,感謝各位人才的:點(diǎn)贊、收藏和評論,我們下期見!
以上就是MySQL查詢緩存的小知識的詳細(xì)內(nèi)容,更多關(guān)于MySQL查詢緩存的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
MySQL用作備份還原的導(dǎo)入和導(dǎo)出命令用法整理
這篇文章主要介紹了MySQL用作備份還原的導(dǎo)入和導(dǎo)出命令用法整理,包括mysqldump的命令的使用以及l(fā)oad data相關(guān)命令,需要的朋友可以參考下2015-12-12MYSQL隨機(jī)抽取查詢 MySQL Order By Rand()效率問題
MYSQL隨機(jī)抽取查詢:MySQL Order By Rand()效率問題一直是開發(fā)人員的常見問題,俺們不是DBA,沒有那么牛B,所只能慢慢研究咯,最近由于項(xiàng)目問題,需要大概研究了一下MYSQL的隨機(jī)抽取實(shí)現(xiàn)方法2011-11-11一文徹底搞懂MySQL?TimeStamp時(shí)區(qū)問題
MySQL的timestamp類型默認(rèn)使用的是服務(wù)器的時(shí)區(qū)來存儲(chǔ)時(shí)間值,這意味著如果服務(wù)器的時(shí)區(qū)發(fā)生了變化,那么存儲(chǔ)的timestamp值也會(huì)發(fā)生變化,下面這篇文章主要給大家介紹了關(guān)于如何通過一文徹底搞懂MySQL?TimeStamp時(shí)區(qū)問題的相關(guān)資料,需要的朋友可以參考下2024-01-01虛擬主機(jī)MySQL數(shù)據(jù)庫的備份與還原的方法
虛擬主機(jī)MySQL數(shù)據(jù)庫的備份與還原的方法...2007-07-07