最开始展示一下两个极其类似的SQL查询语句

SELECT *FROM saas_knowledge_container kcWHERE kc.tenant_id = '1953660902800752640'AND type <> 'PERSONAL_KNOWLEDGE'AND (kc.visibility_range = 'ENTERPRISE_PUBLIC'OR (kc.visibility_range = 'MEMBERS_ONLY'AND EXISTS (SELECT 1FROM saas_knowledge_container_permission pLEFT JOIN kb_department dON d.code = p.membership_codeWHERE p.container_id = kc.codeAND p.tenant_id = kc.tenant_idAND ((p.membership_type = 'USER'AND p.membership_code = '1958104631190691840')OR (p.membership_type = 'ORGANIZATION'AND ((d.full_path LIKE concat('%', '1958103924488216576,1958103969639899136,1958104007833231360', '%'))))))));

 select *FROM saas_knowledge_container kcWHERE kc.tenant_id = '1953660902800752640'AND type <> 'PERSONAL_KNOWLEDGE'AND ( kc.visibility_range = 'ENTERPRISE_PUBLIC'OR ( kc.visibility_range = 'MEMBERS_ONLY'AND exists (SELECT 1FROM saas_knowledge_container_permission pLEFT JOIN kb_department dON d.code = p.membership_codeWHERE p.container_id = kc.codeAND p.tenant_id = kc.tenant_idAND ( (p.membership_type = 'USER'AND p.membership_code = '1958104631190691840')OR ( p.membership_type = 'ORGANIZATION'AND ( ( d.full_path like concat('%', '1958103924488216576', '%')OR d.full_path like concat('%', '1958103969639899136', '%')OR d.full_path like concat('%', '1958104007833231360', '%') ) ) ) ) ) ) ) order by kc.create_time desc

上述两个SQL，除了最后的full_path路径匹配规则不一样，其余都相同。上述两个SQL的效果是SQL1查询不出数据📊，SQL2可以查询出对于的数据。一开始看对着SQL的寓意进行分析没有发现明显的问题。。。。

为什么会出现数据一个有一个无，需要了解一下mysql中的like用法。

• 第一条语句把 3 个组织 ID 用逗号串成一个整体去 LIKE： LIKE concat('%', '1958103924488216576,1958103969639899136,1958104007833231360', '%') 等价于 LIKE '%1958103924488216576,1958103969639899136,1958104007833231360%'

• 第二条语句把 3 个 ID 拆开，各自独立 LIKE： ... LIKE '%1958103924488216576%' OR ... LIKE '%1958103969639899136%' OR ... LIKE '%1958104007833231360%'

  还是问问AI给我分析一下是为什么，我迷茫了

  

所以按照上述AI提供的排查思路，我开始对数据进行分析，查询当前记录是否真的存在特殊字符

SELECT hex(full_path)
FROM kb_department
WHERE code = '1958104007833231360';

如果看到 20（空格）、0A（换行）、EF BB BF（BOM）、E2808B（零宽空格）等，就说明肉眼看不见的东西混进去了。 解决：UPDATE 去掉这些字符，或把 LIKE 模式前后各加一个 %。

但是期待的结果并没有出现

于是后续继续按照别的思路进行排查，是不是visibility_range没有命中，还是COUNT(*) > 0 但带 LIMIT 36 的语句不返回 → 就是 ORDER BY kc.create_time DESC 把这条记录挤到 36 行之外。结果尝试之后都不是。。。。

问题解决

思考了半天，终于在最后想到了原因。话不多说，继续来看两个SQL。

select * from kb_department where code = '1958104007833231360';

select * from kb_department where code = '1958103924488216576';

看到这里应该也发现原因，用户所在的部门编码是1958103924488216576，对应的全路径是1958103924488216576。使用like进行全匹配的规则不服务第一个查询不出的sql中全路径匹配规则，所以需要在路径获取到之后，其中之一也是比较好的解决方案的方式，可以通过代码进行一个字符串逗号分隔～,使用这种能避免一个字符集等问题，要是mysql中有Java一样的contains语法就好了！

// 在调用Mapper之前，先处理字符串分割
List<String> processedOrgCodes = new ArrayList<>();
for (String orgCode : orgPermissions.getOrganizationCodes()) {if (orgCode != null && orgCode.contains(",")) {// 分割逗号分隔的字符串String[] codes = orgCode.split(",");for (String c : codes) {if (c != null && !c.trim().isEmpty()) {processedOrgCodes.add(c.trim());}}} else if (orgCode != null && !orgCode.trim().isEmpty()) {processedOrgCodes.add(orgCode.trim());}
}