LIKE查询需显式用ESCAPE转义%和_，前导%使索引失效，大小写敏感由collation或BINARY控制，简单模糊查优先LIKE，复杂模式才用REGEXP。
LIKE 查询必须注意的通配符转义问题
MySQL 的 LIKE 默认把 % 和 _ 当作通配符，但实际业务中经常要查包含这些字符的原文（比如查手机号以 % 结尾的记录、查字段值为 user_name 的数据）。不加转义会导致误匹配甚至全表扫描。
正确做法是显式指定 ESCAPE 字符，并在待查字符串中转义：
SELECT * FROM users WHERE username LIKE 'admin_%' ESCAPE '';
常见错误写法：WHERE username LIKE 'admin_%' —— 这会匹配 admin1、adminX 等所有下划线后任意单字符的值，不是你想要的字面量下划线。
- 推荐统一用
作 ESCAPE 字符，和大多数编程语言转义习惯一致 - 如果字段内容本身含反斜杠（如 Windows 路径），需写成
\\（SQL 解析一层，LIKE 再解析一层） - 使用参数化查询时（如 Python 的
mysql-connector），注意驱动是否自动处理转义——多数不会，得手动替换→\\
为什么前导通配符（%abc）会让索引失效
当 LIKE 模式以 % 开头（例如 WHERE name LIKE '%john%'），MySQL 无法利用 B+ 树索引的有序性，只能走全表扫描。即使 name 字段有索引，执行计划里也会显示 type: ALL。
可选缓解方式有限，取决于场景：
- 若只查“结尾匹配”，改用
WHERE name LIKE 'john%'—— 这能走索引范围扫描 - 若必须支持任意位置模糊查，且数据量大，考虑引入
FULLTEXT索引 +MATCH ... AGAINST，但仅限 MyISAM 或 InnoDB（5.6+），且对停用词、最小词长敏感 - 避免在高并发 OLTP 场景中长期依赖
%xxx%，容易拖慢整个实例；临时导出类需求可接受
区分大小写的 LIKE 查询怎么控制
MySQL 的 LIKE 是否区分大小写，完全取决于字段的排序规则（collation）。例如 utf8mb4_general_ci 是不区分的，utf8mb4_bin 是区分的。
临时强制区分大小写，可用 BINARY 关键字：
SELECT * FROM logs WHERE BINARY message LIKE '%Error%';
这会让比较按字节进行，'error' 就不再匹配 '%Error%'。但要注意：
-
BINARY会阻止索引使用（除非字段本身就是BINARY类型或_bin排序规则） - 更稳妥的做法是在建表时就选对 collation，比如日志关键字搜索字段设为
utf8mb4_0900_as_cs（8.0+ 的大小写敏感且重音敏感排序规则） - 不要依赖
LOWER()+LIKE组合来“统一转小写”——这同样使索引失效，且多一次函数计算
LIKE 和正则 REGEXP 的性能与语义差异
REGEXP 功能更强（支持分组、量词、字符类等），但代价是解析开销大、几乎无法用索引，且 MySQL 的正则引擎较弱（不支持懒匹配、回溯控制等）。
简单模糊查优先用 LIKE，只有明确需要正则能力时才切过去：
- 查邮箱：用
email REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}$'，LIKE做不了 - 查“以 a 或 b 开头，后跟两个数字”：用
col REGEXP '^[ab][0-9]{2}$'，比拼多个LIKE条件清晰 - 但查“包含 abc 或 xyz”：写成
col LIKE '%abc%' OR col LIKE '%xyz%'通常比col REGEXP 'abc|xyz'快得多
真正难搞的是带复杂通配逻辑又要求高性能的场景——这时候该考虑 Elasticsearch 或 SQLite 的 FTS 模块，而不是硬扛 MySQL 的文本查询。
