例如我搜索“日内瓦协议”可以搜索到内容，但我搜索“日内瓦”或者“协议”就无法搜索得到。内容并不多，我不需要实现中文分词，只需要匹配到文字就行了。能否把Zend_Search_Lucene改为关键字直接匹配呢？

执行的sql是这个 {代码...} 当索引是user_id,asset,business,business_id的联合索引时，执行计划如下 当索引是user_id,asset的联合索引时，执行计划如下 为什么联合索引多加了两个额外字段，导致这个分组查询效率下降呢？

搜索内容时发现内容长度一定时，搜索按钮会遮挡搜索内容，且内容可以无限增加搜索内容时内容长度比较长时，界面会发生崩溃个人认为可以加入限制搜索字长来解决这个问题

比如你创建了 name,age 的覆盖索引，那么 MySQL 会为你创建一棵 B+ 树。可以认为每一个节点都是一个 key-value 结构，key 是覆盖索引 (name,age) 的哈希值，并且这棵树是以 name,age 进行排序的，value 是主键的值，也就是 id。

测试了下，只要条件中有 or 就不会使用索引（包括组合索引和单列索引）

mysql中在大数据表中直接创建索引和将相关的索引的字段提取出来作为单表建索引的有什么不一样的? “如一个表中有500万数据，创建了两个索引" 和 "将这个表里创建索引的字段分离出来单独存储为一个表，然后再创建一个索引" 两种方法在在查询的时候，速度有明显的区别么？

通过 command + shift + p (win/linux ctrl + shift + p) 打开 st 的命令面板，输入 stylus 关键字，进行筛选

这个是设计到mysql索引的最左原则。mysql的索引为什么是执行的最左原则的，是由于索引就是B＋树，而联合索引实际上也是一棵B＋树，是按左到右的顺序排序的，所以搜索的时候会从左到右。

1.因为你索引查了之后需要回表 优化器认为你回表的开销太大 不如直接遍历全表2.字面意思，就是可能用到的索引3.看你的业务需求，比如你只需要返回几个字段而不是全部，可以考虑使用覆盖索引。你也可以force index，强制使用索引，看看走索引快还是全表扫描快（优化器是有误判可能的），如果索引快你就强制索引

如图，网站有个公共的头部组件header.vue 里面有个搜索框在非搜索页面 我点击搜索可以用router push到搜索结果页面search.vue,能够正常获取数据，但是在搜索结果页面再点击搜索，却不获取数据，因为路由没有变化 只是传的搜索参数发生变化，监听路由并不能达到重新获取数据的效果，这个如何解决呢

一、索引的资源消耗分析 1、索引三大特点 　　1、小：只在一个到多个列建立索引 　　2、有序：可以快速定位终点 　　3、有棵树：可以定位起点，树高一般小于等于3 2、索引的资源消耗点 　　1、树的高度，顺序访问索引的数据页，索引就是在列上建立的，数据量非常小，在内存中； 　　2、数据之间跳着访问 　　　　1、索引...

当数据库表中没有建立主键和主键索引时时，而又建立了二级索引（或者说是辅助索引），那么此时二级索引的叶子节点下挂的是什么？

从你的explain中能看出。一共检索 91585 行。4秒肯定索引建立不正确。 起到作用的索引 u.appid，m.user_id_ix。你应该 u.id ,m.uid 建立相应的索引或外键。

试过 type=rt 的实时索引 但是遇到了两个问题1 首先rt索引插入数据后 不能搜索中文?2 rt是不是不能合并到主索引? 问题示例:我修改了一个很久以前的一个数据name字段(中文值) 我如何将修改同步到主索引呢 {代码...}

关于count()优化，在 MySQL 5.7.18 版本之后，最好建立一个更小的二级索引。 我知道聚集索引比二级索引臃肿，但是如果仅仅是计数，不用扫描整个数据行吧，只看索引多少项不就行了，为何二级索引能让count更快？

B+Tree 索引都是有顺序的，'InnoDb的辅助索引是非顺序存储的' 可能理解错了 InnoDB 中，假设非覆盖索引，通过辅助索引排序输出的过程是：扫描排好序的辅助索引树，然后通过主键回表拿到行数据，再发送到客户端