行和
记录在 MySQL 中是完全等价的概念：每插入一条
INSERT INTO ... VALUES (...)，就产生一行（即一条记录）；每查出的一行结果，就是一条逻辑记录。它不是抽象概念，而是物理存储的最小业务单位。
行到底存在哪？看文件就知道
MySQL 的数据不是“飘着”的，它实实在在落在磁盘文件里：
.ibd文件：InnoDB 表的**独占表空间文件**，真实数据（即所有行）都存这里（MySQL 5.6.6+ 默认启用）
.frm文件（8.0 前）：只存表结构（列名、类型、索引定义），不存任何一行数据
ibdata1（共享表空间）：老版本或配置为
innodb_file_per_table=OFF时，所有表的行会挤进这个大文件
执行
SHOW VARIABLES LIKE 'datadir';找到路径，进对应数据库目录，就能看到
users.ibd这类文件——你的每一行，此刻正躺在里面某个页（page）的某个偏移位置上。
一行不是“平铺直叙”，而是有严格格式的二进制块
InnoDB 存储引擎用的是
COMPACT或
DYNAMIC行格式（默认），它把一行拆成四部分打包： 变长字段长度列表：比如
VARCHAR(20)实际存了
"abc"，这里就记
3（逆序存放，细节不用手算，但要知道它占空间） NULL 值列表：每个可为 NULL 的列占 1 bit，全为 NULL 的列才真省空间；哪怕只有一列可空，也至少占 1 字节 记录头信息：含
delete_mask（软删除标记）、
next_record（指向页内下一行的地址偏移）等，固定 5 字节 真实数据：包括你定义的列值 + 3 个隐藏字段：
row_id（6 字节，无主键时自增）、
trx_id（6 字节，事务 ID）、
roll_pointer（7 字节，MVCC 版本链指针）
这意味着：即使你建表只有
id INT一个非空列，一行也至少占
4（INT）+ 5（头）+ 6+6+7（隐藏字段） = 28 字节，还没算 NULL 列和变长字段的开销。
为什么不能随便加 VARCHAR(65535)？65535 是假上限
官方文档写
VARCHAR最大长度是 65535，但这是**整行所有列总长度上限**，且受编码、行格式、NULL/变长头开销挤压： 1 行最大允许
65535字节（注意：是字节数，不是字符数；
utf8mb4下一个汉字占 4 字节） 必须预留至少 2 字节存该字段实际长度（
VARCHAR是变长的，得记“我存了几字节”） 如果表里还有其他列、有可空列、用了
DYNAMIC格式（溢出行指针额外占 20 字节），实际能塞给单个
VARCHAR的空间远小于此 实测：仅一个
VARCHAR列 +
utf8mb4，最大安全值通常是
VARCHAR(65532)；再大就报
Row size too large
CREATE TABLE t1 (v VARCHAR(65533)) CHARSET=utf8mb4; -- ERROR 1118 (42000): Row size too large.
行和页的关系，才是性能关键
MySQL 从不单独读写某一行——它以
16KB的
页（page）为最小 I/O 单位： 一个
页里存几十到上百行（取决于行大小），页内行通过
next_record指针连成单向链表 页与页之间用
FIL_PAGE_PREV / FIL_PAGE_NEXT形成双向链表，但物理磁盘上未必连续 真正影响查询速度的，往往不是“找哪一行”，而是“要读几个页”；所以
WHERE条件能否走索引、索引是否紧凑、行是否被挤进溢出页（
off-page），直接决定随机 I/O 次数
这也是为什么
SELECT *在宽表上极伤性能：哪怕只想要 3 列，引擎仍可能把整页（含其他 20 列）全读进内存。
行的底层结构不是面试八股，而是你调优
innodb_page_size、设计宽表、排查
Row size too large或理解 MVCC 版本链时，绕不开的物理事实。别只盯着 SQL 写法，数据真正躺哪儿、怎么躺，决定了它有多难被捞出来。
