必须先用replace清洗空格和横线，再结合length=11与like '1[3-9]%'匹配号段；sqlite需用glob多段拼接，mysql 8.0+推荐regexp并锚定^$，且应避免where中实时正则以保性能。
WHERE子句里用LIKE匹配11位手机号要加什么通配符？
直接写 WHERE phone LIKE '1%' 会漏掉非1开头的号段（比如虚拟运营商号），也拦不住带空格或横线的脏数据。真正要匹配标准大陆11位手机号，得先统一清洗格式，再用 LIKE 或正则。MySQL 8.0+ 支持 REGEXP，但老版本只能靠 LIKE 拼凑：
- 先用
REPLACE(REPLACE(phone, '-', ''), ' ', '')去掉常见分隔符 - 再用
LENGTH(...)=11 AND phone LIKE '1[3-9]%'锁定长度和号段（注意：不能只写'1%'，否则会命中12位或含字母的值） - 如果字段里混有+86前缀，得额外处理：
REPLACE(phone, '+86', '')
PostgreSQL里用SIMILAR TO还是~做手机号校验？
SIMILAR TO 语法看着像SQL标准，但实际支持有限，且不支持量词嵌套；~（正则匹配）更灵活也更常用。关键点是：必须用 ^ 和 $ 锚定首尾，否则 '13812345678abc' 这种也会被误判为匹配：
- 正确写法：
phone ~ '^1[3-9]\d{9}$' - 错误写法：
phone ~ '1[3-9]\d{9}'（缺少锚点，子串匹配） - 如果字段含空格，先用
TRIM(phone)，别依赖正则里的\s*——有些版本对Unicode空白支持不稳
SQLite没有原生正则，怎么安全过滤手机号？
SQLite默认不带 REGEXP 函数，强行启用需要编译时加扩展，生产环境通常不敢开。替代方案是组合 LENGTH + LIKE + 字符判断：
- 长度必须是11：
LENGTH(phone) = 11 - 首字符是1：
substr(phone, 1, 1) = '1' - 第二位在3–9之间：
substr(phone, 2, 1) IN ('3','4','5','6','7','8','9') - 剩下9位全为数字：
phone GLOB '1[3-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'（GLOB支持[0-9]，但不支持\d）
WHERE里用正则会不会拖慢查询性能？
会，而且很严重——几乎所有数据库对正则字段都无法使用索引（除非建函数索引，如 PostgreSQL 的 CREATE INDEX ON users ((phone::text))）。实际优化路径只有两条：
- 把清洗后的标准手机号存在单独字段（如
phone_clean），对该字段建普通B-tree索引 - 避免在
WHERE里实时计算：WHERE LENGTH(REPLACE(phone,'-','')) = 11这种表达式无法走索引 - 如果必须查原始字段，考虑加生成列（MySQL 5.7+ / PG 12+）并索引它，而不是每次SELECT都跑一遍正则
真正上线前，拿真实数据量 EXPLAIN 一下，别信“看起来能跑”。手机号字段一旦没索引，百万级表上一个 REGEXP 就可能卡住整个连接池。
