问我应该选择全文索引还是locate() position()函数？

EN

在我收到一个慢sql警告2周后，我的sql性能出现了问题。

首先，我需要指出的是，在shop_name列中有很多冗余。因为它目前记录了客户交易的所有历史记录。它看起来是这样的：“(抖音)澳贝母婴旗舰店21/02，(抖音)澳贝母婴旗舰店21/02，(抖音)澳贝母婴旗舰店21/02，(抖音)澳贝母婴旗舰店21/02”or“广东荔枝红文化传媒有限公司，(抖音)澳贝母婴旗舰店21/02”.

也许我会将这一列拆分为一个新的关系表。这将在稍后的讨论中讨论。

这个查询表的大小约为300k。数据长度约为300MB，索引长度为37MB。

下面的代码在执行时搜索fullText索引，而我则在执行解释。它的运行时间是4s，这有点不可接受。

SELECT
    * 
FROM
    customer c 
WHERE
    receiver_mobile_decrypted IS NOT NULL 
    AND c.decrypted_flag = 1 
    AND c.updated_flag = 1 
    AND MATCH ( c.shop_name ) against ("*抖音*" IN boolean MODE ) 
ORDER BY
    create_time DESC 
    LIMIT 1200;

下图是sql执行的说明。奇怪的是，我在最新的navicat客户端中找不到全文初始化。但我看到这一步在生产环境中花费了大约99.455%的时间。在prod环境中，navicat在旧版本中运行。你知道，我不能在生产环境中截取细节。这就是我所能提供的。

for sql1 for sql1

下面的其他sql替换了"match even“into position()或locate()，甚至like函数也能获得更高的性能。运行时间为1.1秒。

SELECT
    * 
FROM
    customer c 
WHERE
    receiver_mobile_decrypted IS NOT NULL 
    AND c.decrypted_flag = 1 
    AND c.updated_flag = 1 
    and position("抖音" in c.shop_name) >0
ORDER BY
    create_time DESC 
    LIMIT 1200;

我想向你提供这次执行的细节。for sql2 for sql2

在目前的情况下，我将我的sql修改为现在可以接受的第二个。但如果你能给我任何提示或建议，我将不胜感激。

更新

当我发布这个问题时，我发现了一些未澄清的问题。

我确实将ngram设置为这个全文索引。因为如果我不这样做，查询结果将与原始的like"%%“函数不同。

我将ngram_token_size设置为2。如下图所示

https://imgur.com/UDRqhno https://imgur.com/BH3dByt