1. 项目概述InnoDB 表空间不是“文件夹”而是数据生存的底层土壤很多人第一次看到“InnoDB 表空间”这个词下意识会把它当成 MySQL 里一个类似操作系统文件夹的概念——放几张表、建几个索引点点鼠标就完事。我刚接触 InnoDB 时也这么想直到某次线上服务突然卡死监控显示磁盘 I/O 持续 98%而ibdata1文件在三天内从 2GB 膨胀到 47GB但SHOW TABLE STATUS显示所有业务表加起来才不到 500MB。那一刻我才真正意识到表空间不是容器而是数据在磁盘上呼吸、生长、代谢的活体系统。它直接决定着你每条INSERT的延迟、每次SELECT ... FOR UPDATE的锁粒度、甚至主从同步中断后能否安全恢复。这不是 DBA 才该关心的冷门参数而是每个写 SQL、设计分库分表、排查慢查询的开发者都绕不开的底层契约。标题里这个“九”很关键——它暗示这不是孤立知识点而是 InnoDB 存储引擎系列中承上启下的核心一环。前八讲可能讲了 Buffer Pool、Redo Log、Undo Log、行格式、锁机制……而表空间就是把所有这些机制物理锚定在磁盘上的“地基”。它决定了 Undo Log 写在哪、临时表存哪、大字段 BLOB 怎么落盘、甚至TRUNCATE TABLE是删文件还是打标记。你用innodb_file_per_tableON创建一张表看似只是多了一个.ibd文件实则触发了整个空间管理器的重调度你执行ALTER TABLE ... ROW_FORMATCOMPRESSED表面是改压缩算法背后是表空间页分配策略的全面重构。关键词“MySQL”“InnoDB”“表空间”“Tables”四个词连在一起指向的从来不是语法层面的操作而是对数据生命周期的全链路掌控能力。适合谁如果你还在用mysqldump做备份、靠OPTIMIZE TABLE清理碎片、遇到Table xxx is marked as crashed就重启 mysqld——那这篇就是为你写的。它不教你怎么装 MySQL而是告诉你当磁盘报警、当INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES里出现陌生的SPACE_TYPE、当ibdata1突然失控膨胀时你手里真正能握紧的扳手在哪。2. 表空间整体设计与思路拆解为什么 InnoDB 不直接用文件系统管理数据2.1 从“文件直写”到“空间抽象”的必然演进早期数据库比如 MyISAM确实简单粗暴一张表对应.MYD数据和.MYI索引两个独立文件增删改查直接操作文件句柄。这种设计在单机小数据量时代很高效但到了 InnoDB 面对高并发事务场景时立刻暴露出三个致命短板事务一致性无法保障假设一个事务要同时修改 A 表和 B 表MyISAM 需要分别锁定两个文件若 A 写成功、B 写失败回滚时就得跨文件恢复没有统一的原子性锚点空间碎片不可控频繁DELETE后.MYD文件里留下大量空洞OPTIMIZE TABLE必须重建整个文件期间表完全不可写业务直接雪崩内存与磁盘映射低效Buffer Pool 缓存的是页Page而文件系统缓存的是块Block两者粒度不匹配导致大量无效 IO。InnoDB 的破局点就是引入表空间Tablespace这一中间抽象层。它不直接操作文件而是把磁盘划分为逻辑连续的“空间编号”Space ID每个空间内部再按 16KB 固定大小切分成“页”Page。所有数据页、索引页、Undo 页、系统页都通过 Space ID Page Number 定位。这就带来三大根本性优势事务原子性的物理载体一个事务的所有修改最终都归结为对若干个Space ID, Page Number的写入。Redo Log 记录的正是这些物理地址的变更崩溃恢复时只需重放日志就能让所有空间页回到一致状态空间复用的精细控制页内有 Free Space List空闲页链表、XDESExtent Descriptor管理 1MB 的区Extent删除记录只回收页内空间删除整页才归还给区管理器碎片率可精确到页级Buffer Pool 的无缝映射缓存页的哈希键 (Space ID 32) Page Number与磁盘定位完全一致避免任何地址转换开销。提示理解这一点是后续所有优化的前提。很多开发者调优只盯着innodb_buffer_pool_size却忽略innodb_page_size和innodb_extent_size的配合——就像只调发动机转速却不看变速箱齿轮比。2.2 两大核心类型系统表空间 vs 独立表空间InnoDB 表空间不是单一实体而是分层架构。最顶层是系统表空间System Tablespace默认由ibdata1文件承载可通过innodb_data_file_path配置多个文件它像数据库的“中央神经系统”强制存储以下四类元数据数据字典Data Dictionary所有表、列、索引的定义以 B 树形式存在SYS_TABLES、SYS_COLUMNS等内部系统表中双写缓冲区Doublewrite Buffer为防止页写入半截partial write导致数据损坏InnoDB 先把脏页写入ibdata1的固定区域再异步刷到真正的表空间这是崩溃恢复的最后防线变更缓冲区Change Buffer针对非唯一二级索引的 DML 操作先缓存在ibdata1中等对应数据页被读入 Buffer Pool 时再合并大幅降低随机 IOUndo Logs事务回滚和 MVCC 多版本读取的基石其段Segment必须位于系统表空间除非启用innodb_undo_directory指向独立路径。而独立表空间File-Per-Table Tablespace则是通过innodb_file_per_tableONMySQL 5.6.6 默认开启为每张用户表单独创建.ibd文件。它的设计哲学是“权责分离”系统表空间管全局生命线独立表空间管业务数据生死。这种分离带来三个关键收益TRUNCATE / DROP 即刻释放磁盘DROP TABLE t1直接删除t1.ibd文件ibdata1不受影响而关闭此选项时DROP只是逻辑标记空间永远无法回收传输表空间Transportable Tablespace成为可能.ibd文件可导出为二进制镜像配合FLUSH TABLES t1 FOR EXPORT和COPY TO SERVER实现 TB 级表的秒级迁移在线 DDL 更可控ALTER TABLE ... ALGORITHMINPLACE时新表空间在独立.ibd中构建旧空间保持可读切换瞬间完成。但硬币另一面是独立表空间无法存储 Undo Logs所以长事务仍会撑爆ibdata1且每个.ibd文件都有固定开销至少 96KB 的文件头和 FSP_HDR 页小表过多反而浪费空间。2.3 空间管理的核心矛盾页内碎片 vs 区级碎片表空间的“健康度”取决于两类碎片的平衡页内碎片Intra-page Fragmentation一页 16KB存满数据后PAGE_FREE为 0但UPDATE修改变长字段如VARCHAR从 10 字节扩到 100 字节时原页可能放不下InnoDB 会触发页分裂Page Split—— 把约 1/2 记录移到新页原页留下大量空洞。此时PAGE_FREE飙升但页数未增属于“虚胖”。区级碎片Inter-extent Fragmentation一个区Extent 64 个连续页 1MB。当表空间需要新页时InnoDB 优先从已有区申请若所有区都无足够空闲页则分配新区。但DELETE大量记录后区里可能只剩零星几页可用导致大量“半废区”空间利用率暴跌。这两类碎片的治理策略完全不同页内碎片靠OPTIMIZE TABLE或ALTER TABLE ... FORCE重建整张表来消除区级碎片则依赖innodb_file_per_tableON下的ALTER TABLE ... ENGINEInnoDB触发空间重组或更激进的mysqldump导出导入。我见过最典型的案例某电商订单表因促销活动高频INSERT/DELETE三个月后DATA_LENGTH显示 12GB但DATA_FREE高达 8GBSELECT COUNT(*)却只有 200 万行——这就是页内碎片的典型症状OPTIMIZE TABLE后空间直接回落到 4.5GB。3. 核心细节解析与实操要点从INFORMATION_SCHEMA到ibd文件头3.1 三张关键系统表读懂表空间的“体检报告”InnoDB 把所有空间元数据都固化在INFORMATION_SCHEMA的三张只读视图中它们是诊断空间问题的第一现场INNODB_SYS_TABLESPACES表空间的“总台账”SELECT SPACE, NAME, FLAG, SPACE_TYPE, FILE_SIZE, ALLOCATED_SIZE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES WHERE NAME LIKE test/%;SPACE: 空间唯一 IDSYS_TABLES中SPACE字段即引用此值NAME: 逻辑名如test/t1数据库名/表名或innodb_system系统表空间FLAG: 32 位标志位需用BIN(FLAG)查看其中第 0 位为 1 表示FILE_PER_TABLE第 1 位为 1 表示COMPRESSEDSPACE_TYPE:General通用表空间、Single独立表空间、System系统表空间FILE_SIZE/ALLOCATED_SIZE: 文件实际大小与已分配空间单位字节二者差值即为文件系统级空洞。INNODB_SYS_TABLES表与空间的“绑定关系图”SELECT NAME, SPACE, FILE_FORMAT, ROW_FORMAT, ZIP_PAGE_SIZE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME test/t1;SPACE: 关联INNODB_SYS_TABLESPACES.SPACEFILE_FORMAT:Antelope老格式仅支持 COMPACT/REDUNDANT或Barracuda新格式支持 DYNAMIC/COMPRESSEDROW_FORMAT: 行格式DYNAMIC大字段外存和COMPRESSED页级 zlib 压缩直接影响空间效率ZIP_PAGE_SIZE: 若ROW_FORMATCOMPRESSED此值为压缩后页大小如 8192。INNODB_SYS_INDEXES索引的空间“分布地图”SELECT NAME, SPACE, PAGE_NO, MI_PAGE_NO, TYPE FROM INFORMATION_SCHEMA.INNODB_SYS_INDEXES WHERE TABLE_ID (SELECT TABLE_ID FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAMEtest/t1);SPACE: 索引所在空间 IDPAGE_NO: 根页Root Page的页号B 树的入口MI_PAGE_NO: 元数据页号用于全文索引等TYPE:3为聚簇索引主键1为二级索引0为全文索引。注意这些视图的数据来自内存中的数据字典缓存非实时磁盘扫描。若需绝对准确必须执行FLUSH TABLES WITH READ LOCK后读取但生产环境慎用。3.2.ibd文件结构16KB 页的精密编排一个典型的t1.ibd文件本质是 16KB 页的线性序列。用hexdump -C t1.ibd | head -20可看到前 256 字节的文件头00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|这并非乱码而是严格定义的页结构FIL Header38 字节位于每页开头包含FIL_PAGE_SPACE_OR_CHKSUM校验和、FIL_PAGE_OFFSET页号、FIL_PAGE_PREV/FIL_PAGE_NEXT双向链表指针Page Header56 字节描述页内状态如PAGE_N_DIR_SLOTS槽位数、PAGE_HEAP_TOP空闲空间起始、PAGE_FREE空闲字节数Infimum Supremum26 字节虚拟记录作为页内 B 树叶子节点的边界哨兵User Records变长真实数据行按槽位Directory Slot倒序排列每个槽位 2 字节指向记录起始偏移Free Space变长页内未分配空间PAGE_FREE即为此区域大小Page Directory变长槽位数组每 4~8 条记录一个槽位加速页内二分查找FIL Trailer8 字节页尾校验FIL_PAGE_END_LSN_LOWLSN 低 32 位与页头校验和共同防止单页损坏。实操心得我曾用page_parser工具Percona Toolkit 组件直接解析.ibd发现某张表PAGE_FREE平均高达 6KB但PAGE_N_RECS记录数却很少——这说明大量DELETE后未OPTIMIZE页内碎片严重。此时SELECT * FROM t1 LIMIT 1可能扫到 10 个空页才找到第一条记录IO 效率极低。3.3 行格式与压缩空间效率的终极杠杆ROW_FORMAT不是简单的存储选项而是空间与性能的博弈矩阵行格式支持版本大字段存储压缩支持典型场景REDUNDANT5.0行内否历史兼容已淘汰COMPACT5.1行内否默认平衡性好DYNAMIC5.7行外是含TEXT/VARCHAR大字段表COMPRESSED5.7行外是归档表、读多写少场景关键原理在于大字段Off-page columns的处理COMPACTTEXT/VARCHAR 768 字节时在行内存 768 字节前缀 20 字节指针指向独立的溢出页Overflow PageDYNAMIC行内只存 20 字节指针所有大字段内容全存溢出页主键查询无需访问溢出页大幅提升SELECT *性能COMPRESSED在DYNAMIC基础上对整页含溢出页用 zlib 压缩KEY_BLOCK_SIZE参数指定压缩后页大小如 8192 表示压缩到 8KB。计算压缩收益的公式很简单理论压缩率 (原始页大小 - 压缩后页大小) / 原始页大小 实际收益 (DATA_LENGTH INDEX_LENGTH) × 压缩率 - 压缩 CPU 开销我实测过一个日志表VARCHAR(2000)主体内容ROW_FORMATDYNAMIC时DATA_LENGTH15.2GB改为COMPRESSED KEY_BLOCK_SIZE8后降至9.8GB压缩率 35.5%但INSERTQPS 下降 12%。所以决策依据很明确如果磁盘是瓶颈如云盘 IOPS 限制、CPU 有富余选COMPRESSED如果写入吞吐是命脉选DYNAMIC。4. 实操过程与核心环节实现从创建到诊断的完整链路4.1 创建表时的空间策略选择创建一张新表CREATE TABLE语句中的选项直接决定其空间命运-- 场景1高频写入的订单明细表追求极致写入性能 CREATE TABLE order_detail ( id BIGINT PRIMARY KEY, order_id BIGINT NOT NULL, item_name VARCHAR(255), price DECIMAL(10,2), created_at DATETIME ) ROW_FORMATDYNAMIC KEY_BLOCK_SIZE0; -- 不压缩避免 CPU 开销 -- 场景2历史归档的用户行为日志追求空间极致压缩 CREATE TABLE user_log_archive ( id BIGINT PRIMARY KEY, user_id BIGINT, event_type VARCHAR(50), payload TEXT, -- 大字段 event_time DATETIME ) ROW_FORMATCOMPRESSED KEY_BLOCK_SIZE4; -- 压缩到 4KB适合文本重复率高的日志 -- 场景3需要快速克隆的配置表要求可传输表空间 CREATE TABLE config_master ( id INT PRIMARY KEY, key_name VARCHAR(100), value TEXT ) ROW_FORMATDYNAMIC -- 必须确保 innodb_file_per_tableON默认已开启这里的关键参数逻辑ROW_FORMAT如前所述DYNAMIC是现代应用的基准线COMPRESSED需权衡 CPUKEY_BLOCK_SIZE仅对COMPRESSED有效合法值为 1, 2, 4, 8, 16单位 KB必须是 2 的幂。值越小压缩率越高但页分裂概率越大因为压缩后页更易满AVG_ROW_LENGTH提示优化器预估行平均长度影响初始页分配但不强制生效DATA DIRECTORY可将.ibd文件存到独立磁盘如 SSD但需secure_file_priv权限且不支持主从复制。注意ROW_FORMATCOMPRESSED要求innodb_file_formatBarracudaMySQL 5.7 默认且innodb_large_prefixON允许索引前缀 767 字节。若创建时报错Row size too large大概率是innodb_large_prefix未开启。4.2 空间诊断的黄金 SQL 组合当磁盘告警或查询变慢这五条 SQL 是我的“空间听诊器”全局空间占用概览SELECT IF(NAME innodb_system, System Tablespace, IF(NAME LIKE mysql/%, System Tables, CONCAT(User Table: , SUBSTRING_INDEX(NAME, /, 1)) ) ) AS space_type, ROUND(SUM(FILE_SIZE)/1024/1024/1024, 2) AS size_gb, ROUND(SUM(ALLOCATED_SIZE)/1024/1024/1024, 2) AS allocated_gb, ROUND((SUM(FILE_SIZE)-SUM(ALLOCATED_SIZE))/1024/1024/1024, 2) AS free_gb FROM INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES GROUP BY space_type;单表空间深度分析含碎片率SELECT t.NAME AS table_name, ROUND(s.FILE_SIZE/1024/1024, 2) AS file_mb, ROUND(s.ALLOCATED_SIZE/1024/1024, 2) AS allocated_mb, ROUND((s.FILE_SIZE - s.ALLOCATED_SIZE)/1024/1024, 2) AS free_mb, ROUND((s.FILE_SIZE - s.ALLOCATED_SIZE)/s.FILE_SIZE * 100, 2) AS fragmentation_pct, t.ROW_FORMAT, t.FILE_FORMAT FROM INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES s JOIN INFORMATION_SCHEMA.INNODB_SYS_TABLES t ON s.SPACE t.SPACE WHERE t.NAME test/t1;页级碎片探测需innodb_metrics开启SELECT NAME, COUNT, ROUND(AVG_VALUE, 2) AS avg_free_bytes_per_page FROM information_schema.INNODB_METRICS WHERE NAME IN (buffer_pool_pages_total, buffer_pool_pages_free, buffer_pool_pages_misc) OR NAME LIKE buffer_pool_page%free%; -- 若 buffer_pool_page_free_bytes_avg 持续 4000表明页内碎片严重Undo Logs 空间消耗追踪SELECT r.trx_id, r.trx_state, r.trx_started, r.trx_weight, r.trx_mysql_thread_id, r.trx_query, u.HISTORY_LIST_LENGTH FROM information_schema.INNODB_TRX r JOIN information_schema.INNODB_METRICS u ON u.NAME innodb_history_list_length ORDER BY r.trx_started ASC LIMIT 10; -- HISTORY_LIST_LENGTH 10000 且持续增长说明长事务阻塞 Undo 回收双写缓冲区使用率判断是否成为 IO 瓶颈SHOW GLOBAL STATUS LIKE Innodb_dblwr%; -- Innodb_dblwr_writes / Innodb_os_log_written 0.3说明双写开销占比过高4.3 空间优化的实操步骤与风险控制优化不是盲目OPTIMIZE而是分阶段精准干预阶段1紧急止血10分钟内若ibdata1持续膨胀立即SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY trx_started LIMIT 1找出最早事务联系业务方确认是否可杀若某张表fragmentation_pct 40%执行ALTER TABLE t1 ENGINEInnoDB ALGORITHMINPLACE LOCKNONE;MySQL 5.6 支持在线重建但需确保innodb_file_per_tableON若磁盘剩余 10%用pt-disk-health检查磁盘坏道同时df -h确认是否被其他进程占满。阶段2计划性重建维护窗口期# 步骤1生成优化脚本排除大表和核心业务表 mysql -e SELECT CONCAT(ALTER TABLE , TABLE_SCHEMA, ., TABLE_NAME, ENGINEInnoDB;) FROM information_schema.TABLES WHERE ENGINEInnoDB AND TABLE_SCHEMA NOT IN (mysql,information_schema,performance_schema) AND DATA_LENGTH 1024*1024*100 -- 大于100MB AND TABLE_ROWS 100000 optimize.sql # 步骤2逐条执行监控 Buffer Pool 命中率 mysql -e SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_%; # 优化前记录命中率 mysql optimize.sql mysql -e SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_%; # 优化后对比阶段3长期治理架构层归档策略对created_at DATE_SUB(NOW(), INTERVAL 1 YEAR)的数据用pt-archiver迁移到归档库并DROP PARTITION若分区表压缩策略对user_log类表每月ALTER TABLE user_log ROW_FORMATCOMPRESSED KEY_BLOCK_SIZE4;监控告警在 Zabbix 中添加INNODB_SYS_TABLESPACES.FILE_SIZE变化率监控突增 50% 触发告警。实操心得我踩过最大的坑是在主库执行OPTIMIZE TABLE时未加READ ONLY锁导致主从延迟飙升。正确姿势是先SET GLOBAL read_onlyON;再OPTIMIZE完成后SET GLOBAL read_onlyOFF;。另外ALGORITHMCOPY旧版默认会锁表务必用ALGORITHMINPLACE。5. 常见问题与排查技巧实录那些文档里不会写的真相5.1 “ibdata1越删越大”之谜现象ibdata1文件从 1GB 开始运行半年后涨到 80GBdu -sh ibdata1和ls -lh ibdata1显示大小一致但INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES中ALLOCATED_SIZE仅 12GB。真相这是双写缓冲区Doublewrite Buffer的隐式膨胀。ibdata1的前 128 个区128×1MB128MB固定分配给双写区但 InnoDB 为应对突发写入会动态扩展双写区至最多 256MB。然而ALLOCATED_SIZE只统计用户数据占用不包含双写区预留空间。更隐蔽的是ibdata1文件系统级空洞File System Hole无法被ALLOCATED_SIZE反映——fallocate -p创建的稀疏文件ls显示大du显示小。排查命令# 查看文件实际占用排除空洞 du -h ibdata1 # 查看双写区实际使用需 Percona Server 或 MySQL 8.0.30 SELECT * FROM performance_schema.file_summary_by_instance WHERE FILE_NAME LIKE %ibdata1% AND EVENT_NAME LIKE wait/io/file/innodb/%doublewrite%; # 强制收缩危险仅限测试环境 # 1. 停库 # 2. mv ibdata1 ibdata1.bak # 3. 启动 mysqld会重建最小 ibdata1 # 4. 用 mysqldump 导入数据注意生产环境严禁直接删ibdata1这是 InnoDB 的心脏删除等于自毁。5.2 “TRUNCATE TABLE不释放空间”之惑现象TRUNCATE TABLE t1后t1.ibd文件大小不变df -h磁盘空间未增加。真相TRUNCATE在innodb_file_per_tableON下本质是删除.ibd文件并重建。但如果t1.ibd正被其他进程打开如lsof | grep t1.ibd发现 mysqld 进程持有 fdLinux 的 unlink 机制会让文件“逻辑删除但物理存在”直到所有 fd 关闭。此时ls看不到文件但du仍计入空间。排查步骤# 1. 确认文件是否真被删除 ls -la /var/lib/mysql/test/t1.* # 2. 检查 mysqld 是否还持有句柄 lsof -p $(pgrep mysqld) | grep t1.ibd # 3. 若存在重启 mysqld 强制释放生产环境需评估 systemctl restart mysqld5.3 “ALTER TABLE ... COMPRESSED失败”的根因现象ALTER TABLE t1 ROW_FORMATCOMPRESSED KEY_BLOCK_SIZE4;报错ERROR 1030 (HY000): Got error -1 from storage engine。真相这不是语法错误而是页压缩失败的底层报错。KEY_BLOCK_SIZE4要求压缩后页 ≤ 4KB但若原始页数据熵值过高如加密字段、随机 UUIDzlib 压缩率不足无法满足条件。InnoDB 会尝试多次压缩失败后抛出此错。解决方案降低压缩强度KEY_BLOCK_SIZE8压缩到 8KB预处理数据对payload字段做 base64 编码增加可压缩性改用ROW_FORMATDYNAMIC 应用层压缩如 JSON 字段存 gzip 后的 base64。5.4 表空间迁移的“隐形陷阱”现象用FLUSH TABLES t1 FOR EXPORTcp t1.{cfg,ibd}到新实例ALTER TABLE t1 IMPORT TABLESPACE后查询返回空。真相IMPORT TABLESPACE要求新实例的innodb_page_size必须与源实例完全一致。若源是 16KB目标是 4KB即使t1.cfg中的PAGE_SIZE字段正确InnoDB 也会拒绝导入。此外t1.cfg文件必须与t1.ibd同时传输且t1.ibd必须chown mysql:mysql。验证命令# 源实例 mysql -e SHOW VARIABLES LIKE innodb_page_size; # 目标实例 mysql -e SHOW VARIABLES LIKE innodb_page_size; # 检查 cfg 文件完整性 strings t1.cfg | head -5 # 应包含 page_size、space_id 等字段5.5 空间问题的终极排查清单当所有 SQL 都失效用这张表快速定位问题现象检查项命令/工具预期正常值ibdata1持续增长长事务、Undo 日志未回收SELECT * FROM INFORMATION_SCHEMA.INNODB_TRXtrx_started最早 1ht1.ibd文件过大但数据少页内碎片、未 OPTIMIZESHOW TABLE STATUS LIKE t1Data_free 10%Data_lengthSELECT极慢Buffer Pool 命中率低SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_%
解法)
