PREFACE:这听起来很糟糕，但请务必在采取行动之前阅读此答案中的所有内容。慢慢来，你不会把事情弄得更糟。阅读每个步骤，希望这足够清楚，让您能够遵循并让 MAMP Pro 中的 MySQL 数据库服务器重新启动并运行。
所以，你的 InnoDB 数据库似乎崩溃了。不是应用程序本身。关键在日志中：
140527 15:06:58 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 791075520
140527 15:06:58 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 791076717
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 8402.
InnoDB: You may have to recover from a backup.
看起来您正在这里使用 MAMP PRO：
/Library/Application Support/appsolute/MAMP PRO/db/mysql
那么问题是，您有 MAMP Pro 数据库的备份吗？要么通过mysqldump或者是其他东西？您的 MAMP 安装中是否还有其他 InnoDB 数据库？
另外，你说你能跑mysqldump，但是数据库崩溃的可能性确实不大。所以我假设当你跑步时mysqldump这是在您的系统上另一个单独安装的 MySQL。 MySQL 二进制文件，例如mysqldumpMAMP 或 MAMP Pro 中的与系统范围内的不同mysqldump。它们是两个 100% 不同的安装。您可以检查哪个mysqldump通过输入以下命令来使用：
which mysqldump
查看您认为您正在使用的内容的完整路径。 MAMP 安装mysqldump- 以及其他相关的二进制文件 - 位于此处：
/Applications/MAMP/Library/bin/
并直接运行它而无需修改您的$PATH值（完全是另一回事）是像这样运行它：
/Applications/MAMP/Library/bin/mysqldump
请仔细阅读：请注意，我在下面给您的建议是我介绍的处理此类情况的各种方法。如果 InnoDB 数据库不重要，只需执行我的第一个建议：丢弃 InnoDB 特定的数据库文件。如果你有一个mysqldump备份，做同样的事情但恢复mysqldump backup.
另外，InnoDB 是not默认存储引擎。你必须不遗余力地设置它。默认是MyISAM。 MySQL 中创建的任何新数据库都将是 MyISAM。所以这会对你有所帮助。您需要充分思考，找出哪些数据库设置了 InnoDB 存储引擎。如果你说你有 25 个，但只有 1 个有 InnoDB，很简单的解决方案。但如果您有 25 个数据库，您应该养成定期创建数据库的习惯mysqldump备份。如果您有备份，这将是一件令人头疼的事情，但却是一个很容易解决的问题。
一种选择：删除损坏的 InnoDB 内容并从mysqldump backup.
如果我是你，我要做的第一件事就是备份mysql目录在/Library/Application Support/appsolute/MAMP PRO/db/所以你至少可以备份损坏的文件以防万一。
然后我会删除以下文件：
/Library/Application Support/appsolute/MAMP PRO/db/mysql/ib_logfile0
/Library/Application Support/appsolute/MAMP PRO/db/mysql/ib_logfile1
/Library/Application Support/appsolute/MAMP PRO/db/mysql/ibdata1
这些是 InnoDB 特定的文件。删除它们，然后尝试再次启动 MAMP。它应该出现。但是 MAMP 中的任何 InnoDB 数据库都将处于某种“僵尸”状态。您应该删除这些数据库并从备份中重新创建。或者如果可以的话从头开始。
另一种选择：尝试使用以下命令重新启动并运行 MySQL 服务器innodb_force_recovery.
现在，如果您需要恢复该数据库，您可以运行尝试设置innodb_force_recovery如此处所述。
对于 MAMP Pro，您似乎可以按照以下说明编辑 MySQL 配置文件：
- 启动 MAMP Pro。
- 如果 MAMP Pro 服务器正在运行，请将其停止。
- 选择文件 -> 编辑模板 -> MySQL my.cnf
- 将出现一个编辑器窗口。
- 如果出现警告消息，请单击“确定”进行确认。
- 找到“[mysqld]”部分
- 在本节的最后一行下方添加以下行：
innodb_force_recovery = 1
And 正如 MySQL 文档所解释的，这严格来说是为了让数据库启动并运行，以便您可以通过以下方式进行备份mysqldump:
在这种情况下，请使用 innodb_force_recovery 选项强制
InnoDB存储引擎启动同时防止后台
停止运行操作，以便您可以转储表。
现在大约有 6 个不同的值innodb_force_recovery但你真的应该只尝试1目前。如果您想尝试这 6 种方法中的每一种，请参阅以下详细说明：
1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到损坏的页面，也让服务器运行。试图使
SELECT * FROM tbl_name 跳过损坏的索引记录和页面，
这有助于倾倒桌子。
2（SRV_FORCE_NO_BACKGROUND）
防止主线程和任何清除线程运行。如果一个
清除操作时会发生崩溃，此恢复值
阻止它。
3（SRV_FORCE_NO_TRX_UNDO）
崩溃恢复后不运行事务回滚。
4 (SRV_FORCE_NO_IBUF_MERGE)
防止插入缓冲区合并操作。如果它们会导致车祸，
不做他们。不计算表统计信息。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库时不查看撤消日志：InnoDB 对待
甚至是未完成的已提交事务。
6（SRV_FORCE_NO_LOG_REDO）
不执行与恢复相关的重做日志前滚。
使用此值，您可能无法执行除
基本的SELECT * FROM t， 没有WHERE, ORDER BY，或其他条款。更多的
复杂的查询可能会遇到损坏的数据结构并失败。
如果表数据损坏导致您无法转储
整个表内容，一个查询ORDER BY primary_key DESC子句也许能够转储表的一部分
损坏的部分。
如果您碰巧启动并运行了数据库，然后可以执行mysqldump那么恭喜你！你是清白的！最好的下一步是
- 停止 MySQL 数据库服务器
- 去除
innodb_force_recoveryMySQL 配置中的选项，以便数据库服务器可以正常运行。
- 重新启动 MySQL 数据库服务器。
- 从服务器中删除损坏的 MySQL 数据库（不要删除转储文件！那是你的备份！）
- 创建一个要恢复的新数据库。
- 导入
mysqldump备份到新数据库。
你应该完成了。
