mysql全文索引 很慢，速度不如like的百分之一
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了mysql全文索引 很慢，速度不如like的百分之一相关的知识，希望对你有一定的参考价值。
我遇到的问题就是，mysql的全文索引特别慢，无论是查询还是删除，
删除127条用207秒。
数据量是10W，每条记录的字段不是很大。整个数据库一共230M。
是本机的 mysql
这个是数据表的结构
这个是建的索引
这是两个sql语句
第一个sql的信息
第二个sql的信息
下面是执行的时间，依次是第一个和第二个
接下来，分析下原因：
sql1：执行步骤：先s_a和s_a_t两表笛卡尔集，然后筛选满足on条件的，接着在从结果集中筛选满足where字句的；该过程中处理的记录条目为69*105479，并且未用到任何索引，未用到的原因可能是你先定义了一个复合索引a_concent_split（a_title_split，a_content_split），然后又定义了一个a_content_split2（a_content_split），当引擎执行查找优化时候会先用到a_content_split，可是又由于复合索引是从最左边开始（不能跳过第一个字段），而你却忽略了a_title_split字段，故未能正常使用索引。
sql2：执行步骤：先调用where字句对s_a表进行筛选形成新的s_a表，然后与s_a_t表笛卡尔积，再利用on字句筛选，最后再次利用where字句形成最终结果集；经过第一个where，该过程处理结果集会大幅少于sql1，并且该过程还用到了主键索引。你所设置的fulltext索引再次没有用到，原因是like字句中开始部分为模糊匹配%时候用不了全文索引，这与fulltext存储机制有关。
另，你说的删除速度慢，原因：设置fulltext字段设置太多，fulltext索引在更新删除大量数据时候，需要同步更改索引，你的三个fulltext压力太大！
改进方法：1、删除a_content_split索引重试 2、在删除时候打开delay_key_write变量
有关fulltext比较复杂，用的时候要谨慎设置，还有很多参数也对其有影响
另外sql语句中外连接有关on where字句也是个比较绕的地方，两者你都占了，唉，所以我写的略复杂，前天看到该问题，思忖两天这才作答
望有结果了予以回复交流！追问
好的，这个问题我放一下，明后天在处理，今天还有其他事情要做，
谢谢你，这事好歹有点眉路了，
结果一定告诉你
对数据库有大量数据的读写时,使用读写分离和数据库数据同步来实现数据的读和写
sql server 全文检索 使用
目前项目中的日志查询 功能 由于长年累月的写入，目前已经达到千万级，对日志进行like 查询，速度可想而知。
此处只讨论 在数据库的优化。
当时 想到两个方案，一个是分区，一个 是全文检索。
分区的话，如果跨区，速度也会很慢，并且对区粒度的划分也得考虑，并且既然使用 like ‘%XX%’,必然不会走索引。
所以 选择 sqlserver 的full-text search 功能，该功能类似一个轻量级搜索引擎。
实现步骤：
1. 首先安装sqlserver时，必须选择安装FULL-Text search功能
2. 创建全文目录，如图，右键 创建即可，
3. 在对应的表或者视图上 定义全文索引：注意 表或者视图 必须存在唯一索引，且视图不能包含union，且每个表或者视图，只能有一个全文索引，步骤：选中 表或者视图 --右键--定义全文索引--下一步，直到 选择索引 界面，如果存在全文索引，则系统默认选中，否则，会提示 无有效索引。
4. 选择索引列 ，第3步ok后，点击 下一步 ，选择需要建立全文检索的列，并选择 断字符语言（就类似切词，搜索引擎嘛）
5. 第4步ok后，下面就是 设置 索引填充规则了，上面都有说明，自己 实际 操作 看一下就行了，然后 下一步，直到 定义填充计划 这个页面，这个干什么的呢。 就是 说 我可以 定义一个job定时进行填充以及填充方式（不能每次都完全填充吧，可以是 增量填充或者基于更改的填充，），next.大功告成。
6 修改 查询 sql : cl like ‘%xxx%‘ 改为 contains(cl,‘xxx‘)即可，也可使用 freetext. 剩余 的自己 google吧
以上是关于mysql全文索引 很慢，速度不如like的百分之一的主要内容，如果未能解决你的问题，请参考以下文章