大字段（TEXT、BLOB、JSON）必须与主表物理分离，否则即使只查1行也会触发磁盘临时表、全表扫描和IO翻倍；应通过垂直分表拆至扩展表，列表页显式指定非大字段，详情页单独查询，外键须加索引且大字段默认为NULL。
先说一个核心结论：大字段（TEXT、BLOB、JSON）必须和主表物理分离，否则一次查询就可能拖垮整条SQL的性能。 这可不是加个索引就能解决的问题，而是由MySQL底层的数据存储和执行机制决定的。只要SELECT语句里包含了TEXT字段，哪怕你只想取一行数据，MySQL都可能放弃使用内存临时表，转而写入磁盘临时表，导致I/O开销直接翻倍。
TEXT 字段为什么会让查询变慢
MySQL处理大字段的方式非常“实在”：它不会像处理普通整型或字符串字段那样走内存缓存，而是按需从磁盘读取完整内容。一旦SQL中间出现了SELECT *，或者没有显式限制字段的select()，问题就来了。即便你的模板里只用到了$user->namecontent、description这类大字段整个捞出来，经历序列化、网络传输，最后再由PHP解析——整个过程造成了计算、传输和内存的三重浪费。
- 宽表加上TEXT字段，极易触发执行计划中的
Using temporary; Using filesort。 - 分页查询20条数据，如果每条都附带100KB的content内容，光是网络传输就得多占2MB，连带着Redis缓存体积也会膨胀。
- 一旦
ORDER BY或GROUP BY操作涉及TEXT字段，索引将完全失效，查询必然走向全表扫描。
怎么把 TEXT 字段从主查询里摘出去
核心原则其实很清晰：在列表页、聚合页、搜索页这些场景下，一律不查询大字段；只在用户点击进入详情页时，再按需加载。
- 列表页：务必使用
field('id,title,created_at,status')，显式排除content、remark等大字段。 - 详情页：单独进行查询，例如
ArticleModel::where('id', $id)->field('id,title,content,cover')->find()。 - 特殊场景：如果确实需要一起查询（比如数据导出），可以改用子查询或JOIN进行拆分：
->field('a.id,a.title,a.created_at,(SELECT content FROM article_ext WHERE article_ext.article_id = a.id) as content')。 - 模型关联：使用
with('ext')进行关联查询时，必须在关联模型里写死field('article_id,content')，否则ORM依然会拉取所有字段。
数据库层面怎么设计才不踩坑
千万别指望在ORM层做补救。如果数据库结构设计不合理，再怎么用field()限制字段，都只是亡羊补牢。
立即学习“PHP免费学习笔记（深入）”；
- 将
content、html、json_config等大字段单独拆分到_ext扩展表中，通过外键与主表关联，确保主表始终保持轻量。 _ext表中的外键字段（例如article_id）必须添加索引，否则进行JOIN查询时会退化为全表扫描。- 避免在大字段上直接建立索引。即使只是执行
WHERE content LIKE '%xxx%'这样的模糊查询，也会导致索引体积急剧膨胀，并严重影响写入性能。 - TEXT字段的默认值应设为
NULL，而不是空字符串。因为MySQL对NULL值的存储处理通常更为节省空间。
还有一个最容易被忽略的细节：字段缓存（通过optimize:schema命令生成）会将SHOW COLUMNS的结果固化下来。如果你在后期向表中添加了TEXT字段，却没有重新生成缓存，那么ORM仍会按照旧的结构进行解析，这可能导致字段丢失或抛出错误。因此，上线前务必确认runtime/schema/目录下的缓存文件已经更新。
