MySQL的FLUSH可以清理mysql資料庫緩存數據
MySQL的FLUSH句法(清除或者重新載入內部緩存） FLUSH flush_option [,flush_option]，如果你想要清除一些MySQL使用內部緩存，你應該使用FLUSH命令。為了執行FLUSH，你必須有reload許可權。
flush_option 可以是下列任何東西：
HOSTS 這個用的最多，經常碰見。主要是用來清空主機緩存表。如果你的某些主機改變IP數字，或如果你得到錯誤消息Host ... isblocked，你應該清空主機表。當在連接MySQL伺服器時，對一台給定的主機有多於 max_connect_errors個錯誤連續不斷地發生，MySQL為了安全的需要將會阻止該主機進一步的連接請求。清空主機表允許主機再嘗試連接。
LOGS 關閉當前的二進制日誌文件並創建一個新文件，新的二進制日誌文件的名字在當前的二進制文件的編號上加1。
PRIVILEGES 這個也是經常使用的，每當重新賦權後，為了以防萬一，讓新許可權立即生效，一般都執行一把，目地是從資料庫授權表中重新裝載許可權到緩存中。
TABLES 關閉所有打開的表，同時該操作將會清空查詢緩存中的內容。
FLUSH TABLES WITH READ LOCK 關閉所有打開的表，同時對於所有資料庫中的表都加一個讀鎖，直到顯示地執行unlock tables，該操作常常用於數據備份的時候。解鎖的語句就是unlock tables。
FLUSH TABLES WITH READ LOCK對於資料庫是全局的表鎖定，如果只想鎖定幾個表，可以用LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} 。這個命令同樣需要unlock tables來解鎖。
read-lock: 允許其他並發的讀請求，但阻塞寫請求，即可以同時讀，但不允許任何寫。也叫共享鎖。write-lock: 不允許其他並發的讀和寫請求，是排他的(exclusive)。也叫獨占鎖
STATUS 重置大多數狀態變數到0。
MASTER 刪除所有的二進制日誌索引文件中的二進制日誌文件，重置二進制日誌文件的索引文件為空，創建一個新的二進制日誌文件,不過這個已經不推薦使用，改成reset master 了。可以想像，以前自己是多土啊，本來一條簡單的命令就可以搞定的，卻要好幾條命令來，以前的做法是先查出來當前的二進制日誌文件名，再用purge 操作。
QUERY CACHE 重整查詢緩存，消除其中的碎片，提高性能，但是並不影響查詢緩存中現有的數據，這點和Flush table 和Reset Query Cache（將會清空查詢緩存的內容）不一樣的。
SLAVE 類似於重置復制吧，讓從資料庫忘記主資料庫的復制位置，同時也會刪除已經下載下來的relay log,與Master一樣，已經不推薦使用，改成Reset Slave了。這個也很有用的。
一般來講，Flush操作都會記錄在二進制日誌文件中，但是FLUSH LOGS、FLUSH MASTER、FLUSH SLAVE、FLUSH TABLES WITH READ LOCK不會記錄，因此上述操作如果記錄在二進制日誌文件中話，會對從資料庫造成影響。
❷ 如何清理mysql資料庫緩存數據
1、打開mysql的客戶端 這里使用navicat，連接資料庫，等到navicat主頁面，雙擊需要操作的資料庫連接。
❸ MySQL表對象緩存
表對象緩存： 是將某個表對象的字典信息（定義內容）緩存到內存中，用來提高對表的訪問效率。某個表被訪問過一次後，只要伺服器沒有關閉且表定義沒有被修改的條件下，訪問該表，只需要從內存中找到這個已經緩存起來的對象做相應操作即可。
用戶訪問表時，表對象在緩存時： 通過HASH演算法找到TABLE_SHARE，然後每個線程構造各自的實例化TABLE即可。
用戶訪問表時，當表沒有被緩存的情況下： 第一需要打開表，首先需要從系統表中將這個表的所有信息都讀入內存中，這些信息包括表名、庫名、所有列信息、列的默認值、表的字元集、對應的frm文件路徑、所屬存儲引擎、主鍵等，將這些信息構造一個TABLE_SHARE結構體，這個結構體是表對象緩存的第一層，所有用戶共享訪問且為靜態不允許修改，它是緩存在table_def_cache（由參數table_definition_cache控制）中的。
而真正與用戶打交道的是TABLE_SHARE的衍生品，它對應結構體為TABLE，在被使用前需要將TABLE_SHARE結構體實例化TABLE才能被使用，由每個線程構造各自的實例化TABLE即可。（實例化的TABLE由table_open_cache及table_open_cache_instance控制）
注意1： DDL操作時會將所有instance鎖住，而DML操作時instance之間互不幹擾。
(DDL statements still require a lock on the entire cache, but such statements are much less frequent than DML statements.)
注意2： 一個線程中如果打開表過多，超過一個instance限制的大小時，是不能跨instance緩存的
(instance大小：table_open_cache / table_open_cache_instances)
表緩存涉及其他參數： 通過下面參數判斷table_open_cache參數設置是否合理
table_open_cache_hit：能夠從table open cache的free list中找到table則為命中，+1
table_open_cache_misses：與table_open_cache_hit相反，如果找不到則需要重新實例化則+1，通常發生在初始化第一次載入表或超過table_open_cache的設置被淘汰後需要重新實例化。
table_open_cache_overflow：table cache淘汰的數量，每次淘汰+1
opened_tables:已經打開的表數。如果Opened_tables很大，那麼table_open_cache的值可能太小了。
open_tables：總的instance (table cache)的總數
❹ mysql調優技巧 增加線程緩存大小
增加線程緩存大小
連接管理器線程處理伺服器監聽的網路介面上的客戶端連接請求。連接管理器線程將每個客戶端連接與專用於它的線程關聯，該線程負責處理該連接的身份驗證和所有請求處理。因此，線程和當前連接的客戶端之間是一對一的比例。確保線程緩存足夠大以容納所有傳入請求是非常重要的。
MySQL提供了許多與連接線程相關的伺服器變數：
線程緩存大小由thread_cache_size系統變數決定。默認值為0（無緩存），這將導致為每個新連接設置一個線程，並在連接終止時需要處理該線程。如果希望伺服器每秒接收數百個連接請求，那麼應該將thread_cache_size設置的足夠高，以便大多數新連接可以使用緩存線程。可以在伺服器啟動或運行時設置max_connections的值。
還應該監視緩存中的線程數（Threads_cached）以及創建了多少個線程，因為無法從緩存中獲取線程（Threads_created）。關於後者，如果Threads_created繼續以每分鍾多於幾個線程的增加，請考慮增加thread_cache_size的值。
使用MySQL show status命令顯示MySQL的變數和狀態信息。這里有幾個例子：
Monyog線程緩存監測
Monyog提供了一個監控線程緩存的屏幕，名為「線程」。與MySQL線程相關的伺服器變數映射到以下Monyog指標：
Monyog線程屏幕還包括「線程緩存命中率」指標。這是一個提示線程緩存命中率的指標。如果值較低，則應該考慮增加線程緩存。在狀態欄以百分比形式顯示該值；它的值越接近100％越好。
如果這些指標的值等於或超過指定值，則可以將每一個指標配置為發出警告和/或嚴重警報
❺ 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 statusG來查看目前查詢處理情況，查找類似如下行：
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_mp_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_mp_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的緩存
redis緩存其實就是把經常訪問的數據放到redis裡面，用戶查詢的時候先去redis查詢，沒有查到就執行sql語句查詢，同時把數據同步到redis裡面。redis只做讀操作，在內存中查詢速度快。
使用redis做緩存必須解決兩個問題，首先就是確定用何種數據結構存儲來自mysql的數據；確定數據結構之後就是需要確定用什麼標識來作為數據的key。
mysql是按照表存儲數據的，這些表是由若干行組成。每一次執行select查詢，mysql都會返回一個結果集，這個結果是由若干行組成的。redis有五種數據結構：列表list，哈希hash，字元串string，集合set，sorted set(有序集合)，對比幾種數據結構，string和hash是比較適合存儲行的數據結構，可以把數據轉成json字元串存入redis。
全量遍歷鍵： keys pattern keys *
有人說 KEYS 相當於關系性數據的庫的 select * ，在生產環境幾乎是要禁用的
不管上面說的對不對， keys 肯定是有風險的。那我們就換一種方案，在存數據的時候。把數據的鍵存一下，也存到redis裡面選hash類型，那麼取的時候就可以直接通過這個hash獲取所有的值，自我感覺非常好用！
❼ mysql緩存如何使用
應用redis實現數據的讀寫，同時利用隊列處理器定時將數據寫入mysql。
同時要注意避免沖突，在redis啟動時去mysql讀取所有表鍵值存入redis中，往redis寫數據時，對redis主鍵自增並進行讀取，若mysql更新失敗，則需要及時清除緩存及同步redis主鍵。
這樣處理，主要是實時讀寫redis，而mysql數據則通過隊列非同步處理，緩解mysql壓力，不過這種方法應用場景主要基於高並發，而且redis的高可用集群架構相對更復雜，一般不是很推薦。
❽ MySQL的緩存對象有什麼
1）只緩存SELECT語句。SHOW命令和存儲程序不會被緩存。
2）不能緩存預編譯語句（prepared statement）和游標。查詢緩存中保存的是查詢語句和結果集，而預編譯語句中存在替代符和額外的參數，游標從塊中讀取結果，因此上述兩種情況不能被緩存。
3）查詢語句不能包含動態內容。多次執行某SQL，必須能夠返回相同的結果集，因此查詢中不能包含像UUID(), RAND(), CONNECTION_ID()這樣的函數。
4）SQL中包含定義函數和自定義變數不會被緩存。
Mysql> set @id=1;
Mysql> select * from test where id=@id 像這種語句也不會緩存
5）對系統表的查詢不會被緩存。
Mysql> select * from mysql.user where user=』root』
6）非自動提交（顯示使用BEGIN…END）事務中的SQL不會被緩存。
7）使用TEMPORARY表的SQL不會被緩存。
8）不使用任何錶的SQL不會被緩存。
Mysql> select @id;
9）在下面的SELECT操作也不會被緩存：
SELECT ...IN SHARE MODE
SELECT ...FOR UPDATE
SELECT ...INTO OUTFILE ...
SELECT ...INTO DUMPFILE ...
SELECT * FROM ...WHERE autoincrement_col IS NULL
❾ mysql 一級緩存和二級緩存的區別
一、Session緩存（又稱作事務緩存）：Hibernate內置的，不能卸除。
緩存范圍：緩存只能被當前Session對象訪問。緩存的生命周期依賴於Session的生命周期，當Session被關閉後，緩存也就結束生命周期。
Hibernate一些與一級緩存相關的操作（時間點）：
數據放入緩存：
1. save()。當session對象調用save()方法保存一個對象後，該對象會被放入到session的緩存中。
2. get()和load()。當session對象調用get()或load()方法從資料庫取出一個對象後，該對象也會被放入到session的緩存中。
3. 使用HQL和QBC等從資料庫中查詢數據。
二、SessionFactory緩存（又稱作應用緩存）：使用第三方插件，可插拔。
❿ 使用mysql怎麼進行處理緩存的
如果資料庫是安裝在你機器上的 那麼你可以暫時把MYSQL關閉 然後進入安裝目錄 找到data文件夾 這裡面就是放置資料庫文件的。。你會看到data裡面每一個文件夾都對應你一個資料庫名稱 把他們刪除就好了 就徹底沒了 不過可別把mysql這個文件夾刪了 還有別的文件 比如.err別亂刪哦。
如果這個你不會 或者說文件在使用刪除不了 那麼你就用mysql的可視化工具 比如mysql-front 5.1 進去刪除 效果都是一樣。