1.区段查询
索引系统须要通过主查询来获取所有的文档信息，一种简单的实现是将整个表的数据读入内存，可是这可能导致整个表被锁定并使得其它操作被阻止（比如：在MyISAM格式上的INSERT操作），同一时候，将浪费大量内存用于存储查询结果，诸如此类的问题吧。 为了避免出现这样的情况，CoreSeek/Sphinx支持一种被称为 区段查询的技术. 首先。CoreSeek/Sphinx从数据库中取出文档ID的最小值和最大值。将由最大值和最小值定义自然数区间分成若干份。一次获取数据，建立索引。现举比例如以下：
sql_query_range = SELECT MIN(id),MAX(id) FROM documents
sql_range_step = 1000
sql_query = SELECT * FROM documents WHERE id>=$start AND id<=$end
仅仅要在配置文件中面写三条语句就可以
from后面要跟的是你数据库里面的表名，如这里的表就是document
2.增量索引取代实时索引
有这么一种常见的情况：整个数据集很大，以至于难于常常性的重建索引，可是每次新增的记录却相当地少。一个典型的样例是：一个论坛有1000000个已经归档的帖子，但每天仅仅有1000个新帖子。
在这样的情况下能够用所谓的“主索引＋增量索引”（main+delta）模式来实现“近实时”的索引更新。
这样的方法的基本思路是设置两个数据源和两个索引，对非常少更新或根本不更新的数据建立主索引，而对新增文档建立增量索引。在上述样例中。那1000000个已经归档的帖子放在主索引中。而每天新增的1000个帖子则放在增量索引中。增量索引更新的频率能够非常快。而文档能够在出现几分种内就能够被检索到。
确定详细某一文档的分属那个索引的分类工作能够自己主动完毕。一个可选的方案是，建立一个计数表，记录将文档集分成两部分的那个文档ID。而每次又一次构建主索引时。这个表都会被更新。
分辨要在mysql里建表，然后改动配置文件
# in MySQL
CREATE TABLE sph_counter
(
counter_id INTEGER PRIMARY KEY NOT NULL,
max_doc_id INTEGER NOT NULL
); # in sphinx.conf
source main
{
# ...
sql_query_pre = SET NAMES utf8
sql_query_pre = REPLACE INTO sph_counter SELECT 1, MAX(id) FROM documents
sql_query = SELECT id, title, body FROM documents \
WHERE id<span style="color:#ff0000;"><=</span>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )
} source delta : main
{
sql_query_pre = SET NAMES utf8
sql_query = SELECT id, title, body FROM documents \
WHERE id<span style="color:#ff0000;">></span>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )
} index main
{
source = main
path = /path/to/main
# ... all the other settings
} # note how all other settings are copied from main,
# but source and path are overridden (they MUST be)
index delta : main
{
source = delta
path = /path/to/delta
}
写好之后，还要写两个批处理文件。一个做增量索引。一个合并索引。
增量索引：g:/service/coreseek/bin/indexer -c g:/service/coreseek/etc/csft_mysql.conf --rotate main_delta
合并索引：g:/service/coreseek/bin/indexer -c g:/service/coreseek/etc/csft_mysql.conf --merge main main_delta --rotate
写好之后，再将两者放入到任务计划里，差点儿相同5分钟做一次增量索引。每天1点半时候做一次主索引