問題タブ [innodb]

主キーなしで InnoDB テーブルが作成されると、「非表示の」auto inc キーが作成され、インデックスに使用されます。このキーがマルチマスターセーフかどうかは誰にもわかりませんか?

マルチマスターになるデータベースに自動インクリメントを設定する場合、mysql の標準的なアプローチは、auto_increment_increment と auto_increment_offset をサーバーの数に適した値に設定することです。

InnoDB の隠しキーはこれらの設定を尊重しますか、それともそうする必要がありますか?

私は、約 4 億の innodb_data_pending_reads と innodb_pending_writes を持つ MySQL データベースを持っています。私の他のデータベースは一貫してゼロかそれに近いので、この大きな異常値に気付きました。

この状況の原因は何ですか?

それはどのような悪影響を引き起こす可能性がありますか?

これをダウンさせるために状況をトラブルシューティングするにはどうすればよいですか?

MySQL InnoDB テーブルに URL の膨大なリストがあり、処理する一連の URL について MySQL にクエリを実行するワーカー プロセスがあります。他のワーカー プロセスが同じプロセスを開始してリソースを浪費しないように、URL はすぐに処理中としてマークする必要があります。

現在、最初にこれを行って、いくつかの URL を取得します。

次にコードで、これらの URL を単純にループ処理して、処理中としてマークします。

これがどれほどばかげていて非効率的であるかは完全にわかっています。さらに重要なことに、UPDATE の途中で別のワーカー プロセスがリストを取得しようとしないという保証はありません。これを行う美しい方法は何ですか？トランザクションにする必要がありますか?どうすればよいですか?

別のテーブルを指す外部キーが既にある既存の InnoDB テーブルがあります。

しかし、プライマリ インデックスを指す外部キーを作成しようとすると、エラーが発生します (データ型を確認してください)。

テーブルは User_Id をプライマリとする User です。

User_Id の FK である外部キー Manager_ID が必要です。

INT の両方 長さ 10 の両方 Unsigned...

それでもデータチェックエラーが出る…？

約 5 GB の MySQL / InnoDB データベースの開発コピーに取り組んでいます。

変更スクリプトをテストするためにかなり頻繁に復元する必要があり、mysqldump ファイルの使用にはかなりの時間がかかります。ファイル自体は約 900MB で、読み込みに約 1 時間かかります。重要でないテーブルのデータ挿入を削除し、拡張挿入などを行いましたが、それでもかなり遅いです。

これを行うより速い方法はありますか？.../mysql/database-name、id_logfile#、および ibdata1 からデータベース ファイルのコピーを作成し、データベースを「リセット」する必要があるときにそれらをコピーして戻すことを考えていますが、これは InnoDB で実行可能ですか? ? ibdata ファイルは 1 つのデータベース用ですか? このボックスには複数の InnoBD データベースがありますが、表示されるのは 1 つだけです。

ありがとう！

InnoDB単純なクエリでテーブルに行を追加しようとしています:

しかし、このクエリを試みると、次のようになります。

エラー 1114 (HY000): テーブルzip_codesがいっぱいです

する

同じデータベースに 810,635 行の別のテーブルがあることを考えると、188,959 行になります。

私は にかなり慣れておらず、InnoDB engineでこの問題を経験したことはありませんMyISAM。ここで考えられる問題にはどのようなものがありますか?

編集:これは、zip_codesテーブルに行を追加するときにのみ発生します。

これは私の現在のデータベースの抜粋です（理解しやすいようにテーブル名を変更しました）：

は常にidで作成された代理キーauto_incrementです。

Pet.id代理キーを「スコープ」にするPet.ownerFKか、つまり、複合キー[ownerFk, id]を最小キーとして使用したいと考えています。テーブルを次のように動作させたい:

私は現在MyISAM のこの機能を使用しており、「複数列インデックスのセカンダリ列で指定できますAUTO_INCREMENT。この場合、AUTO_INCREMENT列の生成値は として計算されMAX(auto_increment_column) + 1 WHERE prefix=given-prefixます。これは、データを順序付けられたグループに入れたい場合に役立ちます。 ."

ただし、いくつかの場所でトランザクションが必要なため、さまざまな (そしておそらく明白な) 理由により、MyISAM から InnoDB に切り替えたいと考えています。

InnoDBでこの効果を達成する方法はありますか?

この問題に関するいくつかの投稿を見つけました。それらの多くは、挿入前にテーブルを書き込みロックすることを提案しました。私はこれにあまり慣れていませんが、テーブルの書き込みロックではなく、これを少しオーバーホールするのではないでしょうか? Owner.current_pet_counterヘルパーフィールドとしてa を持つことが可能であれば、書き込み安全なトランザクション (これまで行ったことがない) を持つことをむしろ考えました。

したがって、別の許容される解決策は...

実際には、「スコープ」ID を実際のキーの一部にする必要はありません。私の実際のデータベース設計では、この「機能」を使用する別の「パーマリンク」テーブルを使用しています。現在、不足しているトランザクションの回避策として使用しています。次の代替案を考えました。

私はまだ MySQL でトランザクション/トランザクション変数を扱っていないので、これに重大な問題があるかどうかはわかりません。 注:id一度ペットに与えた sを再利用したくありません。それが私が使用しない理由ですMAX()。このソリューションには注意事項がありますか?

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