error 1030 (hy000) 几乎总是磁盘空间不足所致，需检查 /var/lib/mysql、/tmp 和 innodb_tmpdir 三处路径；myisam 表会直接标记为 crashed，innodb 则倾向事务回滚或阻塞；innodb_file_per_table 开启后 drop table 可释放空间，但 truncate/delete 不缩表；调优 tmp_table_size 与 max_heap_table_size 应保持一致并结合 created_tmp_disk_tables 监控定位问题 sql。
MySQL 报错 ERROR 1030 (HY000): Got error 28 from storage engine 怎么快速定位
这个错误几乎总是磁盘空间不足的直接信号，但 MySQL 不会告诉你具体是哪个路径满了。关键要查三处：/var/lib/mysql（数据目录）、/tmp（临时表和排序缓冲区默认落盘位置）、以及 innodb_tmpdir（如果显式设置了 InnoDB 临时表路径）。
实操建议：
- 用
df -h检查所有挂载点，特别关注/var/lib/mysql所在分区 - 运行
SELECT @@tmpdir;查看 MySQL 当前临时目录，再检查该路径剩余空间 - 执行
SHOW VARIABLES LIKE 'innodb_tmpdir';，若非空，也要检查该路径 - 注意：即使
df显示还有 5% 空间，也可能因 ext4 的 reserved blocks（默认 5%）导致普通用户进程无法写入 —— 可用tune2fs -l /dev/xxx | grep Reserved确认
MyISAM 表在磁盘满时更容易崩溃，InnoDB 会怎样
MyISAM 对磁盘空间更“敏感”：插入或修复操作中一旦写 .MYD/.MYI 文件失败，会直接标记表为 crashed，后续查询报 Table is marked as crashed；而 InnoDB 在事务写 redo log 或刷脏页失败时，通常先触发 crash recovery 流程，甚至可能主动 abort 连接、回滚事务，但表结构本身不会被标记损坏。
根本差异在于存储引擎对写失败的响应策略：
- MyISAM 是非事务型，写文件即生效，无回退机制 → 失败即中断 + 标记损坏
- InnoDB 依赖 WAL（redo log）和 doublewrite buffer，写失败时可借助日志恢复一致性 → 更倾向于阻塞或报错，而非破坏元数据
- 但要注意：
innodb_file_per_table = OFF时，所有表共用ibdata1，一旦它所在磁盘满，整个实例可能 hang 住，连SHOW ENGINE INNODB STATUS都执行不了
innodb_file_per_table 开启后，删表真的释放磁盘空间吗
开启后，每个表对应一个独立的 .ibd 文件，DROP TABLE 会立即删除该文件，操作系统层面释放空间 —— 这是它最实用的价值。但有两个常见误解：
-
TRUNCATE TABLE和DELETE FROM都不会缩小现有.ibd文件尺寸，只是标记页为可复用；必须用ALTER TABLE ... ENGINE=InnoDB（或OPTIMIZE TABLE）重建表才能回收空间 - 即使删了大表，如果其
.ibd文件曾增长到 100G，而磁盘只剩 20G 空闲，重建操作仍会失败 —— 因为重建需先写新文件，再删旧文件 - 监控建议：用
SELECT table_name, round(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.tables WHERE table_schema = 'your_db' ORDER BY size_mb DESC;快速识别“空间大户”
临时表撑爆磁盘时，tmp_table_size 和 max_heap_table_size 怎么调
这两个参数共同控制内存临时表上限。当查询需要的临时表超过二者中较小值时，MySQL 自动转存为磁盘临时表（MyISAM 格式），写入 tmpdir —— 这就是很多“突然磁盘满”的源头。
调参要点：
- 二者必须设为相同值，否则以小者为准；例如设
tmp_table_size = 64M，max_heap_table_size = 32M，实际生效仍是 32M - 盲目调大有风险：单个复杂 JOIN 可能申请数 GB 内存，引发 OOM Killer 杀 MySQL 进程
- 更稳妥做法：先用
SHOW GLOBAL STATUS LIKE 'Created_tmp%';观察Created_tmp_disk_tables是否持续增长；若远高于Created_tmp_tables，说明大量临时表落地磁盘，此时再结合慢查日志定位具体 SQL 优化 - 临时表路径可迁移：用
SET GLOBAL tmpdir = '/bigdisk/tmp';（需确保 MySQL 进程有写权限），但重启后失效，需写入配置文件my.cnf
磁盘空间问题背后往往不是容量本身，而是空间消耗模式没被看见 —— 比如凌晨的备份脚本没清理旧文件、未加 LIMIT 的 DELETE 语句生成巨量 undo log、或者应用层反复创建又不删的临时表。查清 df、盯住 Created_tmp_disk_tables、定期 du -sh /var/lib/mysql/* | sort -hr | head -20，比调参更能解决问题。
