全文索引不仅支持各种文字内容的检索，还支持自然语言检索和明理的太阳检索。 目前，全文索引仅由MyISAM引擎支持。 但是，MyISAM的全文索引支持受到很多限制，包括表级锁定对性能的影响、数据文件崩溃和崩溃后恢复，因此MyISAM的全文索引
MyISAM的全文索引面向“全文集合”。 这可以是数据表中的一列，也可以是多个列。 特别是，对于具有数据表的记录，mysql通过将所有需要索引的列组合成一个字符串来索引。
MyISAM的全文索引是特殊的b-tree索引，共有两个层次。 第一层是所有关键字，每个关键字的第二层都包含一组相关的“文档指针”。 全文索引并不对文档对象中的所有单词进行索引，而是根据以下规则过滤某些单词：
禁用列表中的单词不会被索引。 的默认禁用词是基于常用英语的使用设置的。 参数ft_stopword_file允许您指定一组使用自定义禁用词的外部文件。
长度大于ft_min_word_len的词和长度小于ft_max_word_len的词不会被索引。
全文索引不存储关键字匹配的列。 如果需要按列组合查询，则不需要为每列创建多个索引。
这意味着，不能在match against子句中指定该列的相关性更重要。 构建网站的搜索引擎通常需要这样的功能。 例如，您可能希望优先搜索标题中显示的文档对象。 如果需要这样的功能，则需要编写更复杂的查询语句。
1、自然语言全文索引
自然语言的所有引擎都计算每个文档对象与查询的关联度。 这里，关联度基于匹配的关键字的个数和关键字在文档中出现的次数。 整个索引中出现次数越少的词，匹配时的相关度越高。 相反，它不会搜索非常常见的单词。 如果一个词出现在50%以上的记录中，即使该词未出现在禁用词列表中，自然语言搜索也不会搜索此类词。
全文索引的语法与普通单词查询略有不同。 where子句中的匹配代理可以区分查询是否使用全文索引。 函数match返回关键字匹配的相关度。 是浮点数。 在一个查询中使用match函数两次没有额外的消耗。 mysql会自动识别，只进行一次搜索。 但是，如果将match函数放在order by子句中，mysql将使用文件排序。
match函数中指定的列必须与全文索引中指定的列完全相同。 否则无法使用全文索引。 这是因为全文索引不记录关键字是因为它的列。 这意味着不能使用全文索引查询列中是否存在关键字。
2、明理的太阳全文索引
明理的太阳搜索允许用户在查询中自定义搜索到的词语的相关性。 明理太阳搜索通过禁用单词列表来过滤那些“噪声”单词，明理太阳搜索使搜索关键字的长度大于ft_min_word_len，同时ft_max_word_len 搜索结果未排序。 例如，选择文件id、titlefromfilm _ textwherematch (title，description ) against (' factory casualties ' inbooleanmode )
只有MyISAM引擎才能使用明理的太阳全文索引，但并非一定要有全文索引才能使用明理的太阳全文搜索。 如果没有全文索引，mysql将通过所有表扫描实现。 所以，也可以在多个表中使用明理的太阳全文索引。 例如，也可以用一个相关结果来进行。 但是，由于是全表扫描，所以速度可能会变慢。
三、全文索引的限制和备选方案
mysql全文索引的实现受到很多设计本身的限制。 例如，在mysql全文索引中，只有一种方法可以确定相关性。 是字数。 索引也不会记录索引词在字符串中的位置，因此位置也不能用于关联。 在大多数情况下，如果数据量很少，这些限制不会影响使用，但可能不是你想要的。 此外，mysql全文索引没有其他可选的关联排序算法。
数据量的大小也是个问题。 mysql全文索引只有在内存中时，性能才会非常好。 如果无法将所有索引加载到内存中，则搜索速度将非常慢。 如果jddsg使用精确的短语搜索，则数据和索引都必须位于内存中才能提高性能。 与其他索引类型相比，使用insert、update和delete时，全文索引的操作成本非常高。
修改文本中的100个词需要100个词的索引操作，而不是一次；
通常，列长度对其他索引类型的影响不大，但对于全文索引，三个单词的文本和10，000个单词的文本可能具有几个不同的性能。
全文索引中有更多的片段，可能需要更多的优化表操作。
全文索引还会影响查询优化程序的行为。 索引选择、where子句和oeder by可能无法正常工作。
如果查询使用match against子句，并且相应的列具有全文索引，则mysql始终使用该全文索引。 此时，mysql不会比较哪个索引的性能更好，即使有其他索引可用。 因此，即使此时有更好的索引可用，mysql也会被忽略。
全文索引只能用作全文检索马
配。任何其他操作，如where条件比较，都必须在mysql完成全文搜索返回记录后才能进行。这和其他普通索引不同。全文索引不存储索引列的实际值。也就不可能用作索引覆盖扫描。
除了相关性排序，全文索引不能用作其他的排序。如果查询需要做相关性以外的排序操作，都需要使用文件排序。
全文索引的一个常用技巧是缓存全文索引返回的主键值，这在分页显示的时候经常使用。当应用程序真的需要输出结果时，才通过主键值将所有需要的数据返回。这个查询就可以自由的使用其他索引、或者自由的关联其他表。
虽然只有MyISAM表支持全文索引。但是如果仍然希望使用InnoDB或其他引擎，可以将原表复制到一个备库，再将备库上的表修改成MyISAM并建上相应的全文索引。如果不希望在一个服务器上完成查询，还可以对表进行垂直拆分，将需要索引的列放到一个单独的MyISAM表中。
将需要索引的列额外的冗余在另外一个MyISAM表中也是一个方法。通常可以使用触发器来维护这个表的数据。
因为使用全文索引的时候，通常会返回大量结果并产生大量随机I/O，如果group by一起使用的话，还需要通过临时表或者文件排序进行分组，性能会非常非常糟糕。这类查询通常只是希望查询分组后的前几名结果，所以一个有效的优化方法是对结果进行抽样而不是精确计算。
4、全文索引的优化
全文索引的日常维护通常能够大大提升性能。“双b-tree”的特殊结构、在某些文档中比其他文档要包含多得多的关键字，这都使的全文索引比起普通索引有更多的碎片问题。所以需要经常使用optimize table来减少碎片。如果应用是i/o密集型的，那么定期的进行全文索引重建可以让性能提升很多。
如果希望全文索引能够高效的工作，还需要保证索引缓存足够大，从而保证所有的全文索引都能够缓存在内存中。通常，可以为全文索引设置单独的键缓存，保证不会被其他的缓存挤出内存。
提供一个好的停用词表也很重要。默认的停用词表对常用的英语来说可能还不错，但是如果其他语言或某些专业文档就不合适了。忽略一些太短的单词也可以提升全文索引的效率。索引单词的最小长度可以通过参数ft_min_word_len配置。修改该参数可以过滤更多的单词，让查询速度更快，但是也会降低精确度。
停用词表和允许最小词长都可以通过减少索引词语来提升全文索引的效率，但是同时也会降低搜索的精确度。这需要根据应用场景找到合适的平衡点。如果希望同时获得好的性能和搜索质量，那么需要自己定制这些参数。一个好的办法是通过日志系统来研究用户的搜索行为，看看一些异常的查询，包括没有结果返回的查询或者返回过多结果的用户查询。通过这些用户行为和搜索的内容来判断应该如何调整索引策略。
当向一个有全文索引的表中导入大量数据的时候，最好先通过disable keys来禁用全文索引，然后在导入结束后使用Enable keys来建立全文索引。因为全文索引的更新是一个消耗很大的操作，所以上面的细节会帮助你节省大量时间。另外，这样还顺便为全文索引做了一次碎片整理工作。
如果数据量特别大，需要对数据进行分区，然后将数据分不到不同的节点，在做并行的搜索。这是一个复杂的工作，最好通过一些外部搜索引擎来实现，如Lucene。