2

私はレガシー 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? )

4

2 に答える 2

3

調べる必要がある重要なことは、データベースがどのように使用されているかです。書き込みよりも読み取りの方が多い場合は、MyISAM を使用する必要があります。読み取りよりも書き込みの方が多い場合は、InnoDB を調べる必要があります。

InnoDB と MyISAM の違いを知りたい場合は、ウィキペディアにそれらの違いの優れたリストがあります。

MyISAM は既存の行への書き込みにテーブル レベルのロックを使用しますが、InnoDB は行レベルのロックを使用します。

多くの行が頻繁に更新される大規模なデータベース アプリケーションでは、単一のテーブル レベルのロックによってデータベースの同時実行性が大幅に低下するため、行レベルのロックは非常に重要です。

于 2009-04-13T23:34:35.587 に答える
2

テーブルのアップグレードから MySQL v4/v5 のアップグレードを分離することは価値があります。これにより、潜在的な問題の範囲が縮小されます。

とはいえ、データベースの再起動がまれに発生する場合は、v4/v5 アップグレードの前に InnoDB サーバー オプションを確認してください。これらのオプションの多くはデータベースの再起動を必要とするためです。推奨される 2 つは innodb_file_per_table=1 と innodb_flush_log_at_tx_commit=1 (調べてください) であり、innodb_buffer_pool_size も確認する必要があります。誰も変更していない場合は、ほぼ確実に小さすぎるためです。

MyISAM は長い間使用されます。これは非常に堅牢なオンディスク フォーマットであり、多くの状況で役立ついくつかの特性を備えています。特に、SELECT更新がまったくない、またはほとんどない小さなテーブルに役立つ高速性があります。SELECTとはいえ、MyISAM は同時読み取りをサポートしていないため、非常にホットなテーブル (大量のs) は InnoDB に移行することでメリットが得られます。

MyISAM はほとんどの場合、データベースのクラッシュにREPAIR TABLE必要なだけで生き残ります。InnoDB は常に幸運であるとは限りません。MyISAM は、データベースの下からバックアップすることもできます。事前にテーブルをロックしなくても、問題なく動作するファイルが得られる可能性が非常に高くなります。InnoDB ファイルはそれほど親切ではありません。これが innodb_hot_copy が存在する理由です。

最近、MySQL v4/v5 のアップグレードを行いましたが、SQLJOINの問題は 1 つだけでした: 混合モードです。バージョン 4 のパーサーは、暗黙的なテーブル ジョインと明示的なLEFT JOIN句を混在させてもかなり寛容でした。バージョン 5 はそれほど寛大ではありません。そこで、この機会にアプリを精査し、すべてJOINの を明示的な にアップグレードしましたJOIN。1 つか 2 つのスポットを逃したことを除けば、これは大成功でした。

MySQL v5 と通信する PHP 4 でテスト環境をセットアップすることをお勧めします。これにより、これらすべてをテストできます。

于 2009-04-14T01:01:38.593 に答える