タグ付けされた質問 「innodb」

私の実稼働環境の1つでは、RedHatクラスター上で2つのインスタンスが実行されており、1つの実稼働インスタンスがクラスターに関連付けられています。 インスタンス1が占有する24G InnoDBバッファープールと、インスタンス2が占有する12Gの125Gメインメモリがあり、RedHatクラスターに関連付けられていません。データとトランザクションログは両方とも、ext3ファイルシステムのあるLVMディスクパーティションにあります。 パフォーマンスの向上とI / Oスループットの向上のために、に変更innodb_flush_methodすることにしましたO_DIRECT。 MySQLドキュメントを参照して： InnoDBのデータファイルとログファイルがSAN上にある場合、に設定innodb_flush_methodするとO_DIRECT、単純なSELECTステートメントのパフォーマンスが3倍低下することがわかっています。 ハイパフォーマンスMySQL Ver 2および3を参照すると、InnoDB開発者がを使用してバグを発見したと述べていinnodb_flush_method=O_DSYNCます。O_SYNCとO_DSYNCに類似しているfsync()とfdatasync()：O_SYNC一方、同期データとメタデータの両方、O_DSYNCのみ同期データ。 それがアドバイスなしで多くの説明のように思えた場合、ここにアドバイスがあります： Unixライクなオペレーティングシステムを使用しており、RAIDコントローラーにバッテリバックアップ式の書き込みキャッシュがある場合は、を使用することをお勧めしますO_DIRECT。そうでない場合は、O_DIRECTアプリケーションに応じて、デフォルトまたはおそらく最適な選択肢のいずれかです。 グーグルで、私はこのベンチマークレポートを得ました：オンO_DSYNC対O_DIRECT ベンチマークレポート： =================== 1B行の複雑なトランザクションテスト、64スレッド * SAN O_DIRECT：読み取り/書き込み要求：31560140（8766.61毎秒） * SAN O_DSYNC：読み取り/書き込み要求：5179457（1438.52毎秒） * SAN fdatasync：読み取り/書き込み要求：9445774（毎秒2623.66） *ローカルディスクO_DIRECT：読み取り/書き込み要求：3258595（毎秒905.06） *ローカルディスクO_DSYNC：読み取り/書き込み要求：3494632（1秒あたり970.65） *ローカルディスクfdatasync：読み取り/書き込み要求：4223757（1秒あたり1173.04。 ただし、O_DIRECTOSレベルのキャッシュを無効にします。ダブルキャッシュを無効にすると、I / Oスループットが向上します。 O_DIRECTよりも一緒に行くのは良いO_DSYNCですか？これら2つのオプションは少しわかりにくいです。特に本番環境でデータ、読み取り/書き込みに影響を与えることなく、I / Oスループットの向上とパフォーマンスの向上を示すオプションはどれですか？あなたの個人的な経験に基づいたより良い提案はありますか？ 投稿で Rolando Updateを見ることができました： それでも、これらのパラメーターの両方にわずかな混乱があります。私が使用して生産の設定テンプレートのほとんどを見ることができた場合はO_DIRECT推薦ところ、私は任意のを見ていませんO_DSYNC。 システム MySQL 5.1.51-enterprise-gpl-pro-log Red Hat Enterprise Linux Serverリリース5.5 バッテリーライトバックキャッシュ512MBのRAIDコントローラーを搭載したDELL DRAC バッテリーバックアップユニット（BBU）を搭載したDell …

12 mysql  performance  innodb  mysql-5.1  redhat 

私はかなり忙しいInnoDBテーブルを持っています（200,000行、1秒あたり数十のクエリのようなものだと思います）。バグが原因で、（同じ）無効なメールアドレスが含まれる14行を取得し、それらを削除したいと考えました。 私は単純にしようとしたDELETE FROM table WHERE email='invalid address'と、約50秒後に「ロック待ちタイムアウトを超えて」しまいました。行の列にはインデックスが付けられていないため、これは驚くべきことではありません。 しかし、私はそうしSELECT id FROM table WHERE email='invalid address'、それは1.25秒かかりました。実行DELETE FROM table WHERE id in (...)、コピー、貼り付けSELECTの結果から、IDSは、0.02秒を要しました。 何が起こっている？条件付きのDELETEが非常に遅いためタイムアウトする理由を誰かが説明できますか？ ありがとう。 編集：リクエストに応じて、テーブル構造といくつかのexplain結果を投稿しました。また、このテーブルを参照する外部キーがないことにも注意してください。 しかし、状況は私には簡単に思えます。私が選択しているインデックスのないフィールドがあります。これにはテーブル全体をスキャンする必要がありますが、それほど大きくありません。idは主キーであるため、IDによる削除は非常に高速です。 mysql> show create table ThreadNotification2 \G *************************** 1. row *************************** Table: ThreadNotification2 Create Table: CREATE TABLE `ThreadNotification2` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `alertId` bigint(20) DEFAULT …

12 mysql  performance  innodb  delete 

これはほぼ間違いなく他の質問の原因ですが、改ざんまたは検証したい次のログに基づいて仮説があるので、2つを分ける価値があると思いました。 私の仮説では、他のデッドロックは実際には次のクエリの結果であり、innodbステータスが最新のトランザクションのみを表示するという理解に基づいて元のクエリが非表示になっています（これは正しいですか？）。 ログに基づいて、コードをチェックしたところ、次の2つのクエリが順番に実行されていることがわかりました。 db.Execute("UPDATE people SET iphone_device_id=NULL WHERE iphone_device_id=@0 AND people_id<>@1", DeviceID, m_User.people_id); // I have hard coded this query in this snippet to simplify things db.Execute("UPDATE people SET company_id = 444, name = 'Dad', password = '<pass>', temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@gmail.com', phone = NULL, …

12 mysql  innodb  deadlock  ado.net 

私は、JDBCテクノロジーを使用して、自宅でいくつかのテストをREAD_COMMITTED行いREAD_UNCOMMITTEDました。 READ_UNCOMMITTED実際にコミットされていないデータ、たとえばまだコミットされていないトランザクションからのデータを読み取ることができることがわかります（UPDATEクエリを実行できます）。 ご質問 READ_UNCOMMITTEDトランザクションがコミットされていないデータを別のトランザクションから読み取ることができるように、コミットされていないデータはどこに保存されますか？ READ_COMMITTEDトランザクションがコミットされていないデータを読み取ることができない、つまり「ダーティリード」を実行できないのはなぜですか。この制限を強制するメカニズムは何ですか？

12 mysql  innodb  transaction  isolation-level 

レコードの統計データの大規模なセットがあると考えてください。例：20〜30 INTカラム。セット全体が1つのレコードに属しているため、セット全体を1つのテーブルに保持するか、1対1の関係で接続された別のテーブルを作成する方が良いでしょうか。 前者の利点はJOIN、対応するレコードのすべての統計データを回避して迅速にアクセスできることです。 後者の利点は、カラムを整頓することです。最初の列は読み取り中心で、2番目の列は書き込み中心です。もちろん、行レベルのブロッキングでInnoDBを使用しているので、パフォーマンスに大きな影響はないと思います。 一般に、1つのレコードに対して異なるデータセットを分離することが実用的かどうか知りたいですか？

12 mysql  database-design  innodb  normalization  relational-theory 

変更したいInnoDBテーブルがあります。テーブルには約8,000万行あり、いくつかのインデックスを終了します。 列の1つの名前を変更し、さらにいくつかのインデックスを追加したいと思います。 それを行う最速の方法は何ですか？ 「プレーン」alter table、最速のソリューションですか？ この時点で、私が気にしているのは速度です:)

12 mysql  innodb  alter-table  ddl 

mysql / innodbで最新のデッドロックを表示できることがわかりましたが、過去のデッドロックを表示する方法はありますか？デッドロックには2つの問題があります。1つは重要で、もう1つは重要ではありません。重要性の低いデッドロックは1日に数回発生するため、「最新の」デッドロックになります。

12 mysql  innodb  mysql-5.5  deadlock 

私は、CSVファイル（customers.csv）をMySQLテーブル（customers）にインポートするPHPスクリプトに取り組んでいます。 mysqlテーブルにCSVファイルの内容を挿入する前に、最初に元のcustomersテーブルをバックアップしています。 mysqlトランザクションでインポートプロセス全体（バックアップを含む）をラップしています（CSVが途中で破損している場合を考慮し、インポートがアトミックであることを確認するため）。 問題は、ステートメントの直後にROLLBACKを呼び出したときにROLLBACKが機能しないように見えることですINSERT INTO。phpMyAdminを介してデータベースをチェックすると、新しく作成されたテーブルとROROW INSIDE ITがroollback後も存在していることがわかります。 操作のログは次のとおりです。 [2015-01-19 14:08:11] DEBUG: "START TRANSACTION" [] [] [2015-01-19 14:08:11] DEBUG: SHOW TABLES LIKE :table_name; [] [] [2015-01-19 14:08:28] DEBUG: CREATE TABLE `customers__20150119_14_08_20` LIKE `customers` [] [] [2015-01-19 14:08:37] DEBUG: INSERT INTO `customers__20150119_14_08_20` SELECT * FROM `customers` [] [] [2015-01-19 14:08:50] DEBUG: "ROLLBACK" …

11 mysql  innodb  transaction  rollback 

MySQLバージョン コードはMySQL 5.5で実行されます バックグラウンド 次のようなテーブルがあります CREATE TABLE t ( id INT NOT NULL AUTO_INCREMENT , patient_id INT NOT NULL , bed_id INT NOT NULL , ward_id INT NOT NULL , admitted DATETIME NOT NULL , discharged DATETIME , PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; このテーブルは入院中の患者に関するものであり、入院中に各患者が時間を費やしたベッドが格納されています。 各病棟には複数のベッドがあり、各患者は同じ病棟内の異なるベッドに移動します。 目的 私がしたいのは、各患者が別の病棟に移動せずに特定の病棟で過ごした時間を見つけることです。つまり、彼が同じ病棟内で過ごした連続した時間の合計時間を見つけたいのです。 …

11 mysql  innodb  mysql-5.5 

auto_incrementストアドプロシージャを使用して一括挿入を実行した後、BidsテーブルのbidIDに記録されている値に見られるこの奇妙な動作に非常に混乱しています。 INSERT INTO Bids (itemID, buyerID, bidPrice) SELECT itemID, rand_id(sellerID, user_last_id), FLOOR((1 + RAND())*askPrice) FROM Items WHERE closing BETWEEN NOW() AND NOW() + INTERVAL 1 WEEK ORDER BY RAND() LIMIT total_rows; たとえばauto_increment、開始時にbidID値が101であり、100行挿入した場合、終了値は201ではなく213になります。ただし、挿入された行のbidIDは、最大201まで順次実行されます。 以下を確認して、 SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 1 | | …

11 mysql  innodb  mariadb  auto-increment 

これはこの質問に関連しています。InnoDBテーブルのパフォーマンスを向上させるのに役立ちます。 MySQLマニュアルによれば、innodb_flush_log_at_trx_commitはグローバル動的変数です。したがって、SET GLOBALコマンドを使用して変更でき、正常に機能しているようです。 mysql> SET GLOBAL innodb_flush_log_at_trx_commit=2; Query OK, 0 rows affected mysql> SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit'; +--------------------------------+-------+ | Variable_name | Value | +--------------------------------+-------+ | innodb_flush_log_at_trx_commit | 2 | +--------------------------------+-------+ 1 row in set ただし、実際のMySQL設定は変更されませんでした。my.cnfを更新し、MySQLサーバーを再起動すると、機能しました。それで、実行時にグローバル変数を変更できませんか？ 私はデフォルト値を好みinnodb_flush_log_at_trx_commit=1ますが、高速化するために大規模なデータベースの復元プロセスを実行する前に、それを2に変更する必要があります。しかし、プロセスが完了したら、値を1に戻したいと思います。実行時にこれを行うことは可能ですか？ 共有ホスティングサーバーのmy.cnfにアクセスできません。

11 mysql  innodb  windows  configuration 

序文 私たちのアプリケーションは、DELETEクエリを並行して実行するいくつかのスレッドを実行します。クエリは分離されたデータに影響します。つまりDELETE、別々のスレッドからの同じ行で同時発生する可能性はありません。ただし、ドキュメントごとに、MySQLはDELETEステートメントにいわゆる「次のキー」ロックを使用します。これにより、一致するキーと一部のギャップの両方がロックされます。このことはデッドロックを引き起こし、私たちが見つけた唯一の解決策はREAD COMMITTED分離レベルを使用することです。 問題 巨大なテーブルDELETEがJOIN複数ある複雑なステートメントを実行すると問題が発生します。特定のケースでは、警告が2行しかないテーブルがありますが、クエリは2つの個別のINNER JOINedテーブルから特定のエンティティに属するすべての警告を削除する必要があります。クエリは次のとおりです。 DELETE pw FROM proc_warnings pw INNER JOIN day_position dp ON dp.transaction_id = pw.transaction_id INNER JOIN ivehicle_days vd ON vd.id = dp.ivehicle_day_id WHERE vd.ivehicle_id=? AND dp.dirty_data=1 day_positionテーブルが十分に大きい場合（私のテストケースでは1448行あります）、READ COMMITTED分離モードでもトランザクションはテーブル全体を ブロックしproc_warningsます。 この問題は常にこのサンプルデータ（http://yadi.sk/d/QDuwBtpW1BxB9）で再現されます（MySQL 5.1（5.1.59でチェック）およびMySQL 5.5（MySQL 5.5.24でチェック））。 編集：リンクされたサンプルデータには、クエリテーブルのスキーマとインデックスも含まれています。 CREATE TABLE `proc_warnings` ( `id` int(11) NOT NULL AUTO_INCREMENT, `transaction_id` int(10) …

11 mysql  innodb  mysql-5.5  locking  isolation-level 

私には修正できないように見える奇妙な問題があります。私はサーバー/ DB管理者というよりはWebプログラマーなので、ここの誰かが私を助けてくれることを願っています。 状況 私はたくさんの扱うシステムに取り組んでいますupdate、insertとdeleteの要求を。そのため、行ロック機能のストレージエンジンとしてINNODBを選択しました。Gearmanを使用して異なるサーバーでの作業を並列化し、10分ごとに60,000レコードを更新しています。コードはPHPにあり、Zend Frameworkを使用しています。 問題 SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction 上記のエラーは、Gearmanワーカーの1人からほぼ30分ごとに発生します。 の mysql_report MySQL 5.1.63-0+squeeze1 uptime 15 9:52:12 Tue Sep 11 21:25:23 2012 __ Key _________________________________________________________________ Buffer used 55.00k of 16.00M %Used: 0.34 Current 2.92M %Usage: 18.24 Write hit 99.95% Read hit 100.00% …

11 mysql  performance  innodb 

こんにちは、Percona Serverの最新バージョンを実行しています。 サーバーのバージョン：5.5.24-55 Percona Server（GPL）、リリース26.0 私はこれらの特性の10 cpuボックスを持っています。 processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 9 model name : AMD Opteron(tm) Processor 6128 stepping : 1 microcode : 0x10000d9 cpu MHz : 800.000 cache size : 512 KB SSDと64GBのRAMを搭載しています。Innodbは約10GBであるため、innodb_buffer_pool_sizeは10GBに設定されています。 次のようなテーブルがあります。 create table TODAY ( symbol_id integer …

11 mysql  performance  innodb  percona-server 

私は最近、サーバーの再起動時にInnoDBがAUTO_INCREMENT値を再計算する方法のため、IDリストの上限にあるすべてのレコードのIDが再利用される可能性があることを最近読みました。 ユーザーが削除されると、IDに関連付けられたすべてのものが他のテーブルからも削除されるため、通常、これは問題にはなりません。 ただし、過去の会話が維持されるように、「= User＃123 =による投稿」というラベルが付けられたフォーラム投稿を意図的に孤立させておきます。明らかに、IDが再利用される場合、これは問題になります。 この方法でIDが再利用される可能性を低くするのに十分な数の新しいユーザーが常にいるため、私はこれまでこの問題に遭遇したことがありません。ただし、私の新しいプロジェクトでは、サインアップはまれであり、非アクティブなユーザーの削除が頻繁に行われ（特に、「Open Alpha」アカウントはプレビューとして3日間しか持続しないため）、そのようなIDの再利用は3〜3回発生しています。 AUTO_INCREMENTの正しい値を他の場所に保存し、内部値に依存する代わりにそれを使用することにより、問題を「修正」しました。InnoDBに実際の最後の値を記憶させる実際の方法はありますか？

11 mysql  innodb