摘自：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就意味着直接取到 了属性字段，省去了二分查找带来的巨大时间消耗。