我有一张非常大的桌子，大约有 100 万条记录。由于性能不佳，我已经优化了查询并需要更改索引。
我使用 更改了它ALTER，现在我真的不确定它在 InnoDB 中是如何工作的。我需要重新启动 MySQL 服务器吗？如果我需要重新启动 MySQL 服务器，我如何保持表之间的数据完整性（这样我就不会错过内存中没有写入数据库的数据）？
我用谷歌搜索，发现在 MySQL 重启的情况下，我需要使用全局变量innodb_fast_shutdown——当我设置它时它会做什么，如果我不这样做呢？这不是很清楚。
我是 InnoDB 的 MySQL 领域的新手。非常感谢任何帮助。
所以改变了它
ALTER，现在我真的不确定这在innodb中是如何工作的？
你是说你添加了索引ALTER TABLE ... ADD INDEX ...（或者ADD KEY——它们是要求完全相同的东西的两种方式）大概？
一旦ALTER TABLE完成执行并且您的mysql>提示返回，就不需要其他任何东西了。此时，该表具有其新索引并且该索引已完全填充。
大功告成，无需重启服务器。
innodb_fast_shutdown既然您提到了它，我还将尝试帮助您消除您对InnoDB 中的内存/磁盘划分的误解。
innodb_buffer_pool_size当 MySQL 服务器启动时，InnoDB 向操作系统 发出一个大小为 1 的内存块的一次性请求，在此示例中来自我的一个测试服务器的 MySQL 错误日志：
130829 11:27:30 InnoDB: Initializing buffer pool, size = 4.0G
这是 InnoDB 在内存中存储表和索引数据的地方，最佳性能是当这个池足够大以容纳所有数据和索引时。读取行时，首先将表空间文件中的页面读入缓冲池，然后从那里提取数据。如果进行了更改，则将更改写入缓冲池中表数据和索引的内存副本，并最终将它们刷新到磁盘。池中的页面要么是“干净的”——意味着它们与磁盘上的页面相同，因为它们在加载后没有被更改，或者如果更改，则更改已经写入磁盘——或者是“脏的”这意味着它们与磁盘上的内容不匹配。
但是，InnoDB是否符合 ACID - 如果它只在内存中写入更改并且更改没有在内存中更改之前的某个地方立即持久化，那么这不可能是真的......并且“某处”是重做日志- 在磁盘上 - 立即以允许此操作比实时更新实际表空间文件本身更快的格式存储要在内存中进行的更改。
反过来，该innodb_fast_shutdown变量确定 MySQL 是在关闭之前完成写入重做日志的所有内容 -还是在它启动备份之后完成。无论哪种方式，它都可以正常工作，但是如果您需要更快地关闭服务器，那么无论您做了什么更改，让它稍后恢复所有内容都会更快且非常安全。
重要的是，我不知道您读过什么，但在日常操作中，您永远不需要弄乱 的值，innodb_fast_shutdown除非您正在关闭以准备升级到您的 MySQL 服务器版本（然后它主要是安全预防措施）。磁盘上的数据始终与内存中的数据一致，要么是因为表空间文件已经与数据的内存表示一致，要么是因为对表空间文件的挂起更改安全地存储在重做日志中，它们将在其中当服务器重新联机时正确处理。
在. ALTER TABLE_ ALTER_ALTER