直接说结论：数值型字段做模糊查询，数值核心思路就是型用询先把数字变成字符串，再用 LIKE 去匹配。糊查你没法拿 LIKE '%123%' 直接怼在 INT 列上——数据库会报错或者直接忽略，数值因为类型对不上。型用询

我去年处理过一个订单表，糊查用户想在后台搜“包含88的数值订单号”，但订单号是型用询 BIGINT 类型。一开始同事写的糊查是 WHERE order_id LIKE '%88%'，MySQL 直接甩了个 Truncated incorrect DOUBLE value 的数值警告，查出来结果全错。型用询后来改成 WHERE CAST(order_id AS CHAR) LIKE '%88%'，糊查才算跑通。数值

具体写法分数据库。型用询MySQL 里用 CAST 或者 CONVERT 都行：
SELECT * FROM orders WHERE CAST(order_id AS CHAR) LIKE '%88%';
PostgreSQL 更直白，糊查直接 WHERE order_id::TEXT LIKE '%88%'。SQL Server 则是 CONVERT(VARCHAR(20), order_id)。Oracle 用 TO_CHAR(order_id)。

但这里有个坑——一旦对列做了类型转换，索引就废了。订单表几十万行的时候，全表扫描还能忍；等到了千万级，这条查询能把数据库拖死。我见过生产环境因为一个这种查询，CPU 直接飙到 100%，DBA 半夜打电话骂人。

所以别急着写代码，先想清楚业务到底要什么。如果只是“订单号最后四位是 8888”，那用取模运算更快：WHERE order_id % 10000 = 8888，索引照样能用。如果确实要搜“任意位置包含 88”，那老老实实加个冗余字段，比如在插入时同步存一个 order_id_str 的 VARCHAR 类型，然后给这个字段建索引。空间换时间，值。

另一个实际场景是价格区间。有人想搜“价格在 100 到 200 之间，且小数部分带 5”，比如 105.5、150.5。这种需求别用模糊查询，直接用 BETWEEN 100 AND 200 加上 CAST(price AS DECIMAL(10,1)) * 10 % 10 = 5 这种数学判断，清晰又高效。模糊查询看着灵活，实际上在数值上做模式匹配，本身就是反模式。

最后提醒一句：如果你真要用 LIKE 查数值，注意前导零的问题。比如金额存的是 DECIMAL(10,2)，显示成 88.50，但转成字符串后可能是 “88.50” 也可能是 “88.5”，不同数据库的处理方式不一样。最好先统一格式，比如 FORMAT(order_amount, 2) 再匹配，不然查“88.5”和“88.50”结果不一致，用户会以为系统 bug 了。

总结成一句话：能用数学运算解决的就别用 LIKE，非要用就做好索引失效的心理准备，或者提前设计冗余字段。别让数据库在查询时帮你做类型体操，那是给自己埋雷。