LIKE语句要快而准，应优先使用前缀匹配（如'关键词%'）以利用索引；含中模糊需用FULLTEXT索引；仅当数据量小且必须%关键词%时才妥协。
LIKE 语句怎么写才不慢又准
MySQL 模糊搜索最常用的是 LIKE，但直接写 WHERE name LIKE '%关键词%' 很容易拖垮查询——因为无法走索引。真正能用上索引的只有前缀匹配，比如 WHERE name LIKE '关键词%'（开头固定，后面模糊）。
实战中建议按场景选写法：
- 查“以某字开头”的数据（如用户昵称搜“张”）：用
LIKE '张%'，可命中 B+ 树索引 - 查“包含某字但不固定位置”（如商品名含“蓝牙”）：优先考虑
FULLTEXT索引 +MATCH ... AGAINST，比%蓝牙%快一个数量级 - 必须用
%关键词%且数据量小（FORCE INDEX 无意义，不如加缓存或预计算字段
FULLTEXT 全文索引怎么建才生效
FULLTEXT 不是加了索引就自动支持中文分词。MySQL 原生 FULLTEXT 对中文支持极弱，它按字符切分（utf8mb4 下按单字），没有语义，搜“数据库”会拆成“数”“据”“库”，导致召回率低、误匹配多。
正确做法分两层：
新手企业管理系统源码
下载
新手写的企业网站系统V1.0，开发工具为VS2005+SQLserver，适合初学者练习目前产品购买功能正在开发中，稍做修改即可。可以实现简单的站内模糊搜索功能DB_51aspx下为Sql数据库，附加即可后台登陆地址：/Admin/Logon.aspx后台登陆用户和密码都是：51aspx【该源码由51aspx提供】
- 建索引时指定列和解析器：
ALTER TABLE products ADD FULLTEXT INDEX ft_name_desc (name, description) WITH PARSER ngram;
（ngram是 MySQL 内置中文分词器，需 MySQL ≥ 5.7.6） - 查询时用
IN NATURAL LANGUAGE MODE或IN BOOLEAN MODE：SELECT * FROM products WHERE MATCH(name, description) AGAINST('mysql优化' IN NATURAL LANGUAGE MODE); - 注意：
ngram_token_size默认为 2，意味着只切 2 字词；若要支持“数据库”这种三字词，需在配置文件设ngram_token_size = 3并重启 MySQL
中文模糊搜索绕不开的三个坑
很多项目卡在“明明写了 LIKE 却搜不到”，其实是编码或 collation 导致的隐式转换问题：
-
COLLATION不一致：表用utf8mb4_unicode_ci，但查询条件用了utf8mb4_general_ci，可能导致大小写或重音敏感差异。统一用utf8mb4_0900_as_cs（大小写敏感+重音敏感）更可控 - 字段类型是
TEXT且没加前缀索引：对TEXT列建LIKE 'xxx%'索引，必须显式指定前缀长度，例如：ALTER TABLE articles ADD INDEX idx_title (title(100));
- 参数被拼接进 SQL 但没转义：PHP 中用
mysqli_real_escape_string()，Python 的mysql-connector要用参数化查询，否则' OR 1=1 --直接穿透
LIKE 和 FULLTEXT 性能对比怎么看
别只看执行计划里的 type: range 或 type: fulltext，重点看 rows 和 Extra 字段：
- 用
EXPLAIN SELECT * FROM users WHERE name LIKE '王%';：若rows接近实际匹配数，说明索引有效；若rows是全表行数，检查该列是否真有索引、是否被函数包裹（如UPPER(name)） - 用
EXPLAIN SELECT * FROM products WHERE MATCH(name) AGAINST('ssd');：若Extra出现Using where; Using filesort，说明排序没走索引，得加ORDER BY MATCH(...) DESC强制用全文相关度排序 - 大数据量下，
FULLTEXT查询响应稳定在毫秒级；而LIKE '%xx%'在百万级表上可能超 5 秒，且随数据增长线性恶化
真正上线前，拿线上数据量的 1:1 备份库压测，别信本地 1 万条数据的“很快”。
