在业务系统中，订单备注、文章正文、日志详情等数据常使用TEXT、MEDIUMTEXT或BLOB这类长文本字段存储。当我们在列表页或报表查询中直接书写SELECT * FROM table，数据库不得不把每行庞大的文本一并读出，再通过数据库连接送往应用层。这种无差别返回会显著放大磁盘读取量和网络传输量，成为接口变慢和数据库连接占满的主要诱因。解决思路并不复杂，核心在于让查询只带回真正需要的那一部分内容。
为什么长文本字段会拖累查询性能
关系型数据库在执行查询时，如果SELECT列表里包含长文本列，存储引擎通常无法只靠索引完成覆盖扫描，必须到数据页甚至溢出的行外页去读取真实内容。以MySQL的InnoDB为例，超过一定长度的TEXT会存放在独立的溢出页中，读取时产生额外随机IO。当结果集行数较多，这些零碎读取会累积成惊人的吞吐压力。
从应用视角看，服务层接收到完整长文本后往往只截取前几句做展示，其余字节纯粹浪费了网卡带宽与JVM或运行时内存。尤其在移动网络或跨机房调用场景下，几MB的响应体会直接拉高延迟。因此，控制返回字段的“体积”比单纯加索引更立竿见影。
选择性返回的常见实现方式
使用字符串函数截断返回
最直接的方法是借助数据库内置函数，只取长文本的前若干字符。下面以MySQL为例，在列表查询中仅返回备注的前50个字：
SELECT id, user_id, SUBSTRING(remark, 1, 50) AS remark_preview, created_at FROM orders WHERE status = 1 ORDER BY created_at DESC LIMIT 20;
上述写法让网络包大小从可能的数MB降到几KB。应用拿到remark_preview后足以渲染摘要，用户点进详情时再发起一次按主键查询全文的请求。这种分屏加载既减轻了列表接口负担，也符合多数产品的交互习惯。
需要注意的是，SUBSTRING在部分数据库中对多字节字符（如UTF-8中文）是按字符数而非字节数截取，行为相对安全；但若使用LEFT或SUBSTR的字节版本，要留意截断乱码问题。同时，该函数仍会读取原文本再计算，极端大字段下可结合生成列或冗余摘要列进一步优化。
用CASE表达式按需返回全文
有些场景需要根据条件决定是否取全文，比如后台导出任务要看完整内容，普通浏览只看预览。此时可用CASE在SQL内做分支：
SELECT
id,
CASE
WHEN :need_full = 1 THEN content
ELSE SUBSTRING(content, 1, 100)
END AS content_view
FROM articles
WHERE category_id = :cat_id;
通过传入参数need_full，同一接口既能服务轻量列表，也能支撑批量导出，避免维护两套查询。数据库优化器在面对常量参数时通常能裁剪掉不必要的列读取，进一步降低IO。
不过要防范的是，如果应用层错误地把need_full永远设为1，优化就形同虚设。建议在代码层明确区分“列表Mapper”和“详情Mapper”，从调用源头保证长文本不会被误查。
冗余摘要列的设计权衡
写时生成与存储预览
当截取法在超高并发下仍有开销，可考虑在表结构里增加content_summary这样的冗余列，在插入或更新时由程序截取前N字写入。列表查询完全不碰原长文本列：
SELECT id, title, content_summary, updated_at FROM articles WHERE is_published = 1 LIMIT 30;
这种方案把计算成本从读路径转移到写路径，读性能极其稳定。对于发布后很少修改的内容型业务，比如新闻站、帮助文档，收益非常明显。表空间虽略有膨胀，但远小于每次传输全文的代价。
缺点是写入逻辑要维护摘要与正文的同步，若摘要规则变化还需刷数。实践中可把摘要生成封装在DAO层，或借助数据库的触发器实现，降低业务侵入。
与覆盖索引的配合
如果摘要列和查询条件能凑成复合索引，列表查询甚至可以纯靠索引返回，连数据页都不用回表。例如为(category_id, content_summary)建索引，上述按分类查列表的语句即可达成索引覆盖，进一步压缩IO到极致。
| 方案 | 读IO | 写复杂度 | 适用场景 |
|---|---|---|---|
| SUBSTRING实时截取 | 中 | 低 | 读多写多，字段超大 |
| CASE按需返回 | 低到中 | 低 | 同一接口多用途 |
| 冗余摘要列 | 极低 | 中 | 内容稳定，读远大于写 |
落地时的注意事项
首先，不要对所有长文本都无脑截断，像聊天记录检索这类本就需要上下文的场景，应评估分页或分片拉取。其次，ORM框架常默认映射所有列，需在查询构造器里显式指定字段，避免select *悄悄带回大字段。最后，监控慢查询日志中的Rows_sent与Bytes_sent，当单查询发送字节数异常偏高时，多半就是长文本未做选择性返回的信号。
通过把“查什么”和“用多少”解耦，选择性返回把IO消耗压到业务真实需求的最小集。它不依赖昂贵硬件，也不引入复杂中间件，是性价比极高的SQL长文本查询优化起点。