继昨天的处理之后，又来新的笔记 ，这次的笔记纯粹是个人的测试，与实际条件有关，比如，我要查询的字段不超过varchar的255的长度，所以我才这么做。
昨天做普通索引后，1100万条记录，索引 为220M，改成全文索引后，索引文件为1.1G，存储空间上，涨了5倍左右。
以下是笔记 ，请不要笑话，场景不同而已
- 经过测试
- title 字段改为全文索引后，在1100万条的时候
- 优点：
- 速度也为0.0x秒级。速度非常快
- 即使有or条件，只要带了limit参数，速度也非常快
- 缺点：
- 如果查询不带limit ,直接卡死，因为他要计算total count
- select count() 卡死
- 如果查询不存在的关键字，卡死
- 优点：
- 使用方法
- 尽量不做select count 查询 （数量低于100万时可以考虑，超过100万时，其实已经没有必要）
- 查询一定要带上limit条件
- 每次查询到不存在的关键字时，记录到关键词库，每次有新增记录时，select 关键词库一下，如果新增房间中有关键字，则将关键词去除，避免卡死
- title 字段改为全文索引后，在1100万条的时候
- 暂时不使用coreseek（sphinx）/xunsearch等第三方工具
- xunsearch只支持分词查询，不支持完全匹配
- 第三方工具，耗内存，而且增量的时候，不够及时