带ORDER BY的MySQL全词匹配查询过慢，求优化方案

补充说明 #

• 查询普通单词实际耗时1.78秒，原提及的4.5秒是查询.vnet这类特殊单词时的耗时（已知REGEXP '\\b.vnet\\b'无法匹配完整的.vnet单词，后续可能用更复杂正则修复，或放弃支持）
• 新增优化方案5

当前查询实现 #

我使用以下MySQL语句实现全词匹配：

SELECT  source, target
    FROM  tm
    WHERE  source REGEXP '\\bword\\b'
      AND  customer = 'COMPANY X'
      AND  language = 'YYY'
    ORDER BY  CHAR_LENGTH(source)
    LIMIT  5;

我的目标是在数十万条英文语句中找出匹配短语的前5条最接近结果——在确保source包含目标单词的前提下，source长度越短匹配度越高，因此按CHAR_LENGTH(source)排序。

表结构 #

CREATE TABLE tm(
    id INT AUTO_INCREMENT PRIMARY KEY,
    source TEXT(7000) NOT NULL,
    target TEXT(6000) NOT NULL,
    language CHAR(3),
    customer VARCHAR(10),
    INDEX src_cus_lang (source(755), customer, language)
);

性能现状与执行计划 #

该查询在配备Intel Core i5-10400F、16GB内存和SSD的电脑上，特殊单词查询耗时约4.5秒，普通单词耗时1.78秒，速度过慢。EXPLAIN执行计划结果如下：

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tm
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1117154
     filtered: 1.00
        Extra: Using where; Using filesort
1 row in set, 1 warning (0.00 sec)

已尝试的优化方案 #

• 方案1：按CHAR_LENGTH(source)排序重建tm表，但希望保留原表顺序，该方案不理想
• 方案2：新增src_len字段存储source长度，但ORDER BY src_len仍过慢
• 方案3：按customer和language将tm表拆分为4个独立表，该方案不理想
• 方案4：为source字段创建索引，仍过慢
• 方案5：使用INDEX(customer, language)，普通单词和特殊单词查询耗时均增加1.4秒

问题 #

是否有方法将执行时间降至0.5秒以内？

内容的提问来源于stack exchange，提问作者zsfzu0