行是mysql中物理存储的最小业务单位，真实存在于.ibd等磁盘文件的16KB页内，按COMPACT/DYNAMIC格式组织为含头信息、隐藏字段和数据的二进制块。
行和记录在 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 写法，数据真正躺哪儿、怎么躺，决定了它有多难被捞出来。