我有几个表是10几百万行，并有多个索引。 当转储和重新加载数据时，由于索引需要很长时间重新插入，或者插入没有索引的索引，然后重新索引。
据我所知，索引为数据库引擎提供了一种在磁盘上定位logging的快速方法，由于数据库转储和重新加载可以或可以有效地改变磁盘上数据的位置，索引可能会失效。 然而，它仍然好像你应该能够通过连续和顺序地查找磁盘上的所有logging来优化一个表，然后只需要索引指向一个起始位置加偏移量。 有没有人在这种types的事情做任何工作？
所需的function：我可以转储数据原始，将其加载到顺序不间断的磁盘区域，然后加载索引并告诉引擎使用新的表格起始位置进行更新。 经过这个search后，我什么都看不到
MySQL将原始数据和索引文件存储在数据目录中; 每个表通常有3个表名，每个表名与表名称相同，文件扩展名不同，全部包含在带有数据库名称的文件夹中。 这些文件可以复制到其他地方进行备份（可以根据您的需要进行压缩和/或encryption）， 但是您必须停止数据库或获取所有表的读取locking – 如果您复制数据正在被写入的时候一个表的文件，你的备份可能会被损坏，无法使用！ （或者，停止MySQL或获取锁，拍快照（如果您足够幸运，可以使用LVM），然后在进行备份时重新启动/释放锁。
从备份中恢复这些文件时：
我已经多次使用这个过程在MySQL，版本3,4和5上备份和恢复数据库，没有任何问题。 可能是一个好主意，以防万一，以防万一，每个恢复表检查。
重要提示： 只有当您恢复到您备份的相同主要版本时，此过程才会起作用！ 也就是说，如果以这种方式制作MySQL 5数据库的副本，则必须恢复到MySQL 5.向上（并且只能向上）1版本（例如复制4，恢复到5）也应该可以工作，但是可能需要更新文件结构，因此可能不会比你的方法更快/更好。
您可能想查看磁盘快照…和/或批量交易。
对于大多数linux系统，您可以使用磁盘pipe理器创build当前文件系统的快照，然后使用原始数据库文件备份/复制/移动/执行任何操作。 这种方法唯一的缺点是在创build快照时，mysql服务器需要暂时脱机。 这将确保您有一个正确提交到磁盘的数据库。 完成快照后，您可以简单地删除快照并继续。 （不需要重新启动mysql或其他任何东西）恢复过程只是简单的复制/移动原始数据文件到正确的数据目录和解雇MySQL的问题。
你也可以使用mysql的“批量事务”命令来绕过所有的一致性检查，等等。 在大多数大宗交易中，重build指数仍然存在一段滞后期。 这种方法的优点是在每个logging被插入时，最后只有一个大的一致性检查，而不是1个。
当所有的事情都说完之后，对于超过200万条logging的数据库来说，真的没有什么好的办法。 这是你开始看到关系数据库中的缺陷，并开始寻找nosql的替代品。 （是的，我知道有很多关于这个问题的争论）