小编Ste*_*e06的帖子

我在我的工作站上运行 MySQL 5.5 服务器以进行科学数据分析，并想知道如何配置 MySQL 以便在性能方面发挥最大作用。我通常运行的查询类型涉及 10-20 个表的连接，并且可以运行很长时间，一到几分钟也不例外。只有极少数用户同时访问数据库（最多 5 个）。我将服务器从具有 2.2 GHz 双核和 4 GB RAM 的联想 Thinkpad T61 移动到以下带有手工选择组件的全新机器：

• Intel i7 3770，4x 3.4 GHz（以 4x3.7 GHz 运行）
• Z77芯片组
• 16 GB DDR3 1600 内存
• Windows 7 教授 64 位
• Windows 和 MySQL 服务器在 Intel 520 系列 SSD 驱动器上运行。

第一次测试（在两台机器上运行相同的查询）显示新机器的速度有了明显的提高，但查询仍然需要很多时间，我原以为会有更多的提升。有问题的查询得到了相当好的优化，即所有表都有适当的键，这些键也被用作“解释扩展”。

现在到我当前的 MySQL 设置：首先我应该提到我很久以前从 MyISAM 转移到 Innodb。

我的一些 my.ini 调整（即偏离默认设置）：

# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to …

不久前，运行 MySQL Server 5.5.31 的 Windows 7 系统崩溃并损坏了 InnoDB 数据库。可用的每周备份并未涵盖在此期间创建的所有表，因此我将努力从数据中尽可能多地恢复。崩溃后，我将 MySQL 的整个数据文件夹复制到外部驱动器。我想以此作为我的救援尝试的起点。

在下面，我将描述我的（尚未令人信服的）救援尝试的步骤，并感谢您对如何改进它的任何评论或指导：

1. 我现在已经在另一台 PC 上全新安装了 MySQL Server 5.5.31
2. 我在命令提示符下使用“net stop MySQL”停止 MySQL 服务。
3. 我已经认为我需要调整 my.ini 文件中 innodb 日志文件的大小，因为它偏离了默认值 (19MB) (256 MB)。
4. 在my.ini中，我还设置了innodb_force_recovery=6
5. 在全新安装的数据文件夹中，我用从崩溃的机器中恢复的文件覆盖了 ibdata1、iblogfile0、iblogfile1 文件。我还将相关的数据库（UPDATE：和 mysql）文件夹复制到这里（不是标准的mysql、 test 和 performance 文件夹）。
6. 我用“net start MySQL”启动 MySQL 服务。
7. 我进入 MySQL Workbench，打开我的服务器实例，转到数据导出，基本上保留默认设置，并将我的数据库的每个表作为单独的转储文件导出。我还设置了要转储的存储过程。否则我不会更改那里的默认设置。
8. 我开始转储过程；它通过了 195 个表中的 43 个。在这 43 个中，
   
   • 有些无法恢复，产生错误“ mysqldump: Got error: 1146: Table '...whatever...' 在执行 LOCK TABLES 时不存在”，
   • 但很多都可以。我假设当转储没有产生任何错误时，表的数据没有损坏。
     然后，在 44 日之后，所有其他表转储都失败，因为它报告服务器无法再连接到：
     “ mysqldump: Got error: 2003: Can't connect …