VARCHAR(65535)反而更耗内存是因为InnoDB对超约768字节的VARCHAR触发行溢出，主记录仅存20字节指针，真实数据存于16KB溢出页，SELECT *强制触发额外随机I/O且溢出页不缓存；其与TEXT底层存储机制完全一致，性能无差别，还多占行内开销。
为什么VARCHAR(65535)反而更耗内存
很多人以为设大点保险，结果发现查询变慢、内存飙升。根本原因不是“存不下”，而是InnoDB对超过约768字节的VARCHAR字段会触发行溢出：主记录只留20字节指针，真实数据扔到独立溢出页。每次SELECT *都得额外读一次磁盘随机I/O——哪怕你根本不需要那个字段。
更糟的是，VARCHAR(65535)和TEXT在底层存储机制上完全一致，只是语法糖。别被“VARCHAR更快”误导，超阈值后性能没差别，还多占一行内开销。
- 查哪些列已溢出：
SELECT NAME, TYPE, LEN FROM information_schema.INNODB_SYS_COLUMNS WHERE TABLE_ID = (SELECT TABLE_ID FROM information_schema.INNODB_SYS_TABLES WHERE NAME LIKE 'your_db/your_table') AND LEN > 768 - 溢出页最小单位是16KB（
innodb_page_size默认值），存1KB也占满一页 - 这些溢出页不会进
innodb_buffer_pool常规缓存，除非启用innodb_large_prefix且表格式为Barracuda
ALTER COLUMN时最容易踩的坑
直接ALTER TABLE t MODIFY c VARCHAR(200)看似简单，但可能锁表、失败或悄悄截断数据。InnoDB在修改长度时，若新长度小于已有最长值，会报错；若等于或大于，也可能因行大小限制拒绝执行。
- 先确认当前最大长度：
SELECT MAX(CHAR_LENGTH(c)) FROM t - 确保新长度 ≥ 当前最大值，否则加
STRICT_TRANS_TABLES模式下会截断并报错 - 避免在高并发写入期间执行，DDL在5.7+虽支持在线，但
MODIFY仍可能触发全表重建（尤其含溢出列） - 更安全的做法是新建列+迁移+删旧列，用
ALGORITHM=INSTANT（8.0.12+）避免锁表
text系列字段真比varchar省内存吗
不是。TEXT类字段（TEXT、MEDIUMTEXT）本身不进buffer pool缓存，但每个连接在处理含TEXT字段的查询时，仍要分配临时内存用于解析、排序、网络传输。尤其当ORM自动生成SELECT *，大量TEXT字段被拉进结果集，MySQL会为每行分配临时缓冲区，内存消耗呈线性增长。
- 查实际内存压力来源：
SHOW STATUS LIKE 'Created_tmp_disk_tables'和Created_tmp_tables比值高，说明临时表频繁落盘，间接反映大字段拖慢查询节奏 -
TEXT字段无法建前缀索引（VARCHAR可以），想加速检索就得靠全文索引或外部引擎（如Elasticsearch） - 如果字段内容平均VARCHAR(500)；超2KB再考虑
TEXT，但必须配合应用层显式投影（避免SELECT *）
真正影响内存的其实是查询方式
字段定义只是静态开销，动态内存爆炸往往来自查询习惯。一个SELECT *拉10个VARCHAR(10000)字段，即使数据实际只填了100字符，MySQL仍按定义长度预分配内存缓冲区——这是per-connection的，100个连接就吃掉几百MB。
- 强制应用层禁用
SELECT *，用SQL审计工具（如pt-query-digest + 自定义规则）拦截含大字段的全选语句 - 对富文本类字段，约定命名后缀如
_content，在DAO层默认exclude，需要时显式join扩展表 - 监控
Handler_read_rnd_next指标突增，大概率是溢出页随机读引发的连锁内存申请
字段长度问题从来不是单点配置能解决的，它缠在表设计、查询语义、连接生命周期里。最常被忽略的，是开发写完SQL就跑，没人盯SHOW PROFILE里那几行“Copying to tmp table”或“Sending data”的真实耗时来源。
