数据库备注型字段，这2种场景别硬上

备注型字段能不能用，关键不在能不能，而在放在哪张表上。MySQL 里的 TEXT、BLOB 那一串类型，面板上常写成备注型、长文本，它跟 VARCHAR 压根不是一回事：行里只留个指针，正文甩到行外，读的时候多一次跳转。这个行内行外的挪动，代价全在后面。数据库备注型字段用对地方是省事，用错地方就是天天给慢查询交学费。

数据库备注型字段最怕的，是躺在一张有列表页的主表里

后台的订单列表、文章列表、会员列表，写起来都一个套路：分页、按时间倒序、页面上显示五六个字段。很多人图省事，把备注、描述、备注说明这些整段文字直接挂在主表上，查询再随手一个 SELECT *。页面上明明只显示标题和时间，数据库却把每条记录的几千字一块儿搬了一遍。翻十页就是几千条大字段在网络上和缓冲池里来回折腾。

更难受的是缓冲池。内存就那么大，这些平时不看的正文把热数据挤出去，本来该常驻的索引页被刷掉，然后你发现整个库响应都变得黏糊糊的，还找不到是哪条 SQL 干的。这种情况我见得太多，最后排查下来往往就是一张表里躺着两三个备注型列。

要排序、要过滤、要 GROUP BY 的列，别让它上场

第二类场景更隐蔽：字段本身要参与查询条件。备注型字段在索引这件事上先天吃亏，整列建不了普通索引，只能拿前缀凑合。前缀短了区分度不够，前缀长了索引也跟着肥。要是还写个 LIKE ‘%关键词%’，那前面带百分号，索引直接歇工，全表扫。

排序同理。按备注字段的长度排、按内容排，或者查询里带着大字段一起 ORDER BY，临时表装不下就落到磁盘上去，那速度就没法看了。这种活儿交给 VARCHAR，或者干脆在业务层想办法，别让数据库扛。

拆表这招老土，但它真能把问题掐掉

解决办法没什么新鲜的：主表只放查询要用的字段，备注、正文这些挪到一张一对一的详情表里，用主键关联，用的时候再取。列表页永远只碰主表，详情页才去 join 一下。听着笨，但它把读写路径彻底分开了。

还有个更省的做法：主表上冗余一个摘要列，VARCHAR 存前一两百个字，列表页展示够了，用户点进去再看全文。摘要跟着业务更新的时候同步写一下就行，别指望触发器帮你做这事，维护起来更绕。

文件类的更别往库里塞。图片、附件、导出的 PDF，直接进对象存储或者文件目录，库里只存一个 URL 或者 key。这样做备份的时候你会感谢自己——一个几百 G 的库和几 G 的库，迁起来完全是两种心情。

数据库备注型字段能放心用的场合，其实比你想的多

别听风就是雨地把备注型字段全禁了，它本来就是为了大段文本设计的。判断标准很简单，问三个问题：这张表会不会被高频地按条件查？这个字段会不会进 WHERE、ORDER BY、GROUP BY？查询里是不是习惯性地 SELECT *？三个答案都是否，那就大大方方用。

后台详情页一次读一条，日志正文、工单内容、归档的历史说明，这类低频访问的场景，备注型字段比 VARCHAR 合适得多，因为它不占行内空间，主表的行能塞得更紧凑，索引扫描反而更快。

几个容易踩的细节，顺手记一下

第一个，ORM 的默认行为。不少框架查主表的时候会把所有列一起带出来，你以为没查备注，实际查了。映射里给它加个延迟加载或者排除掉，或者在查询里明确列字段，别偷懒。第二个，默认值。较老的 MySQL 版本里给 TEXT 设默认值会直接报错，新版本宽松一些，但具体行为以你手上版本的官方文档为准，别照着博客抄。

第三个，长度别想当然。TEXT 的上限是字节数不是字符数，utf8mb4 下一个汉字占三字节，带 emoji 的还要再多，标称能装多少字得自己换算。写死在代码里的长度校验如果按字符算，超长插入会在运行时炸，日志里还不太好看。第四个，备份和迁移。带大字段的表用逻辑备份导出，文件体积和耗时都上一个台阶，日常备份策略要把它单独考虑进去，别等迁移窗口排不开了才发现。

这张表要不要动，上线前花两分钟对一遍就行：主表里有没有备注型列；有没有列表页在 SELECT *；这几个列有没有进过 WHERE 或 ORDER BY；附件是不是存在库里。四条全中，那就趁数据还少赶紧拆；一条不中，安心用，别自己给自己找活干。