MySQL中LIKE查不出带下划线字段，因_是匹配单字符的通配符；需用ESCAPE显式定义转义符（如LIKE 'a$b' ESCAPE '$'）才能匹配字面下划线。
MySQL中LIKE为什么查不出带下划线的字段？
因为 _ 在 LIKE 里是通配符，代表“任意单个字符”，不是字面意义的下划线。比如 SELECT * FROM user WHERE name LIKE 'a_b' 会匹配 abb、a2b，但不会匹配 a_b 本身。
要查真实下划线，得转义：LIKE 'a_b' ESCAPE ''；或者换用更安全的 ESCAPE '$' 避免和路径冲突，写成 LIKE 'a$b' ESCAPE '$'。
- 默认转义符是反斜杠，但 Windows 路径里常见
，容易误逃逸，建议显式声明ESCAPE -
%匹配零或多个字符，_只匹配一个——这点常被忽略，导致模糊范围失控 - 索引对
LIKE 'abc%'有效，但'%abc'或'%ab%'会全表扫描
REGEXP比LIKE快还是慢？什么时候该换用正则？
绝大多数情况下更慢。REGEXP（或 RLIKE）不走索引，且 MySQL 的正则引擎是回溯实现，复杂模式可能指数级耗时。但它能表达 LIKE 做不到的逻辑，比如“以字母开头、后跟3位数字”：name REGEXP '^[a-zA-Z][0-9]{3}$'。
注意：MySQL 8.0+ 支持 REGEXP_LIKE() 函数，语法更标准，但性能模型没变。
- 简单前缀/后缀匹配，坚持用
LIKE 'xxx%'，别为“看起来高级”上正则 - 需要多选一（如邮箱、手机号、身份证格式校验），
REGEXP是合理选择 - 避免在
WHERE中对大字段（如TEXT）用REGEXP，尤其没加 LIMIT
中文模糊搜索用LIKE还是全文索引？
LIKE '%关键词%' 对中文基本等于放弃性能——它没法利用 B+ 树索引做范围跳转，只能逐行扫描 + 字节匹配，遇到 GBK 或 UTF8MB4 编码还可能因多字节边界出错。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
真要支持中文模糊检索，优先建 FULLTEXT 索引 + MATCH ... AGAINST，哪怕只是“包含某词”这种基础需求。它按词分词（依赖内置分词器或 ngram 插件），并支持自然语言模式与布尔模式。
- MyISAM 和 InnoDB 都支持
FULLTEXT，但 InnoDB 要求 MySQL ≥ 5.6 - 默认分词器对中文不友好，必须启用
ngram插件，并建索引时指定WITH PARSER ngram -
LIKE仍可用于极短字段（如昵称 ≤ 20 字）的简单首尾匹配，别硬套在文章正文上
正则里的中文怎么写？常见编码陷阱
MySQL 正则不直接支持 Unicode 属性（如 p{Han}），想匹配中文得靠字节范围。UTF8MB4 下，常用汉字落在 [u4e00-u9fa5] 区间，但这个范围不完整（缺生僻字、扩展A/B区），且 MySQL 不认 u 写法——得用十六进制表示：name REGEXP '[\x{4e00}-\x{9fa5}]'（仅 MySQL 8.0.4+ 支持 \x{...}）。
更稳妥的做法是用字符集相关函数兜底：CONVERT(name USING gbk) REGEXP '[\x81-\xfe][\x40-\xfe]'（GBK双字节中文规则），但跨编码易出错。
- 低版本 MySQL（LENGTH(name) != CHAR_LENGTH(name) 判断是否含多字节字符，再配合
LIKE过滤 - 正则中混用英文、数字、中文时，注意字符集排序规则（collation），
utf8mb4_0900_as_cs和utf8mb4_general_ci对大小写/重音处理不同 - 线上环境别用
REGEXP做实时搜索入口，至少加缓存或降级到LIKE前缀匹配
实际业务里，模糊查询的瓶颈往往不在语法选型，而在数据分布和索引覆盖。比如 LIKE '%xx%' 查不到结果，先看字段是否为 NULL、是否被 TRIM 过、是否用了错误的 collation 导致大小写不匹配——这些比纠结用不用正则更值得花时间。
