确认当前查询真在读溢出页需依赖运行时指标：Handler_read_rnd_next异常高（每行触发一次溢出页加载）、慢查日志中Rows_examined远大于Rows_sent且Sort_merge_passes上涨、或查INFORMATION_SCHEMA.INNODB_BUFFER_PAGE中PAGE_TYPE='BLOB'的缓存页数。
怎么确认当前查询真在读溢出页
EXPLAIN 完全不提示溢出页读取，它只管索引选择和访问类型，不管引擎层是否悄悄发起多次 os_aio 随机读。真正能说明问题的是运行时行为：
– 查 SHOW PROFILE FOR QUERY N，重点看 Handler_read_rnd_next 值是否异常高（每行触发一次溢出页加载，这个值就涨一次）
– 慢查询日志里 Rows_examined 远大于 Rows_sent，且 Sort_merge_passes 持续上涨，说明磁盘临时表被反复刷写，背后大概率是 TEXT 字段拖累
– 开启 innodb_monitor_enable = 'innodb_buffer_page' 后查 INFORMATION_SCHEMA.INNODB_BUFFER_PAGE，过滤 PAGE_TYPE = 'BLOB'，能看到实际缓存的溢出页数量（但生产环境慎用，监控开销大）
为什么只查 id 和 order_id 也变慢
二级索引回表时仍要拼完整行，这是 MVCC 可见性判断的前提。哪怕你的 WHERE order_id = ? 走了 idx_order_id，InnoDB 仍需根据隐式主键回聚簇索引页，而只要该页上存在溢出列（哪怕 SELECT 列表里没它），就会同步加载对应溢出页。
– 不是优化器“多此一举”，而是隔离级别（如 READ-COMMITTED）要求构造事务快照下的逻辑行，必须把指针指向的内容读回来才能判断这行是否可见
– 即使 ext_info 是空字符串，只要定义为 LONGTEXT，InnoDB 就按 65535 字节参与行宽估算，可能提前触发溢出，导致整页结构已含指针
如何用 SHOW TABLE STATUS 快速筛出高风险表
SHOW TABLE STATUS LIKE 'your_table' 返回的 Avg_row_length 是最直接的线索：
– 手动加总所有非大字段长度（比如 id + order_id + status + created_at 约 200 字节）
– 如果 Avg_row_length 显示 4000+ 或更高，基本可断定已有大量行进入溢出页
– 再补查一条典型记录：SELECT LENGTH(content) FROM your_table WHERE id = 123，结果 > 8000 且表是 ROW_FORMAT = DYNAMIC，就是硬证据
– 注意：别信 INFORMATION_SCHEMA.INNODB_SYS_TABLES 里的 FILE_FORMAT 或 ROW_FORMAT 字段，它可能滞后；优先以实际读取行为和 SHOW CREATE TABLE 输出为准
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
绕过溢出页读取的三个实操动作
核心不是“避免溢出”，而是让执行计划不触碰溢出页：
– 永远不用 SELECT *，显式列出所需字段，且把 TEXT 类字段放在最后甚至完全不查
– 给二级索引加覆盖字段：CREATE INDEX idx_order_id_cover ON order_ext (order_id) INCLUDE (id)（MySQL 8.0.23+），这样 SELECT id, order_id 可完全走索引，彻底不回表
– 拆表：把 ext_info 这类纯扩展字段单独建 order_ext_detail 表，主表只留业务强相关字段；关联查时再按需 JOIN，把溢出页 I/O 控制在明确场景
溢出页读取是同步、透明、不可跳过的，哪怕你只想要一个 id。最容易被忽略的是：**二级索引覆盖不足时，回表动作本身就会触发溢出页加载，和 SELECT 列表无关**。
