Java面試中常問的數據庫方面問題

時間  2019-11-10
標籤 java 面試 常問 數據庫 方面 問題 欄目 Java 简体版
原文   原文鏈接

MySQL

爲何用自增列做爲主鍵

  1. 若是咱們定義了主鍵(PRIMARY KEY)，那麼InnoDB會選擇主鍵做爲彙集索引、若是沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的惟一索引做爲主鍵索引、若是也沒有這樣的惟一索引，則InnoDB會選擇內置6字節長的ROWID做爲隱含的彙集索引(ROWID隨着行記錄的寫入而主鍵遞增，這個ROWID不像ORACLE的ROWID那樣可引用，是隱含的)。java

  2. 數據記錄自己被存於主索引（一顆B+Tree）的葉子節點上。這就要求同一個葉子節點內（大小爲一個內存頁或磁盤頁）的各條數據記錄按主鍵順序存放，所以每當有一條新的記錄插入時，MySQL會根據其主鍵將其插入適當的節點和位置，若是頁面達到裝載因子（InnoDB默認爲15/16），則開闢一個新的頁（節點）node

  3. 若是表使用自增主鍵，那麼每次插入新的記錄，記錄就會順序添加到當前索引節點的後續位置，當一頁寫滿，就會自動開闢一個新的頁mysql

  4. 若是使用非自增主鍵（若是身份證號或學號等），因爲每次插入主鍵的值近似於隨機，所以每次新紀錄都要被插到現有索引頁得中間某個位置，此時MySQL不得不爲了將新記錄插到合適位置而移動數據，甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增長了不少開銷，同時頻繁的移動、分頁操做形成了大量的碎片，獲得了不夠緊湊的索引結構，後續不得不經過OPTIMIZE TABLE來重建表並優化填充頁面。redis

爲何使用數據索引能提升效率

  1. 數據索引的存儲是有序的算法

  2. 在有序的狀況下，經過索引查詢一個數據是無需遍歷索引記錄的sql

  3. 極端狀況下，數據索引的查詢效率爲二分法查詢效率，趨近於 log2(N)數據庫

B+樹索引和哈希索引的區別

B+樹是一個平衡的多叉樹，從根節點到每一個葉子節點的高度差值不超過1，並且同層級的節點間有指針相互連接，是有序的緩存

哈希索引就是採用必定的哈希算法，把鍵值換算成新的哈希值，檢索時不須要相似B+樹那樣從根節點到葉子節點逐級查找，只需一次哈希算法便可,是無序的安全

哈希索引的優點：服務器

  1. 等值查詢。哈希索引具備絕對優點（前提是：沒有大量重複鍵值，若是大量重複鍵值時，哈希索引的效率很低，由於存在所謂的哈希碰撞問題。）

哈希索引不適用的場景：

  1. 不支持範圍查詢

  2. 不支持索引完成排序

  3. 不支持聯合索引的最左前綴匹配規則

一般，B+樹索引結構適用於絕大多數場景，像下面這種場景用哈希索引才更有優點：

在HEAP表中，若是存儲的數據重複度很低（也就是說基數很大），對該列數據以等值查詢爲主，沒有範圍查詢、沒有排序的時候，特別適合採用哈希索引，例如這種SQL：

select id,name from table where name='李明'; — 僅等值查詢

而經常使用的InnoDB引擎中默認使用的是B+樹索引，它會實時監控表上索引的使用狀況，若是認爲創建哈希索引能夠提升查詢效率，則自動在內存中的「自適應哈希索引緩衝區」創建哈希索引（在InnoDB中默認開啓自適應哈希索引），經過觀察搜索模式，MySQL會利用index key的前綴創建哈希索引，若是一個表幾乎大部分都在緩衝池中，那麼創建一個哈希索引可以加快等值查詢。

注意：在某些工做負載下，經過哈希索引查找帶來的性能提高遠大於額外的監控索引搜索狀況和保持這個哈希表結構所帶來的開銷。但某些時候，在負載高的狀況下，自適應哈希索引中添加的read/write鎖也會帶來競爭，好比高併發的join操做。like操做和%的通配符操做也不適用於自適應哈希索引，可能要關閉自適應哈希索引。

B樹和B+樹的區別

  1. B樹，每一個節點都存儲key和data，全部節點組成這棵樹，而且葉子節點指針爲nul，葉子結點不包含任何關鍵字信息。

  2. B+樹，全部的葉子結點中包含了所有關鍵字的信息，及指向含有這些關鍵字記錄的指針，且葉子結點自己依關鍵字的大小自小而大的順序連接，全部的非終端結點能夠當作是索引部分，結點中僅含有其子樹根結點中最大（或最小）關鍵字。 (而B 樹的非終節點也包含須要查找的有效信息)

​​​​​​​

爲何說B+比B樹更適合實際應用中操做系統的文件索引和數據庫索引？

  1. B+的磁盤讀寫代價更低 B+的內部結點並無指向關鍵字具體信息的指針。所以其內部結點相對B樹更小。若是把全部同一內部結點的關鍵字存放在同一盤塊中，那麼盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的須要查找的關鍵字也就越多。相對來講IO讀寫次數也就下降了。

  2. B+-tree的查詢效率更加穩定 因爲非終結點並非最終指向文件內容的結點，而只是葉子結點中關鍵字的索引。因此任何關鍵字的查找必須走一條從根結點到葉子結點的路。全部關鍵字查詢的路徑長度相同，致使每個數據的查詢效率至關。

MySQL聯合索引

  1. 聯合索引是兩個或更多個列上的索引。對於聯合索引:Mysql從左到右的使用索引中的字段，一個查詢能夠只使用索引中的一部份，但只能是最左側部分。例如索引是key index (a,b,c). 能夠支持a   、    a,b   、  a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側字段是常量引用時，索引就十分有效。

  2. 利用索引中的附加列，您能夠縮小搜索的範圍，但使用一個具備兩列的索引 不一樣於使用兩個單獨的索引。複合索引的結構與電話簿相似，人名由姓和名構成，電話簿首先按姓氏對進行排序，而後按名字對有相同姓氏的人進行排序。若是您知 道姓，電話簿將很是有用；若是您知道姓和名，電話簿則更爲有用，但若是您只知道名不姓，電話簿將沒有用處。

什麼狀況下應不建或少建索引

  1. 表記錄太少

  2. 常常插入、刪除、修改的表

  3. 數據重複且分佈平均的表字段，假如一個表有10萬行記錄，有一個字段A只有T和F兩種值，且每一個值的分佈機率大約爲50%，那麼對這種表A字段建索引通常不會提升數據庫的查詢速度。

  4. 常常和主字段一塊查詢但主字段索引值比較多的表字段

MySQL分區

一. 什麼是表分區？

表分區，是指根據必定規則，將數據庫中的一張表分解成多個更小的，容易管理的部分。從邏輯上看，只有一張表，可是底層倒是由多個物理分區組成。

二. 表分區與分表的區別

分表：指的是經過必定規則，將一張表分解成多張不一樣的表。好比將用戶訂單記錄根據時間成多個表。

分表與分區的區別在於：分區從邏輯上來說只有一張表，而分表則是將一張表分解成多張表。

三. 表分區有什麼好處？

  1. 分區表的數據能夠分佈在不一樣的物理設備上，從而高效地利用多個硬件設備。 2. 和單個磁盤或者文件系統相比，能夠存儲更多數據

  2. 優化查詢。在where語句中包含分區條件時，能夠只掃描一個或多個分區表來提升查詢效率；涉及sum和count語句時，也能夠在多個分區上並行處理，最後彙總結果。

  3. 分區表更容易維護。例如：想批量刪除大量數據能夠清除整個分區。

  4. 可使用分區表來避免某些特殊的瓶頸，例如InnoDB的單個索引的互斥訪問，ext3問價你係統的inode鎖競爭等。

四. 分區表的限制因素

  1. 一個表最多隻能有1024個分區

  2. MySQL5.1中，分區表達式必須是整數，或者返回整數的表達式。在MySQL5.5中提供了非整數表達式分區的支持。

  3. 若是分區字段中有主鍵或者惟一索引的列，那麼多有主鍵列和惟一索引列都必須包含進來。即：分區字段要麼不包含主鍵或者索引列，要麼包含所有主鍵和索引列。

  4. 分區表中沒法使用外鍵約束

  5. MySQL的分區適用於一個表的全部數據和索引，不能只對表數據分區而不對索引分區，也不能只對索引分區而不對錶分區，也不能只對表的一部分數據分區。

五. 如何判斷當前MySQL是否支持分區？

命令：show variables like '%partition%' 運行結果:

mysql> show variables like '%partition%'; +-------------------+-------+ | Variable_name     | Value | +-------------------+-------+ | have_partitioning | YES   | +-------------------+-------+ 1 row in set (0.00 sec) have_partintioning 的值爲YES，表示支持分區。

六. MySQL支持的分區類型有哪些？

  1. RANGE分區： 這種模式容許將數據劃分不一樣範圍。例如能夠將一個表經過年份劃分紅若干個分區

  2. LIST分區： 這種模式容許系統經過預約義的列表的值來對數據進行分割。按照List中的值分區，與RANGE的區別是，range分區的區間範圍值是連續的。

  3. HASH分區 ：這中模式容許經過對錶的一個或多個列的Hash Key進行計算，最後經過這個Hash碼不一樣數值對應的數據區域進行分區。例如能夠創建一個對錶主鍵進行分區的表。

  4. KEY分區 ：上面Hash模式的一種延伸，這裏的Hash Key是MySQL系統產生的。

四種隔離級別

  1. Serializable (串行化)：可避免髒讀、不可重複讀、幻讀的發生。

  2. Repeatable read (可重複讀)：可避免髒讀、不可重複讀的發生。

  3. Read committed (讀已提交)：可避免髒讀的發生。

  4. Read uncommitted (讀未提交)：最低級別，任何狀況都沒法保證。

關於MVVC

MySQL InnoDB存儲引擎，實現的是基於多版本的併發控制協議——MVCC (Multi-Version Concurrency Control) (注：與MVCC相對的，是基於鎖的併發控制，Lock-Based Concurrency Control)。MVCC最大的好處：讀不加鎖，讀寫不衝突。在讀多寫少的OLTP應用中，讀寫不衝突是很是重要的，極大的增長了系統的併發性能，現階段幾乎全部的RDBMS，都支持了MVCC。

  1. LBCC：Lock-Based Concurrency Control，基於鎖的併發控制。

  2. MVCC：Multi-Version Concurrency Control，基於多版本的併發控制協議。純粹基於鎖的併發機制併發量低，MVCC是在基於鎖的併發控制上的改進，主要是在讀操做上提升了併發量。

在MVCC併發控制中，讀操做能夠分紅兩類：

  1. 快照讀 (snapshot read)：讀取的是記錄的可見版本 (有多是歷史版本)，不用加鎖（共享讀鎖s鎖也不加，因此不會阻塞其餘事務的寫）。

  2. 當前讀 (current read)：讀取的是記錄的最新版本，而且，當前讀返回的記錄，都會加上鎖，保證其餘事務不會再併發修改這條記錄。

行級鎖定的優勢：

  1. 當在許多線程中訪問不一樣的行時只存在少許鎖定衝突。

  2. 回滾時只有少許的更改

  3. 能夠長時間鎖定單一的行。

行級鎖定的缺點：

  1. 比頁級或表級鎖定佔用更多的內存。

  2. 當在表的大部分中使用時，比頁級或表級鎖定速度慢，由於你必須獲取更多的鎖。

  3. 若是你在大部分數據上常常進行GROUP BY操做或者必須常常掃描整個表，比其它鎖定明顯慢不少。

  4. 用高級別鎖定，經過支持不一樣的類型鎖定，你也能夠很容易地調節應用程序，由於其鎖成本小於行級鎖定。

MySQL觸發器簡單實例

  1. CREATE TRIGGER <觸發器名稱>  --觸發器必須有名字，最多64個字符，可能後面會附有分隔符.它和MySQL中其餘對象的命名方式基本相象.

  2. { BEFORE | AFTER }  --觸發器有執行的時間設置：能夠設置爲事件發生前或後。

  3. { INSERT | UPDATE | DELETE }  --一樣也能設定觸發的事件：它們能夠在執行insert、update或delete的過程當中觸發。

  4. ON <表名稱>  --觸發器是屬於某一個表的:當在這個表上執行插入、 更新或刪除操做的時候就致使觸發器的激活. 咱們不能給同一張表的同一個事件安排兩個觸發器。

  5. FOR EACH ROW  --觸發器的執行間隔：FOR EACH ROW子句通知觸發器 每隔一行執行一次動做，而不是對整個表執行一次。

  6. <觸發器SQL語句>  --觸發器包含所要觸發的SQL語句：這裏的語句能夠是任何合法的語句， 包括複合語句，可是這裏的語句受的限制和函數的同樣。

什麼是存儲過程

簡單的說，就是一組SQL語句集，功能強大，能夠實現一些比較複雜的邏輯功能，相似於JAVA語言中的方法；

ps:存儲過程跟觸發器有點相似，都是一組SQL集，可是存儲過程是主動調用的，且功能比觸發器更增強大，觸發器是某件事觸發後自動調用；

有哪些特性

  1. 有輸入輸出參數，能夠聲明變量，有if/else, case,while等控制語句，經過編寫存儲過程，能夠實現複雜的邏輯功能；

  2. 函數的廣泛特性：模塊化，封裝，代碼複用；

  3. 速度快，只有首次執行需通過編譯和優化步驟，後續被調用能夠直接執行，省去以上步驟；

DROP PROCEDURE IF EXISTS `proc_adder`;
DELIMITER ;;
CREATE DEFINER=`root`@`localhost` PROCEDURE `proc_adder`(IN a int, IN b int, OUT sum int)
BEGIN
   #Routine body goes here...

   DECLARE c int;
   if a is null then set a = 0; 
   end if;
 
   if b is null then set b = 0;
   end if;

   set sum  = a + b;
END
;;
DELIMITER ;

set @b=5;
call proc_adder(0,@b,@s);
SELECT @s as sum;



create table tab2(
  tab2_id varchar(11)
);

DROP TRIGGER if EXISTS t_ai_on_tab1;
create TRAILING t_ai_on_tab1
AFTER INSERT ON tab1
for EACH ROW
BEGIN
  INSERT INTO tab2(tab2_id) values(new.tab1_id);
end;

INSERT INTO tab1(tab1_id) values('0001');

SELECT * FROM tab2;

MySQL優化

  1. 開啓查詢緩存，優化查詢

  2. explain你的select查詢，這能夠幫你分析你的查詢語句或是表結構的性能瓶頸。EXPLAIN 的查詢結果還會告訴你你的索引主鍵被如何利用的，你的數據表是如何被搜索和排序的

  3. 當只要一行數據時使用limit 1，MySQL數據庫引擎會在找到一條數據後中止搜索，而不是繼續日後查少下一條符合記錄的數據

  4. 爲搜索字段建索引

  5. 使用 ENUM 而不是 VARCHAR，若是你有一個字段，好比「性別」，「國家」，「民族」，「狀態」或「部門」，你知道這些字段的取值是有限並且固定的，那麼，你應該使用 ENUM 而不是VARCHAR。

  6. Prepared Statements Prepared Statements很像存儲過程，是一種運行在後臺的SQL語句集合，咱們能夠從使用 prepared statements 得到不少好處，不管是性能問題仍是安全問題。Prepared Statements 能夠檢查一些你綁定好的變量，這樣能夠保護你的程序不會受到「SQL注入式」攻擊

  7. 垂直分表

  8. 選擇正確的存儲引擎

key和index的區別

  1. key 是數據庫的物理結構，它包含兩層意義和做用，一是約束（偏重於約束和規範數據庫的結構完整性），二是索引（輔助查詢用的）。包括primary key, unique key, foreign key 等

  2. index是數據庫的物理結構，它只是輔助查詢的，它建立時會在另外的表空間（mysql中的innodb表空間）以一個相似目錄的結構存儲。索引要分類的話，分爲前綴索引、全文本索引等；

Mysql 中 MyISAM 和 InnoDB 的區別有哪些？

區別：

  1. InnoDB支持事務，MyISAM不支持，對於InnoDB每一條SQL語言都默認封裝成事務，自動提交，這樣會影響速度，因此最好把多條SQL語言放在begin和commit之間，組成一個事務；

  2. InnoDB支持外鍵，而MyISAM不支持。對一個包含外鍵的InnoDB錶轉爲MYISAM會失敗；

  3. InnoDB是彙集索引，數據文件是和索引綁在一塊兒的，必需要有主鍵，經過主鍵索引效率很高。可是輔助索引須要兩次查詢，先查詢到主鍵，而後再經過主鍵查詢到數據。所以，主鍵不該該過大，由於主鍵太大，其餘索引也都會很大。而MyISAM是非彙集索引，數據文件是分離的，索引保存的是數據文件的指針。主鍵索引和輔助索引是獨立的。

  4. InnoDB不保存表的具體行數，執行select count(*) from table時須要全表掃描。而MyISAM用一個變量保存了整個表的行數，執行上述語句時只須要讀出該變量便可，速度很快；

  5. Innodb不支持全文索引，而MyISAM支持全文索引，查詢效率上MyISAM要高；

如何選擇：

  1. 是否要支持事務，若是要請選擇innodb，若是不須要能夠考慮MyISAM；

  2. 若是表中絕大多數都只是讀查詢，能夠考慮MyISAM，若是既有讀寫也挺頻繁，請使用InnoDB。

  3. 系統奔潰後，MyISAM恢復起來更困難，可否接受；

  4. MySQL5.5版本開始Innodb已經成爲Mysql的默認引擎(以前是MyISAM)，說明其優點是有目共睹的，若是你不知道用什麼，那就用InnoDB，至少不會差。

數據庫表建立注意事項

1、字段名及字段配製合理性

  1. 剔除關係不密切的字段

  2. 字段命名要有規則及相對應的含義（不要一部分英文，一部分拼音，還有相似a.b.c這樣不明含義的字段）

  3. 字段命名儘可能不要使用縮寫（大多數縮寫都不能明確字段含義）

  4. 字段不要大小寫混用（想要具備可讀性，多個英文單詞可以使用下劃線形式鏈接）

  5. 字段名不要使用保留字或者關鍵字

  6. 保持字段名和類型的一致性

  7. 慎重選擇數字類型

  8. 給文本字段留足餘量

2、系統特殊字段處理及建成後建議

  1. 添加刪除標記（例如操做人、刪除時間）

  2. 創建版本機制

3、表結構合理性配置

  1. 多型字段的處理，就是表中是否存在字段可以分解成更小獨立的幾部分（例如：人能夠分爲男人和女人）

  2. 多值字段的處理，能夠將表分爲三張表，這樣使得檢索和排序更加有調理，且保證數據的完整性！

4、其它建議

  1. 對於大數據字段，獨立表進行存儲，以便影響性能（例如：簡介字段）

  2. 使用varchar類型代替char，由於varchar會動態分配長度，char指定長度是固定的。

  3. 給表建立主鍵，對於沒有主鍵的表，在查詢和索引定義上有必定的影響。

  4. 避免表字段運行爲null，建議設置默認值（例如：int類型設置默認值爲0）在索引查詢上，效率立顯！

  5. 創建索引，最好創建在惟一和非空的字段上，創建太多的索引對後期插入、更新都存在必定的影響（考慮實際狀況來建立）。

Redis

Redis單線程問題

單線程指的是網絡請求模塊使用了一個線程（因此不需考慮併發安全性），即一個線程處理全部網絡請求，其餘模塊仍用了多個線程。

爲何說Redis可以快速執行

  1. 絕大部分請求是純粹的內存操做（很是快速）

  2. 採用單線程,避免了沒必要要的上下文切換和競爭條件

  3. 非阻塞IO - IO多路複用

Redis的內部實現

內部實現採用epoll，採用了epoll+本身實現的簡單的事件框架。epoll中的讀、寫、關閉、鏈接都轉化成了事件，而後利用epoll的多路複用特性，不在io上浪費一點時間 這3個條件不是相互獨立的，特別是第一條，若是請求都是耗時的，採用單線程吞吐量及性能不好。redis爲特殊的場景選擇了合適的技術方案。

Redis關於線程安全問題

redis其實是採用了線程封閉的觀念，把任務封閉在一個線程，天然避免了線程安全問題，不過對於須要依賴多個redis操做的複合操做來講，依然須要鎖，並且有多是分佈式鎖。

使用Redis有哪些好處？

  1. 速度快，由於數據存在內存中，相似於HashMap，HashMap的優點就是查找和操做的時間複雜度都是O(1)

  2. 支持豐富數據類型，支持string，list，set，sorted set，hash

  3. 支持事務，操做都是原子性，所謂的原子性就是對數據的更改要麼所有執行，要麼所有不執行

  4. 豐富的特性：可用於緩存，消息，按key設置過時時間，過時後將會自動刪除

redis相比memcached有哪些優點？

  1. memcached全部的值均是簡單的字符串，redis做爲其替代者，支持更爲豐富的數據類型

  2. redis的速度比memcached快不少

  3. redis能夠持久化其數據

  4. Redis支持數據的備份，即master-slave模式的數據備份。

  5. 使用底層模型不一樣，它們之間底層實現方式 以及與客戶端之間通訊的應用協議不同。Redis直接本身構建了VM 機制 ，由於通常的系統調用系統函數的話，會浪費必定的時間去移動和請求。

  6. value大小：redis最大能夠達到1GB，而memcache只有1MB

Redis主從複製

過程原理：

  1. 當從庫和主庫創建MS關係後,會向主數據庫發送SYNC命令

  2. 主庫接收到SYNC命令後會開始在後臺保存快照(RDB持久化過程),並將期間接收到的寫命令緩存起來

  3. 當快照完成後,主Redis會將快照文件和全部緩存的寫命令發送給從Redis

  4. 從Redis接收到後,會載入快照文件而且執行收到的緩存的命令

  5. 以後,主Redis每當接收到寫命令時就會將命令發送從Redis，從而保證數據的一致

缺點：全部的slave節點數據的複製和同步都由master節點來處理,會照成master節點壓力太大,使用主從從結構來解決

Redis兩種持久化方式的優缺點

  1. RDB 持久化能夠在指定的時間間隔內生成數據集的時間點快照（point-in-time snapshot）

  2. AOF 持久化記錄服務器執行的全部寫操做命令，並在服務器啓動時，經過從新執行這些命令來還原數據集。

  3. Redis 還能夠同時使用 AOF 持久化和 RDB 持久化。當redis重啓時,它會有限使用AOF文件來還原數據集,由於AOF文件保存的數據集一般比RDB文件所保存的數據集更加完整

RDB的優勢：

  1. RDB 是一個很是緊湊（compact）的文件，它保存了 Redis 在某個時間點上的數據集。 這種文件很是適合用於進行備份： 好比說，你能夠在最近的 24 小時內，每小時備份一次 RDB 文件，而且在每月的每一天，也備份一個 RDB 文件。 這樣的話，即便趕上問題，也能夠隨時將數據集還原到不一樣的版本。

  2. RDB 很是適用於災難恢復（disaster recovery）：它只有一個文件，而且內容都很是緊湊，能夠（在加密後）將它傳送到別的數據中心，或者亞馬遜 S3 中。

  3. RDB 能夠最大化 Redis 的性能：父進程在保存 RDB 文件時惟一要作的就是 fork 出一個子進程，而後這個子進程就會處理接下來的全部保存工做，父進程無須執行任何磁盤 I/O 操做。

  4. RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快

Redis常見的性能問題都有哪些？如何解決？

  1. Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工做，當快照比較大時對性能影響是很是大的，會間斷性暫停服務，因此Master最好不要寫內存快照。

  2. Master AOF持久化，若是不重寫AOF文件，這個持久化方式對性能的影響是最小的，可是AOF文件會不斷增大，AOF文件過大會影響Master重啓的恢復速度。Master最好不要作任何持久化工做，包括內存快照和AOF日誌文件，特別是不要啓用內存快照作持久化,若是數據比較關鍵，某個Slave開啓AOF備份數據，策略爲每秒同步一次。

  3. Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會佔大量的CPU和內存資源，致使服務load太高，出現短暫服務暫停現象。

  4. Redis主從複製的性能問題，爲了主從複製的速度和鏈接的穩定性，Slave和Master最好在同一個局域網內

Redis提供6種數據淘汰策略

  1. volatile-lru：從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰

  2. volatile-ttl：從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰

  3. volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰

  4. allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰

  5. allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰

  6. no-enviction（驅逐）：禁止驅逐數據

PS：若是以爲個人分享不錯，歡迎你們隨手點贊、轉發。

我有一個微信公衆號，常常會分享一些Java技術相關的乾貨；若是你喜歡個人分享，能夠用微信搜索「Java團長」或者「javatuanzhang」關注。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程