MySQL对长字符串不能直接建FULLTEXT或普通B+树索引，因前者不支持等值查询和短词检索，后者易超长报错且效率低；前缀索引需权衡选择性与空间，建议选择性≥0.95，注意utf8mb4下字符数与字节换算及3072字节限制。
MySQL 对长字符串建索引为什么不能直接用 FULLTEXT 或普通 B+ 树索引？
因为 VARCHAR(1000) 或 TEXT 字段直接建普通索引，InnoDB 会尝试存储完整值（超长时可能报错 ERROR 1071: Specified key was too long），即使成功，索引体积大、写入慢、缓存效率低。而 FULLTEXT 只适用于全文检索场景（如模糊匹配关键词），不支持等值查询或 ORDER BY，且对单字节字符集（如 utf8mb4）有最小词长限制（默认 4），短字符串或英文缩写查不到。
前缀索引长度怎么选才既节省空间又不失区分度？
核心是平衡「索引大小」和「选择性（selectivity）」：太短 → 大量重复前缀 → 查询走索引后还要回表过滤，效果差；太长 → 接近全字段索引，失去前缀意义。实际操作分三步：
- 用
SELECT COUNT(DISTINCT LEFT(column_name, N)) / COUNT(*) FROM table_name;测不同N下的选择性，目标值建议 ≥ 0.95（即 95% 的值能被前缀唯一区分） - 结合常见查询模式：如果
WHERE name = 'zhangsan'频繁出现，优先保证前 5~8 个字符的区分度；如果是邮箱字段，@前部分往往足够（如LEFT(email, 12)覆盖大部分user123@domain） - 注意字符集：
utf8mb4下一个汉字占 4 字节，但前缀长度按「字符数」算，不是字节数 ——INDEX idx_name (name(10))表示前 10 个字符，不管实际占多少字节
创建前缀索引时容易忽略的两个硬限制
一是 InnoDB 单列索引前缀最大长度为 3072 字节（MySQL 5.7+），但受行格式和字符集影响：例如 utf8mb4 下，3072 字节最多支持 768 个字符（3072 ÷ 4），所以 name(1000) 会直接报错；二是 JSON、GEOMETRY 等类型不支持前缀索引，必须用生成列（generated column）配合虚拟索引。
典型错误：ALTER TABLE users ADD INDEX idx_bio (bio(2000)); 在 utf8mb4 下大概率失败，应先确认 SHOW VARIABLES LIKE 'innodb_large_prefix'; 是否为 ON，再检查当前 ROW_FORMAT 是否为 DYNAMIC 或 COMPRESSED。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
前缀索引会影响哪些查询行为？
它只加速「前缀匹配」类操作，其他情况会失效：
-
WHERE column LIKE 'abc%'✅ 有效 -
WHERE column = 'abcdef'✅ 有效（等值查询依赖前缀唯一性） -
WHERE column LIKE '%abc'❌ 不走索引（无法利用 B+ 树结构） -
WHERE column LIKE '%abc%'❌ 同上 -
ORDER BY column⚠️ 仅当排序字段就是该前缀索引的最左前缀，且无其他非索引字段参与时才可能用上
真正难处理的是「需要排序 + 分页 + 长字符串等值过滤」的组合，这时前缀索引往往不够，得考虑冗余生成列（如 email_prefix VARCHAR(32) AS (LEFT(email, 32)) STORED）再建索引。
前缀索引不是“设个数就完事”，关键在验证选择性、卡死字符集换算、避开隐式类型转换——比如把 INT 字段转成字符串再前缀索引，性能反而更差。
