我有一个遗留的web应用程序php4/mysql4 (MyISAM,db包含一些cms,一些用户数据,一些日历应用程序)。现在,我将迁移到具有php5/mysql5的新服务器。
我应该在迁移mysql数据库时更改为InnoDB吗?-预期的优点/缺点/风险?- MyISAM是否已被弃用,或者有一天它会被弃用?或者我可以安全地保存它吗?-我听说MyISAM很容易损坏,InnoDB呢,它能防止崩溃吗?- InnoDB更容易备份和恢复,还是更安全?
当我进行更改(中断SQL查询)或破坏逻辑(由于更改了的锁定机制)时,它会破坏我的代码吗?如果是这样,典型的场景是什么?
(对于php问题,我创建了一个不同的问题:Migrating php4/mysql4 to php5/mysql5: expected php issues?)
发布于 2009-04-14 01:01:39
将MySQL v4/v5升级与表升级分开是值得的。这缩小了潜在问题的范围。
也就是说,如果重新启动数据库的情况很少发生,那么在v4/v5升级之前花一些时间检查InnoDB服务器选项,因为它们中的许多都需要重新启动数据库。推荐的两个是innodb_file_per_table=1和innodb_flush_log_at_tx_commit=1 (查找它们),你也应该看看innodb_buffer_pool_size,因为如果没有人修改它,它几乎肯定会太低。
MyISAM将存在很长一段时间。它是一种非常健壮的磁盘格式,在许多情况下都有一些有用的特性。特别是,它有一个快速的SELECT
,这对于没有或很少更新的小型表很有用。也就是说,非常热的表(大量的SELECT
)将从迁移到InnoDB中受益,因为MyISAM不支持并发读取。
MyISAM几乎总是在数据库崩溃时幸免于难,只需要一个REPAIR TABLE
。InnoDB并不总是那么幸运。还可以从数据库下备份MyISAM;即使您事先没有锁定表,您也很可能得到一个可以正常工作的文件。InnoDB文件并不那么友好;这就是innodb_hot_copy存在的原因。
我们最近经历了SQLv4/v5升级,只有一个MySQL问题:混合模式的JOIN
。版本4的解析器在混合隐式表连接和显式LEFT JOIN
子句时相当宽松。版本5就不那么宽宏大量了。所以我们利用这个机会清理了应用程序,并将所有的JOIN
升级到了显式的JOIN
,除了一两个遗漏的地方,这是非常成功的。
我建议你设置一个PHP4与MySQL v5对话的测试环境。这将让您测试所有这些。
发布于 2009-04-13 23:34:36
你应该调查的关键是,你的数据库是如何被使用的。如果它更多的是读而不是写,那么你应该坚持使用MyISAM,如果它更多的是写而不是读,你应该研究InnoDB。
如果你想知道InnoDB和MyISAM之间的区别,那就Wikipedia has a great list他们的区别。
MyISAM对写入任何现有行使用表级锁定,而InnoDB使用行级锁定。
对于经常更新许多行的大型数据库应用程序,行级锁定至关重要,因为单个表级锁可以显著降低数据库中的并发性。
https://stackoverflow.com/questions/745787
复制相似问题