text字段无法高效排序，因其不支持完整b-tree索引，导致order by必触发filesort；应改用辅助列、应用层排序或前缀索引等替代方案。
TEXT 字段本身不能直接参与高效排序 —— MySQL 不允许对 TEXT 列建普通 B-tree 索引（除非用前缀，且长度受限），更不支持在 ORDER BY 中直接利用索引避免 filesort。这不是配置或写法问题，而是类型限制决定的。
为什么 TEXT 字段会让 ORDER BY 变慢？
当你执行类似 SELECT * FROM article WHERE status = 1 ORDER BY content DESC LIMIT 10 这样的语句时：
• content 是 TEXT 类型 → 无法建完整索引 → MySQL 无法跳过排序
• 即使加了 WHERE 过滤，只要 ORDER BY 指向 TEXT 列，就大概率触发 filesort
• 如果结果集大，filesort 会先写磁盘临时文件，再归并，I/O 和 CPU 开销陡增
• EXPLAIN 中看到 Using filesort 就是明确信号
TEXT 字段上做 ORDER BY 的替代方案
根本解法不是“优化排序”，而是绕开对 TEXT 列排序的需求：
- 把排序逻辑移到应用层：查出 ID + 排序依据字段（如
created_at、score），在内存里按业务规则排序后，再用 ID 批量查TEXT内容 - 新增一个可索引的辅助列：比如
content_hash（VARCHAR(32)存 MD5）、content_length（INT）、或提取关键词生成summary_keywords（VARCHAR(255)），然后对这些列排序 - 业务上接受近似排序：例如按发布时间倒序，而不是按正文内容排序 —— 大多数场景真正需要的是“最新”或“最热”，而非“按文本字典序”
不得已必须按 TEXT 内容排序时的底线操作
如果真有强需求（比如合规审计要求按原文首段排序），只能妥协但需严控范围：
- 用
SUBSTRING(content, 1, 255)或LEFT(content, 255)提取前缀转成VARCHAR(255)，再建前缀索引：CREATE INDEX idx_content_prefix ON table_name (content(255)) - 确保该前缀能区分绝大多数值；否则重复率高，索引失效，仍会
filesort - 强制使用该前缀列排序：
ORDER BY SUBSTRING(content, 1, 255) DESC，并确认EXPLAIN显示用了索引 - 严禁在大表（>10 万行）上对
TEXT做ORDER BY+LIMIT大偏移，比如LIMIT 100000, 20—— 即使有前缀索引，MySQL 仍要扫描前 10 万行排序
容易被忽略的连锁影响
很多人只盯着 ORDER BY，却没意识到 TEXT 字段还会放大其他问题：
-
SELECT *会把整个TEXT值拉进网络传输和客户端内存，哪怕你只想要前 10 行摘要 —— 应始终显式指定非TEXT列，或用SUBSTRING截断 - InnoDB 行锁粒度受
TEXT影响：更新含TEXT的行时，若该值过大，可能触发额外的页分裂或锁升级 - 备份与主从同步延迟：
TEXT字段体积大会拖慢 binlog 写入和复制解析，尤其在频繁更新时
