macos数据库启动失败常因系统宗卷（/）空间不足，而非磁盘满；需检查df -h、清理time machine本地快照与缓存，并修复apfs容器大小，mysql还需删除ibtmp1临时文件。
macos中数据库启动失败，常被误判为“磁盘满”，实则多由apfs容器空间分配失衡或系统宗卷被快照/缓存挤占所致——数据库（如postgresql、mysql、docker内嵌db）启动时需临时写入日志、预分配共享内存或创建wal文件，若系统宗卷（macintosh hd）可用空间低于几gb，即使数据宗卷（- data）尚有百gb空闲，也会直接报错“no space left on device”或“could not write lock file”。
确认是否真因空间溢出而非其他故障
数据库启动失败前，先验证底层存储状态是否健康：
- 打开终端，运行
df -h，重点看/（即系统宗卷）和/System/Volumes/Data（数据宗卷）的Use%。若/显示 95%–100%，而/System/Volumes/Data仅用 30%，就属典型宗卷失衡 - 运行
diskutil apfs list，检查主容器 Size 是否等于物理磁盘总容量（如 SSD 标称512GB，容器应接近500GB）。若明显偏小（如仅320GB），说明容器未吃满硬盘，剩余空间无法被任何宗卷使用 - 执行
tmutil listlocalsnapshots /，查看是否有大量以com.apple.TimeMachine.开头的本地快照——它们默认驻留在系统宗卷，单个可达10–30GB，且不显示在“储存空间”界面中
优先释放系统宗卷的可清理空间
数据库依赖系统宗卷完成初始化动作，必须确保其有至少5GB真实可用空间：
- 进入系统设置 → 通用 → 储存空间 → 管理，依次点击“缓存文件”“日志文件”“旧文件”，执行“删除”
- 在终端中安全删除非系统更新类快照：
sudo tmutil deletelocalsnapshots com.apple.TimeMachine.2026-04-22-153000
（将示例时间替换成
tmutil listlocalsnapshots /输出中的旧快照名；避开com.apple.os.update开头的，那是升级必需快照） - 清空用户级缓存（不影响系统）：
rm -rf ~/Library/Caches/* sudo rm -rf /Library/Caches/*
注意：不要删
/var/folders或/private/var/db，这些受SIP保护且删后可能引发权限异常
修复APFS容器与宗卷的空间映射关系
释放空间后若数据库仍无法启动，大概率是容器或宗卷元数据未同步：
- 重启进入 macOS 恢复模式（开机按住 Command + R）
- 打开“磁盘工具” → 选取“显示”→“显示所有设备”
- 先选中 数据宗卷（如 Macintosh HD - Data）→ 点“急救”→ 运行
- 再选中 系统宗卷（Macintosh HD）→ 点“急救”→ 运行
- 最后选中 APFS容器（如 Container disk1）→ 点“急救”→ 运行
- 若容器Size仍小于物理磁盘，返回终端（恢复模式下可打开终端），执行：
diskutil apfs resizeContainer disk0 0
（
disk0替换为你的主硬盘编号，可通过diskutil list确认；末尾0表示扩展至最大可用）
针对常见数据库的补充操作
某些数据库对空间敏感度更高，需额外处理：
- PostgreSQL：检查
/usr/local/var/postgres/pg_wal/是否堆积大量WAL文件，可临时移动旧归档（勿直接删）到外置盘再重启服务 - Docker Desktop 内嵌数据库：在 Docker 设置 → Resources → Disk image size 中调高镜像上限，并勾选“Use the new Virtualization framework”，避免容器层空间耗尽
- MySQL via Homebrew：运行
brew services stop mysql→mysql.server stop→ 清理/usr/local/var/mysql/ibtmp1（临时表空间文件，可安全删除）→ 再启动
不复杂但容易忽略
