本篇文章給大家整理分享28道PHP面試題（附答案分享），帶你梳理基礎(chǔ)知識，有一定的參考價值，有需要的朋友可以參考一下，希望對大家有所幫助。

過完年之后打算尋找新的工作機會，發(fā)現(xiàn)之前自己對于很多基礎(chǔ)的面試?yán)斫夂蛯W(xué)習(xí)不夠深刻，為了鼓勵自己持續(xù)前進所以最近開始在論壇和搜索引擎上開始學(xué)習(xí)和總結(jié)相關(guān)知識，其中有一些題目時論壇里面一些前輩分享過的題目或者答案，還有一部分時自己最近面試遇到的問題，基于自己的理解和前輩們的分享歸檔了一部分，所以分享出來，希望對其他的小伙伴們也有幫助，同時也希望能收到大佬們對于理解有誤的地方的指導(dǎo)，最近一段時間會持續(xù)更新

本論壇的文章參考的比較多，優(yōu)先列出來大家參考，如下： https://learnku.com/articles/63520 https://learnku.com/php/t/47623 https://learnku.com/articles/28772

一、php 數(shù)組底層實現(xiàn)原理

1、底層實現(xiàn)是通過散列表（hash table） + 雙向鏈表（解決hash沖突）

• hashtable：將不同的關(guān)鍵字（key）通過映射函數(shù)計算得到散列值（Bucket->h） 從而直接索引到對應(yīng)的Bucket

• hash表保存當(dāng)前循環(huán)的指針，所以foreach 比for更快

• Bucket：保存數(shù)組元素的key和value，以及散列值h

2、如何保證有序性

• 1. 散列函數(shù)和元素數(shù)組（Bucket）中間添加一層大小和存儲元素數(shù)組相同的映射表。

• 2. 用于存儲元素在實際存儲數(shù)組中的下標(biāo)

• 3. 元素按照映射表的先后順序插入實際存儲數(shù)組中

• 4. 映射表只是原理上的思路，實際上并不會有實際的映射表，而是初始化的時候分配Bucket內(nèi)存的同時，還會分配相同數(shù)量的 uint32_t 大小的空間，然后將 arData 偏移到存儲元素數(shù)組的位置。

3、解決hash重復(fù)(php使用的鏈表法)：

• 1. 鏈表法:不同關(guān)鍵字指向同一個單元時，使用鏈表保存關(guān)鍵字（遍歷鏈表匹配key）

• 2. 開放尋址法：當(dāng)關(guān)鍵字指向已經(jīng)存在數(shù)據(jù)的單元的時候，繼續(xù)尋找其他單元，直到找到可用單元（占用其他單元位置，更容易出現(xiàn)hash沖突，性能下降）

4、基礎(chǔ)知識

• 鏈表：隊列、棧、雙向鏈表、

• 鏈表 ：元素 + 指向下一元素的指針

• 雙向鏈表：指向上一元素的指針 + 元素 + 指向下一元素的指針

參考：

• 算法的時間與空間復(fù)雜度（一看就懂）

  https://zhuanlan.zhihu.com/p/50479555

• LeetCode0：學(xué)習(xí)算法必備知識：時間復(fù)雜度與空間復(fù)雜度的計算

  https://cloud.tencent.com/developer/article/1769988

二、冒泡排序的時間復(fù)雜度和空間復(fù)雜度

1、代碼實現(xiàn)

         $arr = [2, 4, 1, 5, 3, 6];          for ($i = 0; $i < (count($arr)); $i++) {              for ($j = $i + 1; $j < (count($arr)); $j++) {                  if ($arr[$i] <= $arr[$j]) {                      $temp = $arr[$i];                      $arr[$i] = $arr[$j];                      $arr[$j] = $temp;                  }              }          }      result : [6,5,4,3,2,1]

2、計算原理

• 第一輪：將數(shù)組的第一個元素和其他所有的元素進行比較，哪個元素更大，就換順序，從而冒泡出第一大（最大）的元素

• 第一輪：將數(shù)組的第二個元素和其他所有的元素進行比較（第一大已經(jīng)篩選出來不用繼續(xù)比較了），哪個元素更大，就換順序，從而冒泡出第二大的元素

• … 依次類推，冒泡從大到小排序的數(shù)組

平均時間復(fù)雜度：O(n^2) ；

最優(yōu)時間復(fù)雜度：O(n) ，需要加判斷，第一次循環(huán)如果一次都沒有交換就直接跳出循環(huán)

空間復(fù)雜度：O(1)，交換元素的時候的臨時變量占用的空間

最優(yōu)空間復(fù)雜度：O(1)，排好序，不需要交換位置

3、時間復(fù)雜度和空間復(fù)雜度

時間復(fù)雜度：全程為漸進時間復(fù)雜度，估算對處理器的使用效率（描述算法的效率趨勢，并不是指算法具體使用的時間，因為不同機器的性能不一致，只是一種效率計算的通用方法）

表示方法：大O符號表示法

復(fù)雜度量級：

• 常數(shù)階O(1)

• 線性階O(n)

• 平方階O(n2)

• 立方階O(n3)

• K次方階O(n^k)

• 指數(shù)階(2^n)

• 對數(shù)階O(logN)

• 線性對數(shù)階O(nlogN)

時間復(fù)制類型：

• 最好時間復(fù)雜度

• 最壞時間復(fù)雜度

• 平均時間復(fù)雜度

• 均攤時間復(fù)雜度

空間復(fù)雜度：全程漸進空間復(fù)雜度，估算對計算機內(nèi)存的使用程度（描述算法占用的存儲空間的趨勢，不是實際占用空間，同上）

參考：

• 算法的時間與空間復(fù)雜度（一看就懂）

  https://zhuanlan.zhihu.com/p/50479555

• LeetCode0：學(xué)習(xí)算法必備知識：時間復(fù)雜度與空間復(fù)雜度的計算

  https://cloud.tencent.com/developer/article/1769988

三、網(wǎng)絡(luò)七層協(xié)議及 TCP 和 TCP

應(yīng)用層、表示層、會話層、傳輸層、網(wǎng)絡(luò)層、（數(shù)據(jù)）鏈路層、物理層

記憶套路：

首字：應(yīng)表會傳（物鏈網(wǎng)）

第一個字：應(yīng)用層（出現(xiàn)次數(shù)多，易憶）

前四個正向：應(yīng)表 – 會傳

后三個反向：物聯(lián)網(wǎng)諧音比網(wǎng)鏈物更好記

四、TCP 和 UDP 的特點和區(qū)別

1、都是屬于傳輸層協(xié)議

2、TCP

• 面向連接，所以只能一對一

• 面向字節(jié)流傳輸

• 數(shù)據(jù)可靠，不丟失

• 全雙工通信

3、UDP（根據(jù)TCP特點反記）

• 無連接，支持一對一，一對多，多對多

• 面向保溫傳輸

• 首部開銷小，數(shù)據(jù)不一定可靠但是速度更快

參考：

• github:colinlet/PHP-Interview-QA =>PHP 面試問答 網(wǎng)絡(luò)篇

  https://github.com/colinlet/PHP-Interview-QA/blob/master/docs/01.網(wǎng)絡(luò).md#1-計算機網(wǎng)絡(luò)體系結(jié)構(gòu)

五、TCP 的三次握手和四次揮手

1、三次握手：

• 1）第一次：客戶端發(fā)送SYN = 1,seq = client_isn

  作用：

  客戶端：無

  服務(wù)端：確認(rèn)自己的接收功能和客戶端的發(fā)送功能

• 2）第二次：服務(wù)端發(fā)送SYN = 1,seq = server_isn,ACK =client_isn +1

  作用：

  客戶端：確認(rèn)自己發(fā)送和接收都正常，確認(rèn)服務(wù)端的接收和發(fā)送正常

  服務(wù)端：確認(rèn)自己的接收正常，確認(rèn)服務(wù)端的發(fā)送正常（這時候服務(wù)端還不能確認(rèn)客戶端接收是否正常）

• 3）第三次：客戶端發(fā)送SYN = 0, ACK = server_isn+1,seq =client_isn+1

  作用：雙方確認(rèn)互相的接收和發(fā)送正常，建立連接

2、四次揮手

• 1）第一次:客戶端發(fā)送FIN

  作用：告訴服務(wù)端我沒有數(shù)據(jù)發(fā)送了（但是還能接收數(shù)據(jù)）

• 2）第二次：服務(wù)端發(fā)送ACK

  作用：告訴客戶端收到請求了，可能服務(wù)端可能還有數(shù)據(jù)需要發(fā)送，所以客戶端收到進入FIN_WAIT狀態(tài)，等服務(wù)端數(shù)據(jù)傳輸完之后發(fā)送FIN

• 3）第三次：服務(wù)端發(fā)送FIN

  作用：服務(wù)端告訴客戶端我發(fā)送完了，可以關(guān)閉連接了。

• 4）第四次:客戶端發(fā)送ACK

  作用：客戶端收到FIN之后，擔(dān)心服務(wù)端不知道要關(guān)閉，所以發(fā)送一個ACK，進入TIME_WAIT，等待2MSL之后如果沒有收到回復(fù)，證明服務(wù)端已經(jīng)關(guān)閉了，這時候客戶端也關(guān)閉連接。

注意：

• 當(dāng)收到對方的FIN報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)

• 最后需要等待2MSL是因為網(wǎng)絡(luò)是不可靠的，如果服務(wù)端沒有收到最后一次ACK,服務(wù)端會重新放FIN包然后等客戶端再次發(fā)送ACK包然后關(guān)閉（所以客戶端最后發(fā)送ACK之后不能立即關(guān)閉連接）

參考：

• github:colinlet/PHP-Interview-QA =>PHP 面試問答 網(wǎng)絡(luò)篇

  https://github.com/colinlet/PHP-Interview-QA/blob/master/docs/01.網(wǎng)絡(luò).md#1-計算機網(wǎng)絡(luò)體系結(jié)構(gòu)

• TCP 協(xié)議中的三次握手和四次揮手 (圖解)

  https://blog.csdn.net/whuslei/article/details/6667471

• “三次握手，四次揮手” 你真的懂嗎？

  https://zhuanlan.zhihu.com/p/53374516

• TCP 的特性

  https://hit-alibaba.github.io/interview/basic/network/TCP.html

六、HTTP 狀態(tài)碼

1、狀態(tài)碼分類

• – 1xx：信息，服務(wù)器收到請求，需要請求者繼續(xù)操作

• – 2xx：成功

• – 3xx：重定向

• – 4xx：客戶端錯誤

• – 5xx：服務(wù)端錯誤

2、常用狀態(tài)碼

• 200：請求成功

• 301：永久重定向

• 302：臨時移動

• 400 bad request：客戶端請求語法錯誤

• 401 unauthorized：客戶端沒有權(quán)限

• 403 forbidden：服務(wù)器拒絕客戶端請求

• 404 not found：客戶端請求資源不存在

• 500 Internal Server Eerro：服務(wù)器內(nèi)部錯誤

• 502 bad gateway：作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請求時，從上游服務(wù)器接收到無效的響應(yīng)

• 503 Service Unavailable 超載或系統(tǒng)維護

• 504 Gateway timeout：網(wǎng)關(guān)超時

3、502 的原因及解決方法

原因：nginx將請求提交給網(wǎng)關(guān)（php-fpm）處理異常導(dǎo)致

1）fastcgi 緩沖區(qū)設(shè)置過小

fastcgi_buffers 8 16k;

fastcgi_buffer_size 32k;

2）php-cgi的進程數(shù)設(shè)置過少

查看FastCgi進程數(shù)：netstat -anpo | grep "php-cgi"| wc -l

調(diào)整參數(shù)最大子進程數(shù)：max_children

一般按照單個進程20M計算需要需要設(shè)置的子進程數(shù)

3）max_requests（內(nèi)存溢出或頻繁重啟）

參數(shù)指明每個children最多能處理的請求數(shù)量，到達最大值之后會重啟children。

設(shè)置過小可能導(dǎo)致頻繁重啟children：

php將請求輪詢給每個children，在大流量的場景下，每一個children 到達最大值的時間差不多，如果設(shè)置過小可能多個children 在同一時間關(guān)閉，nginx無法將請求轉(zhuǎn)發(fā)給php-fpm，cpu降低，負(fù)載變高。

設(shè)置過大可能導(dǎo)致內(nèi)存泄露

4）php執(zhí)行時間超過nginx等待時間

fastcgi_connect_timeout

fastcgi_send_timeout

fastcgi_read_timeout

5）fastcgi執(zhí)行時間

max_execution_time

參考：

• php+php-fom+nginx 配置參數(shù)調(diào)優(yōu)詳解

  http://www.voycn.com/article/phpphp-fomnginxpeizhicanshudiaoyouxiangjie

• nginx 報錯 502

  https://www.cnblogs.com/fengzhongzhuzu/p/9193355.html

七、http 和 HTTPS 的區(qū)別

1、端口：http 80； https ：443

2、http無狀態(tài)，https是有http + ssl構(gòu)建的可進行加密傳輸?shù)膮f(xié)議

3、http明文傳輸，https加密傳輸

4、http更快，三次握手三個包，https 需要12個包（3個tcp包+9個ssl握手包）

八、redis 分布式鎖及問題

1、實現(xiàn)：

加鎖：setnx

解鎖：del

鎖超時：expire

2、可能出現(xiàn)的問題

• 1）setnx 和expire非原子性問題（加鎖之后還沒來得及設(shè)置超時就掛了）

  解決方案：

  Redis 2.6.12以上版本為set指令增加了可選參數(shù)，偽代碼如下：set（key，1，30，NX）,這樣就可以取代setnx指令

• 2）超時誤刪其他進程鎖。（A進程執(zhí)行超時，導(dǎo)致鎖釋放，這時候B進程獲取鎖開始處理請求，這時候A進程處理完成，會誤刪B進程的鎖）

  解決方案：只能刪除自己進程的鎖 （lua腳本防止B進程獲取過期鎖之后誤刪A進程的鎖）

• 3）并發(fā)場景，A進程執(zhí)行超時導(dǎo)致鎖釋放，這時候B進程獲取到鎖。

  解決方案：開啟守護進程，給當(dāng)前進程要過期的鎖延時。

• 4）單點實例安全問題

  單機宕機之后導(dǎo)致所有客戶端無法獲取鎖

  解決：

  主從復(fù)制，因為是異步完成的所以無法完全實現(xiàn)解決

參考：

• 使用 Redis 作為分布式鎖的一些注意點

  https://www.cnblogs.com/gxyandwmm/p/9588383.html

• 面試官：你真的了解 Redis 分布式鎖嗎？

  https://segmentfault.com/a/1190000038988087

九、redis 為什么是單線程？為什么快？

推薦閱讀：https://www.php.cn/redis/475918.html

十、redis 的數(shù)據(jù)類型及應(yīng)用場景

1、string ：

普通的key/value存儲

2、hash：

hashmap：鍵值隊集合，存儲對象信息

3、list：

雙向鏈表:消息隊列

4、set：

value永遠為null的hashMap：無序集合且不重復(fù)：計算交集、并集、差集、去重值

5、zset：

有序集合且不重復(fù):hashMap(去重) + skiplist跳躍表（保證有序）：排行榜

參考：

• Redis 五種數(shù)據(jù)類型及應(yīng)用場景

  https://www.cnblogs.com/jasonZh/p/9513948.html

十一、redis 實現(xiàn)持久化的方式及原理、特點

1、RDB持久化（快照）：指定時間間隔內(nèi)的內(nèi)存數(shù)據(jù)集快照寫入磁盤

1）fork一個子進程，將快照內(nèi)容寫入臨時RDB文件中（dump.rdb），當(dāng)子進程寫完快照內(nèi)容之后新的文件替換老的文件

2）整個redis數(shù)據(jù)庫只包含一個備份文件

3）性能最大化，只需要fork子進程完成持久化工作，減少磁盤IO

4）持久化之前宕機可能會導(dǎo)致數(shù)據(jù)丟失

2、AOF持久化 ：以日志的形式記錄服務(wù)器的所有的寫、刪除操作

1）每接收到一個寫的命令用write函數(shù)追加到文件appendonly.aof

2）持久化的文件會越來越大，存在大量多余的日志（0 自增100次到100，會產(chǎn)生100條日志記錄）

3）可以設(shè)置不同的fsync策略

• appendfsync everysec ：1s一次，最多丟失1s的數(shù)據(jù)（默認(rèn)）

• appendfsync always ：每次變動都會執(zhí)行一次

• appendfsync no ：不處理

4）AOF文件太大之后會進行重寫：壓縮AOF文件大小

• fork一個子進程，將redis內(nèi)地數(shù)據(jù)對象的最新狀態(tài)寫入AOF臨時文件（類似rdb快照）

• 主進程收到的變動會先寫入內(nèi)存中，然后同步到老的AOF文件中（重寫失敗之后也能保證數(shù)據(jù)完整性）

• 子進程完成重寫之后會將內(nèi)存中的新變動同步追加到AOF的臨時文件中

• 父進程將臨時AOF文件替換成新的AOF文件，并重命名。之后收到的新命令寫入到新的文件中

參考：

• Redis 專題：萬字長文詳解持久化原理

  https://segmentfault.com/a/1190000039208726

• Redis 持久化

  https://segmentfault.com/a/1190000002906345

• RDB 和 AOF 持久化的原理是什么？我應(yīng)該用哪一個？它們的優(yōu)缺點？

  https://segmentfault.com/a/1190000018388385

十二、秒殺設(shè)計流程及難點

1、靜態(tài)緩存

2、nginx 負(fù)載均衡

三種方式：DNS輪詢、IP負(fù)債均衡、CDN

3、限流機制

方式：ip限流、接口令牌限流、用戶限流、header動態(tài)token（前端加密，后端解密）

4、分布式鎖

方式：

• setnx + expire （非原子性，redis2.6 之后set保證原子性）

• 釋放鎖超時 （開啟守護進程自動續(xù)時間）

• 過期鎖誤刪其他線程（requestId驗證或者lua腳本保證查 + 刪的原子性）

5、緩存數(shù)據(jù)

方式：

• 緩存擊穿：緩存數(shù)據(jù)預(yù)熱 + 布隆過濾器/空緩存

• 緩存雪崩：緩存設(shè)置隨機過期時間，防止同一時間過期

6、庫存及訂單

• 扣庫存

  • redis 自減庫存，并發(fā)場景下可能導(dǎo)致負(fù)數(shù)，影響庫存回倉：使用lua腳本保證原子性

  • redis預(yù)扣庫存之后，然后使用異步消息創(chuàng)建訂單并更新庫存變動

  • 數(shù)據(jù)庫更新庫存使用樂觀鎖：where stock_num – sell_num > 0

  • 添加消息發(fā)送記錄表及重試機制，防止異步消息丟失

• 創(chuàng)建訂單

  • 前端建立websocket連接或者輪詢監(jiān)聽訂單狀態(tài)

  • 消費驗證記錄狀態(tài)，防止重復(fù)消費

• 回倉

  • 創(chuàng)建訂單之后發(fā)送延時消息，驗證訂單支付狀態(tài)及庫存是否需要回倉

十三、防 sql 注入

1、過濾特殊字符

2、過濾數(shù)據(jù)庫關(guān)鍵字

3、驗證數(shù)據(jù)類型及格式

4、使用預(yù)編譯模式，綁定變量

十四、事務(wù)隔離級別

1、標(biāo)準(zhǔn)的sql隔離級別實現(xiàn)原理

• 未提交讀：其他事務(wù)可以直接讀到?jīng)]有提交的：臟讀

  • 事務(wù)對當(dāng)前被讀取的數(shù)據(jù)不加鎖

  • 在更新的瞬間加行級共享鎖到事務(wù)結(jié)束釋放

• 提交讀：事務(wù)開始和結(jié)束之間讀取的數(shù)據(jù)可能不一致，事務(wù)中其他事務(wù)修改了數(shù)據(jù)：不可重復(fù)度

  • 事務(wù)對當(dāng)前讀取的數(shù)據(jù)（被讀到的時候）行級共享鎖，讀完釋放

  • 在更新的瞬間加行級排他鎖到事務(wù)結(jié)束釋放

• 可重復(fù)讀：事務(wù)開始和結(jié)束之前讀取的數(shù)據(jù)保持一致，事務(wù)中其他事務(wù)不能修改數(shù)據(jù)：可重復(fù)讀

  • 事務(wù)對當(dāng)前讀到的數(shù)據(jù)從事務(wù)一開始就加一個行級共享鎖

  • 在更新的瞬間加行級排他鎖到事務(wù)結(jié)束釋放

  • 其他事務(wù)再事務(wù)過程中可能會新增數(shù)據(jù)導(dǎo)致幻讀

• 串行化

  • 事務(wù)讀取數(shù)據(jù)時加表級共享鎖

  • 事務(wù)更新數(shù)據(jù)時加表級排他鎖

2、innodb的事務(wù)隔離級別及實現(xiàn)原理（??！和上面的不一樣，區(qū)分理解一個是隔離級別 一個是?。∈聞?wù)??！隔離級別）

1）基本概念

• mvcc:多版本并發(fā)控制:依賴于undo log 和read view

  • 讓數(shù)據(jù)都讀不會對數(shù)據(jù)加鎖，提高數(shù)據(jù)庫并發(fā)處理能力

  • 寫操作才會加鎖

  • 一條數(shù)據(jù)有多個版本，每次事務(wù)更新數(shù)據(jù)的時候會生成一個新的數(shù)據(jù)版本，舊的數(shù)據(jù)保留在undo log

  • 一個事務(wù)啟動的時候只能看到所有已經(jīng)提交的事務(wù)結(jié)果

• 當(dāng)前讀：讀取的是最新版本

• 快照讀:讀取的是歷史版本

• 間隙鎖：間隙鎖會鎖住一個范圍內(nèi)的索引

  • update id between 10 and 20

  • 無論是否范圍內(nèi)是否存在數(shù)據(jù)，都會鎖住整個范圍：insert id = 15，將被防止

  • 只有可重復(fù)讀隔離級別才有間隙鎖

• next-key lock：

  • 索引記錄上的記錄鎖+ 間隙鎖（索引值到前一個索引值之間的間隙鎖）

  • 前開后閉

  • 阻止幻讀

2）事務(wù)隔離級別

• 未提交讀

  • 事務(wù)對當(dāng)前讀取的數(shù)據(jù)不加鎖，都是當(dāng)前讀

  • 在更新的瞬間加行級共享鎖到事務(wù)結(jié)束釋放

• 提交讀

  • 事務(wù)對當(dāng)前讀取的數(shù)據(jù)不加鎖，都是快照讀

  • 在更新的瞬間加行級排他鎖到事務(wù)結(jié)束釋放

• 可重復(fù)讀

  • 事務(wù)對當(dāng)前讀取的數(shù)據(jù)不加鎖，都是快照讀

  • 事務(wù)再更新某數(shù)據(jù)的瞬間，必須加行級排他鎖（Record 記錄鎖、GAP間隙鎖、next-key 鎖），事務(wù)結(jié)束釋放

  • 間隙鎖解決的是幻讀問題

    • 主從復(fù)制的情況下 ,如果沒有間隙鎖，master庫的A、B進程

    • A進程 delete id < 6 ;然后還沒有commit

    • B進程insert id = 3，commit

    • A進程提交commit

    • 該場景下，主庫會存在一條id =3 的記錄，但是binlog里面是先刪除再新增就會導(dǎo)致從庫沒有數(shù)據(jù)，導(dǎo)致主從的數(shù)據(jù)不一致

  • MVCC的快照解決的是不可重復(fù)讀問題

• 串行化

  • 事務(wù)讀取數(shù)據(jù)時加表級，當(dāng)前讀

  • 事務(wù)更新數(shù)據(jù)時加表級排他鎖

參考：

• 深入理解 MySQL 中事務(wù)隔離級別的實現(xiàn)原理

  https://segmentfault.com/a/1190000025156465

• 小胖問我：MySQL 事務(wù)與 MVCC 原理

  https://segmentfault.com/a/1190000039809030

• 快照在 MVCC 中是怎么工作的？

  https://www.jianshu.com/p/6c4454ffecc3

• MVCC 我知道，但是為什么要設(shè)計間隙鎖？

  https://www.jianshu.com/p/fbec6d1fa16c

• 間隙鎖和 next-key lock

  https://www.jianshu.com/p/d1aba64b5c03

十五、索引原理

索引就是幫助數(shù)據(jù)庫高效查找數(shù)據(jù)的存儲結(jié)構(gòu)，存儲再磁盤中，需要消耗磁盤IO

1、存儲引擎

• myisam 支持表鎖，索引和數(shù)據(jù)分開存儲適合跨服務(wù)器遷移

• innodb 支持行鎖，索引和數(shù)據(jù)存儲再一個文件

2、索引類型

• hash索引

  • 適合精確查詢且效率高

  • 無法排序、不適合范圍查詢

  • hash沖突的情況下需要遍歷鏈表（php數(shù)組的實現(xiàn)原理、redis zset 的實現(xiàn)原理類似）

• b-tree、b+tree

  • b-tree 和b+tree的去區(qū)別

    • b+tree 的數(shù)據(jù)全部存儲在葉子節(jié)點，內(nèi)部節(jié)點只存key,一次磁盤IO能獲取到