Mysql在2个服务器之间显示不同的结果，并且FULLTEXT索引的数据相同

问题描述

我有一个使用MysqL 5.7.19的本地环境（在Windows 10 Pro法语上）和一个使用MysqL 5.7.31的产品服务器（Ubuntu Linux 16.04.5）。

数据从Prod同步到本地ENV。我有3列的全文索引和一个简单的请求：

SELECT MATCH (r0_.title,r0_.description,r0_.tag_text)
       AGAINST ('+poulet* +carotte*' IN BOOLEAN MODE) AS sclr_0,r0_.id AS id_1,r0_.title AS title_2,r0_.description AS description_3,r0_.url AS url_4,r0_.image AS image_5,r0_.slug AS slug_6,r0_.click AS click_7,r0_.tag_text AS tag_text_8,r0_.active AS active_9,r0_.created_at AS created_at_10,r0_.updated_at AS updated_at_11
    FROM recipe r0_
    WHERE r0_.active = 1
    HAVING sclr_0 >= 1
    ORDER BY sclr_0 DESC;

在本地环境中=> 98个结果
在prod env => 0结果

创建架构：

CREATE TABLE `recipe` (
  `id` int(11) NOT NULL,`blog_id` int(11) NOT NULL,`title` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,`description` longtext COLLATE utf8mb4_unicode_ci NOT NULL,`url` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,`image` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,`slug` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,`click` smallint(6) NOT NULL,`created_at` datetime NOT NULL,`updated_at` datetime NOT NULL,`tag_text` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,`active` tinyint(1) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

ALTER TABLE `recipe`
  ADD PRIMARY KEY (`id`),ADD KEY `IDX_DA88B137DAE07E97` (`blog_id`),ADD KEY `IDX_DA88B1374B1EFC02` (`active`),ADD KEY `IDX_DA88B1378B8E8428` (`created_at`);
ALTER TABLE `recipe` ADD FULLTEXT KEY `IDX_DA88B1372B36786B6DE44026D5841871`
        (`title`,`description`,`tag_text`);

有关Prod的更多数据实际上是因为有新配方，但没有结果。

解决方法

relevancy score是根据完整表的内容计算的：

InnoDB使用“术语频率-反文档频率”（TF-IDF）加权系统的一种变体来对给定的全文本搜索查询排名文档的相关性。 TF-IDF权重基于单词在文档中出现的频率，被单词在集合中所有文档中出现的频率抵消。换句话说，单词在文档中出现的频率越高，单词在文档集合中出现的频率越低，文档的排名就越高。

此处的“文档”表示单行，“文档集合”表示所有行。手册中包含确切的公式，但重要的是：由于与本地相比，您在产品上的食谱更多，因此得分会有所不同。如果您例如添加了更多包含菜谱的食谱，分数将降低；如果添加了不包含搜索词的食谱，则分数将升高。

这完全独立于单个结果的实际效果！鸡肉炖胡萝卜很适合您的搜索，但是如果您的数据库中也有胡萝卜糕的食谱，则绝对评分会有所不同。

因此，分数本身的绝对值通常不是过滤的好标准，例如与您的where score > 1一起使用，但是作为一种排序结果的方式，例如order by score desc，通常包括limit。

您不太可能会找到总的来说合理的绝对最小值（0除外）：

如果您现在发现一个不错的价值，那么如果胡萝卜变得更受欢迎并且您为它们添加食谱（类似于您在产品上的经验），则可能在2周内过高。反之亦然，如果您使用特定的值1来消除不必要的较低分数结果，那么如果您添加与胡萝卜无关的食谱，它们可能会在2周内重新出现-不是因为这些不需要的结果突然好转，而是因为它们变得稀有。
如果您发现一个适合包含胡萝卜的搜索的合适值，则对于其他搜索词可能不是一个合适的值。如果您例如搜索常用成分（例如“糖”），即使绝对值很低，您仍然会期望包含“糖”的结果-仅仅是因为它比胡萝卜使用得更多。

但是，经常使用单词sugar的食谱（因为它可能是重要的成分，也许是焦糖食谱）比只提到一次的食谱（“加点糖”）得分更高），因此您可以使用该值对结果进行相对排序。

full-text-search fulltext-index indexing indexing mysql resultset resultset