必须配合where过滤才能实现正确权重排序，因locate不参与条件筛选，直接order by会导致无关记录混入；应先用regexp或like在where中缩小结果集，再计算locate权重。
直接用 LOCATE + IF 组合就能实现基础权重排序，但必须配合 REGEXP 或 LIKE 做前置过滤，否则会把不匹配的记录也拉进来算权重——这是最常见的漏查错误。
为什么不能只靠 ORDER BY LOCATE(...)？
LOCATE 返回 0 表示未找到，但它本身不参与 WHERE 过滤。如果跳过 WHERE 条件直接 ORDER BY LOCATE('关键词', col)，结果里会混入大量 weight = 0 的无关记录，分页时极易漏掉真正匹配的行。
- 错误写法：
SELECT *, LOCATE('标题', t1) AS pos FROM test ORDER BY pos DESC→ 返回全部行，包括 t1 里根本没“标题”的记录 - 正确做法：先用
WHERE t1 REGEXP '标题' OR t2 REGEXP '内容'缩小结果集，再算权重 - 注意
REGEXP比LIKE '%关键词%'更灵活（支持|、^、$），但性能略低；简单场景用LIKE更稳
IF(LOCATE(...), weight, 0) 的权重分配陷阱
权重值不是越大越好，得看业务意图。比如标题列权重设为 7，但若该列平均长度远大于内容列，LOCATE 找到的位置偏后，实际“相关性”未必更高——这时单纯加权反而失真。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 常见误配：给主键字段或 ID 列赋高权重（如
IF(LOCATE('x', id), 10, 0)），但id是数字型，LOCATE强转字符串后匹配无意义 - 安全做法：只对明确的文本列（
VARCHAR、TEXT）使用LOCATE，且确保字符集一致（避免 UTF8MB4 下中文被截断） - 调试技巧：临时加上
LOCATE('关键词', t1) AS pos_t1字段，肉眼验证位置值是否合理（正常应 ≥ 1）
多关键词 + 多字段时的权重叠加逻辑
当一个字段要匹配多个词（如“标题”和“摘要”都出现在 t1），LOCATE 只返回首次出现位置，无法体现频次。此时需改用 (LENGTH(t1) - LENGTH(REPLACE(t1, '关键词', ''))) / LENGTH('关键词') 算出现次数，但要注意除零错误。
- 防错写法：
IF(LENGTH('关键词') > 0, (LENGTH(t1) - LENGTH(REPLACE(t1, '关键词', ''))) / LENGTH('关键词'), 0) - 混合策略更实用：标题字段用
LOCATE（看重位置靠前），内容字段用频次计算（看重密度），再加权求和 - 别忽略
WHERE子句的 OR 逻辑：若写成t1 REGEXP 'A|B' OR t2 REGEXP 'C'，只要任一条件成立就保留，但权重计算仍需逐字段判断
真正难的不是写对单条 SQL，而是权重数值得贴合业务反馈——比如用户搜“张三丰”，“张三丰”本人排第一是合理的，但“张三丰剑谱”和“张三丰弟子”谁该权重更高，得靠 AB 测试调参，函数只是工具，数据才是标尺。
