为什么MySQL查询的搜索字符串增加1-2个字符时执行时长不成比例变长？

• 你的查询没有触发已创建的FULLTEXT索引，全程走全表扫描：LIKE '%xxx%'的前后通配语法无法触发常规B树索引，而MySQL只有使用MATCH() AGAINST()语法时才会调用FULLTEXT全文索引，所以你所有的LIKE查询都是逐行扫描全表4万条记录、逐条匹配每条6万字符的text字段。
• 耗时跳变的核心是混合字符触发了排序规则的额外校验开销：你表的默认字符集为latin1，但text字段单独设置为utf8，排序规则为utf8_general_ci。当匹配串是纯数字（202）或纯字母（information）时，这类字符在utf8编码中属于单字节兼容字符，utf8_general_ci的匹配逻辑可以直接调用快速字符串匹配算法（BM/KMP）执行，开销极低；当匹配串混合数字和字母（2020i、information2）时，utf8_general_ci的不区分大小写+字符归类校验逻辑会被触发，需要逐字符做编码转换和归类值匹配，开销直接提升上百倍，正好对应你从0.05秒涨到15~17秒的耗时差。
• 你可以做验证：将text字段的排序规则改为utf8_bin后再执行混合字符的LIKE查询，耗时会直接回落至0.05秒级别，因为utf8_bin直接按二进制值匹配，不需要额外的归类校验步骤。

• 优先改用FULLTEXT索引查询语法，性能会提升至少2个量级，示例代码如下：

SELECT * FROM `table` 
WHERE MATCH(text) AGAINST('+15 +10 +2020i' IN BOOLEAN MODE);

• 如果必须保留LIKE查询逻辑，建议统一表和字段的字符集，避免隐性字符集转换开销；业务允许的前提下将text字段的排序规则改为utf8_bin，可大幅降低混合字符的匹配开销。
• 长期建议将MyISAM引擎替换为InnoDB，MyISAM已被MySQL官方废弃，InnoDB的全文索引实现性能、稳定性都远优于MyISAM。

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