MySQL长URL字段不能直接建完整索引，因InnoDB单列索引上限767字节（utf8mb4下约191字符），超长会报错或截断致选择性暴跌；有效方案是拆解host与path_prefix建复合索引、用REVERSE()建反向索引加速后缀匹配，而全文索引不适用于URL模糊查询。
为什么长URL字段不能直接建完整索引
MySQL单列索引长度上限是767字节（InnoDB默认，utf8mb4下约191个字符），而实际URL动辄500+字符。直接 CREATE INDEX idx_url ON logs(url) 会报错 Specified key was too long，或被自动截断——但截断后前191字符很可能大量重复，索引选择性暴跌，形同虚设。
复合前缀索引要怎么设计才有效
URL模糊匹配常见模式其实是“协议+域名前缀固定，路径动态”，比如查所有 https://api.example.com/v2/% 的请求。这时应把结构化字段拆出来，和前缀索引组合使用：
- 新增
host和path_prefix字段（如取前32字符），用INSERT ... SET host = SUBSTRING_INDEX(url, '/', 3), path_prefix = SUBSTRING(url, LOCATE('/', url, 12), 32)预计算 - 建复合索引：
CREATE INDEX idx_host_path ON logs(host, path_prefix)—— 利用最左前缀原则，WHERE host = 'api.example.com' AND path_prefix LIKE 'v2/%'能精准走索引 - 避免在
url字段上直接LIKE：哪怕加了前缀索引url(64)，一旦查询是url LIKE '%/callback?token=%'，依然全表扫描
后缀匹配（如查所有 .js 文件）怎么用反向索引加速
URL末尾扩展名是典型后缀场景。硬写 url LIKE '%.js' 必定慢。正确做法是加反向列并索引：
- 添加列：
ALTER TABLE logs ADD COLUMN url_rev VARCHAR(512) AS (REVERSE(url)) STORED - 建索引：
CREATE INDEX idx_url_rev ON logs(url_rev) - 查询改写：
SELECT * FROM logs WHERE url_rev LIKE CONCAT(REVERSE('.js'), '%')—— 等价于匹配原URL结尾，且能走idx_url_rev - 注意：如果表写入频繁，需用触发器或应用层同步维护
url_rev，否则数据不一致
全文索引不适合URL模糊匹配的三个事实
别看到 %xxx% 就想上 FULLTEXT。对URL这类非自然语言文本，全文索引反而添乱：
-
MATCH(url) AGAINST('api.example.com' IN BOOLEAN MODE)可能拆出api、example、com三个词，但api.example.com是整体，分词后召回率极低 - 停用词列表默认包含
com、org、www等，一查就丢关键后缀 - 全文索引最小词长默认是4，
/v1/、.js这类短串直接被过滤，查不到
真正难搞的是中间任意位置的子串匹配（如 URL 中含 utm_source=），这种没结构、无规律的全模糊，索引确实帮不上忙——要么加应用层缓存预判，要么接受它就是慢查询，别硬优化。
