DBA’s blog

试了下sphinx,不久就发现有个问题，也就是不变的索引和变化的数据之间对立的问题，根据文档，sphinx是这样解决这个矛盾的，相对于少量变化的数据，大部分数据是不变的，这样把大多数数据装入主索引，而变化的数据装入增量索引，而文档中区分是否是增量数据是根据ID判断的，也就是到某个时间点主索引重新建立时计算这个时间点的数据库记录最大数，保存到一个辅助表中，而增量索引的重建是根据这个最大数为判断下限，来取变动的数据，这样对于插入删除是没有问题的，但是对于更新操作则会带来奇怪的问题，比如我更新了一个记录的查询字段值，那么这个字段或者被新包含到某个查询的结果集，或者是被某个查询的结果集合排除，而对于不变的主索引，无法检测到这个变动，而对于增量索引同样无法包含变动后的记录（因为ID）结果是，当更新数据后再次查询，本来应该被结果集排除的记录仍旧存在于中，本来应该新纳入结果集的还是无法被包含，根据网上的资料和实际实验，我给出以下方法，来部分解决这个问题。

1，对于主索引sphinx应该需要是否一条记录被更新，以从检索中排除。

2，对于增量索引，应该能包含主索引中的更新后的记录

这样设置新的辅助表为

+————-+———+——+—–+———+——-+
| Field       | Type    | Null | Key | Default | Extra |
+————-+———+——+—–+———+——-+
| counterid   | int(11) | NO   | PRI | NULL    |       |
| update_time | datetime    | YES  |     | NULL    |       |
+————-+———+——+—–+———+——-+

update_time字段记录主索引建立时间

编辑主索引数据源为（在索引中增加is_dirty字段来检测记录是否被改变，在索引建立后更新辅助表）

sql_query       = \
SELECT id, group_id, UNIX_TIMESTAMP(date_added) AS date_added, title, content,1 as is_dirty FROM documents
sql_query_post = REPLACE INTO search_counter SELECT 1,NOW();

编辑增量索引数据源（增量记录取舍根据表的附加字段date_added时间与辅助表时间比较）

sql_query                               = \
SELECT id, group_id, UNIX_TIMESTAMP(date_added) AS date_added, title, content,1 as is_dirty FROM documents WHERE date_added > (SELECT update_time FROM search_counter WHERE counterid=1)
另外在增量索引和主索引中都需要声明is_dirty的属性

对于更新操作需要做的是调用API的UpdateAttributes方法来更新is_dirty的值（比如1为未更新，2为更新）

更新数据库的相应记录的date_added时间，

这样主索引通过API的SetFilter方法来排除更新的记录，增量索引在重建时通过时间比较来包括更新的记录.

对于单表建立索引，这种方法可行，但是对多表联合的复杂情况可能要具体问题具体分析了。