longtext字段不能建常规索引，因MySQL禁止对BLOB/TEXT类型创建B+树索引；摘要索引（MD5+SUBSTRING）和垂直拆分是两种高效落地方案，前者适用于内容判等，后者更适合高频读低频更新场景。
直接说结论：longtext 字段本身不能建常规索引，但“摘要索引”和“垂直拆分”是真正能落地、见效快的两种方案；前者适合模糊/关键词检索场景，后者适合高频读取但低频更新的长文本内容。
为什么不能直接对 longtext 字段建索引？
MySQL 明确限制：对 longtext、longblob 等大对象类型，不允许创建普通 B+ 树索引（会报错 ERROR 1170 (42000): BLOB/TEXT column 'xxx' used in key specification without a key length）。即使强行加前缀索引（如 ADD INDEX idx_content (content(100))），也仅对前 100 字节有效——对“包含关键词但出现在第 200 字节后”的记录完全无效，实用性极低。
全文索引（FULLTEXT）虽可支持，但有硬伤：MyISAM 全文索引不支持事务，InnoDB 全文索引要求最小词长（默认 4 字符），且不支持中文分词（需配合插件或外部引擎），线上环境维护成本高。
用 SUBSTRING + MD5 建摘要索引
核心思路：把 longtext 内容的“特征”抽出来，存在一个新字段里，再对这个字段建索引。不是存全文，而是存它的指纹。
- 新增摘要列：
ALTER TABLE articles ADD COLUMN content_digest CHAR(32) NOT NULL DEFAULT ''; - 填充摘要（以 MySQL 8.0+ 为例）：
UPDATE articles SET content_digest = MD5(SUBSTRING(content, 1, 2000));—— 截取前 2000 字符防爆内存，再哈希，确保固定长度、可索引 - 建索引：
CREATE INDEX idx_content_digest ON articles(content_digest); - 查询时改写：
SELECT id, title FROM articles WHERE content_digest = MD5(SUBSTRING('待查文本', 1, 2000));
注意：该方式只适用于“内容基本不变、比对意图是判等而非模糊匹配”的场景（如校验导入文本是否已存在）。若要支持关键词搜索，摘要索引需配合倒排表或转向 Elasticsearch。
垂直拆分到独立表（推荐首选）
把 longtext 字段单独拎到一张关联表里，主表只留 ID 和轻量字段。这是最干净、最易维护、对现有 SQL 改动最小的解法。
- 拆分建表：
CREATE TABLE articles_content (article_id INT PRIMARY KEY, content LONGTEXT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, FOREIGN KEY (article_id) REFERENCES articles(id) ON DELETE CASCADE); - 迁移数据：
INSERT INTO articles_content (article_id, content) SELECT id, content FROM articles;，然后ALTER TABLE articles DROP COLUMN content; - 读取时按需 JOIN：
SELECT a.id, a.title, c.content FROM articles a LEFT JOIN articles_content c ON a.id = c.article_id WHERE a.status = 'published' LIMIT 20;
优势明显：主表体积骤降，SELECT * 不再拖垮网络和内存；articles_content 表可单独做读写分离、归档或压缩存储；更新 content 不锁主表；备份恢复更灵活。
容易被忽略的细节
垂直拆分后，INSERT 和 UPDATE 必须用事务包裹两表操作，否则一致性断裂；摘要索引必须在应用层或触发器中严格同步，漏掉一次就失效；所有涉及 ORDER BY 或 GROUP BY 的查询，如果依赖 longtext 内容生成排序值（比如按内容长度排序），拆分后必须重写逻辑——这些不是“做完就完事”的步骤，而是持续需要兜底的设计点。
