like匹配标签字段的关键是确认真实存储格式，需用hex()和length()检查不可见字符，优先用前缀匹配、json函数或生成列索引提升效率。
LIKE 匹配带标签的字段值时，通配符位置决定能否命中
用 LIKE 提取标签数据，核心不是“写对语法”，而是“猜对存储格式”。很多人写 LIKE '%<tag>abc</tag>%' 却查不到，其实字段里存的是 <tag>abc</tag>（HTML 实体）或前后有空格、换行、零宽字符。
- 先用
SELECT HEX(column_name), LENGTH(column_name) FROM table LIMIT 1看真实字节构成，确认是否含不可见字符 - 标签若为固定前缀（如
category:tech），优先用LIKE 'category:tech%'而非LIKE '%tech%'—— 后者可能误中architecture - MySQL 8.0+ 支持
REGEXP_LIKE，对复杂标签结构（如label="urgent|high"）比LIKE更可靠
SUBSTRING_INDEX + LOCATE 截取标签内容最稳，但要注意嵌套和边界
当标签是类似 [status:done] 或 type=web;lang=zh; 这种键值对格式，硬切分比正则更轻量、更可控。关键是别假设分隔符只出现一次。
- 提取
type=web;lang=zh;中的lang值：用SUBSTRING_INDEX(SUBSTRING_INDEX(col, 'lang=', -1), ';', 1)，而不是直接SUBSTRING_INDEX(col, ';', -1) - 如果标签可能重复（如
tags:sql,tags:db,tags:query），LOCATE需配合POSITION或递归 CTE（MySQL 8.0+）才能取全部，单次截取只拿第一个 - PostgreSQL 用户请改用
SPLIT_PART()或REGEXP_MATCHES()，SUBSTRING_INDEX是 MySQL 特有函数
用 JSON_EXTRACT 处理 JSON 标签字段时，NULL 不等于空字符串
现在很多系统把标签存成 JSON 字段（如 {"labels": ["urgent", "backend"]}），这时别再用 LIKE 暴力扫描 —— 效率低且无法利用索引。
-
JSON_EXTRACT(labels, '$.labels[0]')返回带双引号的字符串"urgent"，比较时要写= '"urgent"'或套一层TRIM(BOTH '"' FROM ...) - 字段为
NULL或 JSON 格式错误时，JSON_EXTRACT返回NULL，不是空字符串，WHERE JSON_EXTRACT(...) IS NOT NULL才能过滤有效记录 - MySQL 5.7+ 支持
JSON_CONTAINS(labels, '"urgent"', '$.labels')，比逐个提取再匹配更安全
LIKE 和 SUBSTRING 混用时，ORDER BY 和索引失效是隐形坑
一旦在 WHERE 或 SELECT 中对字段做函数操作（比如 LIKE CONCAT('%', @tag, '%') 或 SUBSTRING(col, 1, 10)），该字段就无法走索引 —— 即使你加了前缀索引也没用。
- 高频查询标签建议建生成列（generated column）：比如
label_prefix VARCHAR(20) STORED AS (SUBSTRING_INDEX(tags, ':', 1))，再给它加索引 - MySQL 8.0+ 可用函数索引：
CREATE INDEX idx_tag ON tbl ((SUBSTRING_INDEX(tags, '=', 1))) - 如果必须模糊查，至少把通配符放在右边：
WHERE tags LIKE 'status:%'能用到前缀索引，LIKE '%status%'完全不能
真正难的不是写出那条 SQL，而是搞清标签在数据库里到底长什么样、谁写的入库逻辑、有没有被其他服务二次转义过。跑一遍 SELECT column_name, DUMP(column_name) FROM ... WHERE ROWNUM = 1（Oracle）或 HEX()（MySQL）比翻文档快得多。
