摘自：http://blog.csdn.net/cangyingzhijia/article/details/8592441
Sphinx使用的文件包括 “sph”， “spa”， “spi”， “spd”, “spp”， “spm” ，還有鎖文件。其中sph是系統的配置文件。其它則為索引文件。
.Spi 文件：保存WordId及指向此WordId對應的文檔信息在spd文件的指針。Spi文件在檢索程序啟動時完全加載入內存。Spi文件是分塊的，塊內排序，塊之間也排序。分塊的目的應該是為了快速檢索到WordId，因為Spi中的WordId是變長壓縮的，索引需要先在塊級別做二分定位，再在快內解壓縮查找。——這種做法，lucene里是FST，用trie來進行單詞和doc ids文件位置存儲！
文件結構，每塊中結構，wordId實際存儲的是差值
WordId | SpdFilePointer | DocNum | HitNum
.Spd文件：文件結構
DocID | [DocInfo] | HitFilePointer | FieldNum | HitNum
.Spp文件: 文件結構
HitPos
.Spa文件：存儲DocInfo的文件，檢索程序啟動時會把此文件加載如內存，sphinx可以指定DocInfo的存儲方式，
① 存儲到spd文件中（InLine）
②. 另外單獨存儲。指定此，就會生成spa文件
文件結構：
DocId | DocInfo
.Spm文件：在DocInfo中，有一種特殊的屬性，叫MVA，多值屬性。Sphinx對此屬性特殊處理，需要存儲在spm文件中。檢索程序啟動時會把此文件加載如內存。此（MVA）屬性在DocInfo對應位置存儲其在此文件中的字節偏移量。
文件結構：
DocId | Anum,A1,A2,…,An | Bnum,B1,B2,…,Bn | …
由於在第一趟掃描過程中會出現WordID相同的不同Hits(不同文檔或者不同位置不同字段)，二趟前會根據WordID排序，WordID相同的Hits會連續出現並合並(合並到第一次出現的相同WordID中)
下文摘自：http://mysql.taobao.org/monthly/2016/11/05/
sphinx索引文件的簡單介紹.
- 然后我們來看索引的種類以及格式，在sphinx中，每一個索引都包含了下面幾個文件：
- sph文件 保存了索引的頭文件，主要是一些索引元信息
- 實現在WriteHeader/LoadHeader中。
- spi文件 保存了wordlist,也就是索引文件中最核心的一個文件。
- 也就是通過spi文件可以迅速的從一個keywords(word)映射到一堆document list。下面就是spi文件的格式(dict=keywords)：
- sph文件 保存了索引的頭文件，主要是一些索引元信息
byte dummy = 0x01 keyword[] keyword_blocks keyword is: byte keyword_editcode byte[] keyword_delta if keyword_editcode == 0: assert keyword_delta = { 0 } return block_end zint doclist_offset zint num_docs zint num_hits if num_docs >= DOCLIST_HINT_THRESH: byte doclist_sizehint if ver >= 31 and num_docs > SKIPLIST_BLOCK: zint skiplist_pos zint skiplist_len if min_infix_len > 0: tag "infix-entries" infix_entry[] infix_hash_entries checkpoint[] checkpoints checkpoint is: dword keyword_len byte[] keyword [ keyword_len ] qword dict_offset if min_infix_len > 0: tag "infix-blocks" infix_block[] infix_hash_blocks tag "dict-header" zint num_checkpoints zint checkpoints_offset zint infix_codepoint_bytes zint infix_blocks_offset - 文件生成是在cidxHit中。
- spa文件 保存了attribute
- sps文件 單獨保存string類型的attribute值
- spd文件 保存了document list
- 所有的document id都保存在這個這個文件中，也就是通過spi文件得到document list的信息后，可以迅速在spd文件中定位document list。
- spe文件 保存了skip list
- spk文件 保存了 kill list
- spm文件 保存了MVA 值
- spp文件 保存了hit list。
- 保存了一個word在document中的所有出現的位置。也就是給定一個document 和一個keywords，這個文件將會返回所有的匹配位置(在當前的document中).
其中spp/spi/spd/spa/spe文件的生成都在RtIndex_t::SaveDiskDataImpl中實現。
轉自：http://www.xuebuyuan.com/1160253.html
sphinx的倒排索引采用了緊湊的磁盤存儲方式，由於應用環境的特 殊，docid是非連續的，其使用過程中我們對它的速度並不滿意，其並發和單次查詢時間在倒排列表較大的情況下，無論使用進程模式或是線程模式，都不能滿 足要求，為此才產生了修改其所索引結構的想法。
sphinx的倒排列表存放於spd文件，docid以增量壓縮的方式存儲，在源碼分析過程中，可以看到為了對查詢樹進行query_node(查詢詞) 間的"與"、"或"運算，sphinx采用了多層調用，多路歸並的方法來完成，這個過程中，為了找到符合某屬性條件的docid，會進行 docid->屬性之間的二分查找(查詢spa文件的hash索引，該索引在系統啟動時創建)，當查詢節點較多，要求返回結果較大的情況下，二分查 找帶來的時間消耗是“巨大”的。
spa文件粗略來說是docid+屬性，docid采用遞增方式存儲，ATTR_NUM0(docid+屬性) + ATTR_NUM1(...) + ....，我們注意到spd中每個詞的docid倒排列表，也是使用增量方式存儲的，二者存在着共性，因此產生了以ATTR_NUMx來替代docid的 思路，由於spa文件的每個docid屬性節點大小固定，因此在系統啟動時被加載到固定大小的數組中。在查詢時，取得ATTR_NUMx就意味着直接取到 了屬性字段，省去了二分查找帶來的巨大時間消耗。