必须先安装fuzzystrmatch扩展，否则levenshtein()函数不存在；该函数返回编辑距离（越小越相似），非归一化相似度，不可简单换算百分比，需依业务设定阈值。
必须先装扩展，否则levenshtein()根本不存在
PostgreSQL 默认不带 levenshtein() 函数，直接调用会报错 function levenshtein(text, text) does not exist。这不是拼写错误，是扩展没启用。
执行前确认你有数据库 owner 或 superuser 权限：
CREATE EXTENSION IF NOT EXISTS fuzzystrmatch;- 如果提示权限不足，得找 DBA 执行；普通用户无法绕过
- 扩展只需运行一次，不是每次查询都要装
levenshtein() 返回的是编辑距离，不是相似度百分比
它算的是“最少改几次字符才能让两个字符串一样”，结果越小越相似，但数值本身没有归一化。比如：
SELECT levenshtein('cat', 'dog'); -- 返回 3
SELECT levenshtein('cat', 'cats'); -- 返回 1
SELECT levenshtein('a', 'abcde'); -- 返回 4这些数字不能直接当“相似度 80%”用。常见误区是拿它除以长度硬算比例，比如 1 - levenshtein(a,b)/GREATEST(LENGTH(a),LENGTH(b))，这在长短差异大时严重失真——'a' 和 'abcde' 算出来是 0.8，显然不合理。
真正该做的是结合业务定阈值：
- 人名查重：
levenshtein(name1, name2) 可能合理 - 地址比对：
可能只是邮编差一位，得看字段平均长度再调 - 避免在
WHERE中对大表全量计算，性能会断崖下跌
子字符串模糊匹配不能直接用levenshtein()
如果你要从长文本（如商品描述）里找近似包含 “posthole” 的行，levenshtein(description, 'posthole') 是错的——它比的是整段 description 和 “posthole” 的距离，不是“description 里有没有接近 posthole 的子串”。
正确思路是滑动窗口切分 + 循环比较，但 PostgreSQL 原生不支持高效实现。实用方案只有两个：
- 用
pg_trgm的%运算符或similarity()，它天然适合子串级相似（比如'posthole' % description） - 把长字段预处理成关键词数组，再用
unnest()拆开逐个比levenshtein()，但要注意空格、标点清洗 - 更稳的做法：把模糊匹配逻辑移到应用层（Python/Go），数据库只做等值或前缀索引加速
性能敏感场景必须用levenshtein_less_equal()
当只需要知道“距离是否 ≤3”，而不在乎具体是 1 还是 3 时，levenshtein_less_equal(str1, str2, 3) 比 levenshtein() 快得多。它内部做了剪枝，一旦发现距离超限就立刻返回，不继续算。
注意参数顺序和行为：
-
levenshtein_less_equal('kitten', 'sitting', 2)返回3（因为实际是 3 > 2） -
levenshtein_less_equal('kitten', 'sitting', 3)返回3（精确值） - 第三个参数为负数时，退化为普通
levenshtein() - 别在 JOIN 条件里滥用，仍会触发大量计算
字符集也得盯紧：确保数据库是 UTF8 编码，否则含中文字段时，levenshtein() 按字节算，一个汉字算三步，结果完全不可信。
