MySQL中对CASE结果、格式化DATETIME列使用LIKE运算符问题

SQL执行顺序决定了原写法必然出现匹配错位：

• MySQL执行查询时，WHERE子句的执行阶段早于SELECT子句的字段计算、别名生成。当WHERE条件运行时，DATE_FORMAT生成的dateAdded/datePlannedReturn格式化文本、CASE生成的permission权限文本都还没计算完成，数据库只能拿到原始的DATETIME类型值、u.accoutPermission整数值做匹配，自然无法命中格式化后的文本结果。
• 原写法在WHERE中直接引用SELECT定义的别名本身属于MySQL的非标准语法兼容，本身就存在逻辑歧义，不推荐使用。

你调整后的HAVING + LOCATE + CONCAT_WS写法是可行的，逻辑上完全解决了之前的匹配错位问题：

• HAVING子句执行在SELECT计算完成之后，这时候所有返回列的计算结果、别名都已经生成，引用别名匹配到的就是最终返回给前端的展示值，和用户实际看到的内容完全一致。
• 相比堆叠数十个OR LIKE的写法，拼接后统一匹配的写法维护成本更低，代码更简洁。不过要注意补充分隔符参数，避免跨列拼接导致的误匹配：

-- CONCAT_WS第一个参数传不会出现在业务内容里的分隔符，比如竖线，避免相邻列的内容拼接后误命中搜索词
HAVING LOCATE('search term', CONCAT_WS('|', i.itemID, b.brandname, c.categoryName, p1.fname, p1.lname, p2.fname, p2.lname, dateAdded, datePlannedReturn, permission)) > 0

关于“无需逐一指定列”的全列搜索需求，并不推荐实现：

• 虽然可以通过子查询包裹主体逻辑、外层拼接*所有列实现免列名枚举，但这种写法会把不需要对外暴露的内部字段（比如内部状态标记、原始权限值、用户敏感字段）都纳入搜索范围，很容易出现意料之外的搜索结果泄露问题，维护性也很差。
• 实际业务场景下手动指定需要参与搜索的展示列是更稳妥的选择，后续新增/删除返回列时同步调整搜索列列表即可，逻辑可控。

最后补充性能相关的注意点：

• 因为你用的是前后带通配的模糊匹配，不管是LIKE '%关键词%'还是LOCATE匹配，都无法用到常规索引，两种写法性能差异极小，拼接匹配的写法稳定性更好。
• 如果后续单表数据量涨到百万级以上，多列模糊匹配的性能会明显下降，到时候再考虑接入独立的全文检索引擎覆盖多类型字段、多列的搜索需求即可，MySQL原生FULLTEXT索引对非文本字段、计算列的支持局限很大，没必要强行适配。

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