sphinx 1.10推出了很多新特性：
比如：实时索引，字符串属性，prefork 和 threads支持，及SphinxSE 中的option添加等
详细请查阅原文：http://www.sphinxsearch.com/docs/manual-1.10.html#rel110
个人觉得 sphinx 1.10-beta 两个最大的新特性：字符串索引和实时索引。对sphinx使用来说是一个很大的飞跃
字符串索引：可以很方便的存储，如果结合实时索引的话，就已经形成了貌似nosql一样的数据缓存层。而且，很多数据不必二次在数据库中查询，自然对
程序开发和运维有很大的帮助。检索出来后直接使用其数据，不过这个和所有缓存数据一样，注意在数据更新操作的时候需要同步更新这里的sql_attr_string
或rt_attr_string
实时索引(Real-time indexes)：
优点：
此功能是个人对sphinx的最大期待。在正式部署中，sphinx real-time 可以当成一个类似 memcache的数据存储插件，充分利用其查询、分布式
部署的便捷性，做到数据层次化管理。缓解数据库的压力。同时还支持事务操作，这个在很多nosql中是所缺少的。这，简直就是sql和nosql的混合体啊^_^
不足：
今天特别对实时索引进行了功能性的测试。虽然此功能很新颖且实用。但现阶段，若部署在生产环境下可能会遇到以下几个问题：
a、数据插入问题：Real-time的功能采取的是类似 标准sql的语句执行数据存储。如：
insert into(id,gid,title,content) values(1,234,’hello sphinx ‘,’I am superman!’);
这里的id必须人工计算：不能像mysql的auto_increment对主键进行自动累加。
另外，不能使用标准sql 的函数 max获取最大值，如：select max(id) from testrt,(sphinxQL中提示可以使用函数，但我在尝试过，系统提示语法错误，可能暂时只针对 非实时索引sphinxSE方式)
如果数据多的话，而且并发量比较大的话，在程序端实现起来自然会出现异常。
我这里暂时采用了一个办法处理这个问题：
查询 最大的id，并每次进行累加
select * from testrt order by id desc limit 1;
获取结果集的 id即为最大，相当于mysql中的auto_increment 变量。然后再对每次数据插入进行累加。具体做法可以参照前一篇的程序代码
b、数据删除：只能使用唯一的语句 delete from testrt where id=123; 如果数据量大的话，必须在逻辑层循环删除。而且不支持 in操作，不过文档中已提到，in操作已经在
计划中了，期待着。 另外，不能全部清空数据，不能像 数据库操作的 truncate table那样便捷。若索引很大并想重建索引的话，那就。。。等着抓狂吧
c、索引数据更新：sphinx没有提供标准sql的update操作(其实也没必要)，而是采取了类似mysql 的replace 语法。
实例：repalce into(id,gid,title,content) values(1,234,’hello sphinx ‘,’I am superwomen!’); 不过遗憾的是不能进行条件更新
d、查询：Real-time的sql查询还是很方便，或者很健全，比如：对字段查询、属性过滤、分组聚合、排序、评分等。完全满足一个搜索引擎的查询需求。但此版本还是缺少支持一些
数据库的常用函数。正如刚才提到的max、min等；以及对字段的较复杂的操作。
比如：select count(gid) as amount from testrt;就会报语法错误，这个例子可以采取变通的方式处理
select * from testrt group by gid;
其结果集中存在 @groupby @count变量值
文档中有提及在sphinxSE中可以使用函数，不过在这里暂时用不了，还是期待！
综上所述：sphinx的实时索引特性，暂时在生产部署上功能可能欠缺一些，必须采用其他办法变通，故，生产需谨慎，还是期待正式版吧！
以上即是对sphinx 1.10的2个新特性的体验报告^_^。当然以上的结论只是因个人在工作中可能会遇到的问题而提出的，我不能期望sphinx完全取代数据库
但是，sphinx小弟弟，你能帮就多帮帮你大哥mysql吧，你看他每天累得cpu冒汗，还分布式的累，不容易啊！