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

InnoDBテーブル 'idtimes'（MySQL 5.0.22-log）に列があります `id` int(11) NOT NULL, `time` int(20) NOT NULL, [...] 複合一意キー UNIQUE KEY `id_time` (`id`,`time`) そのため、IDごとに複数のタイムスタンプがあり、タイムスタンプごとに複数のIDがあります。 私はすべてのエントリに加えて、存在する場合は各エントリの次の大きな時間を取得するクエリを設定しようとしているので、たとえば次のように返されます： +-----+------------+------------+ | id | time | nexttime | +-----+------------+------------+ | 155 | 1300000000 | 1311111111 | | 155 | 1311111111 | 1322222222 | | 155 | 1322222222 | NULL | | …

18 mysql  innodb  select 

InnoDBで、同時実行パフォーマンスの利点を得ながら、RAMの制限のためにクラスター化インデックスの代わりにMyISAMと同じインデックスを使用することは可能ですか？

17 mysql  performance  index  innodb  myisam 

MySQL 5.0でこのInnoDBエラーが発生しました。Mysqldは完全に停止しましたが、その後ib_logfile0とib_logfile1を失いました。クリーンスタートアップの後、InnoDBは「クラッシュリカバリ」を実行しました。innodb_force_recovery = 4のビジネスを行って、ハングしたMyISAMテーブルを修復しました。これで、レプリケーションの準備が整いました。大きな数字を表明： 111116 15:49:36 InnoDB: Error: page 393457 log sequence number 111 561,760,232 InnoDB: is in the future! Current system log sequence number 70 3,946,969,851. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: …

16 mysql  innodb 

MyISAMからInnoDBに変換したいかなり小さなデータベースがあります。データベース初心者であるため、サイトをダウンさせることなく変換（alter tableを使用）しました。 変換が完了したので、多くの断続的な行が欠落しているようです。これは、おそらく変換中の操作によるものですか？または、問題はどこか別の場所ですか？

16 mysql  innodb  myisam 

Microsoft ADO.NETコネクタからMySQLにアクセスしています。 ときどき、innodbステータスに次のデッドロックが発生し、問題の原因を特定できないことがあります。トランザクション（2）は同じロックを待機して保持しているように見えますか？ ------------------------ LATEST DETECTED DEADLOCK ------------------------ 110606 5:35:09 *** (1) TRANSACTION: TRANSACTION 0 45321452, ACTIVE 0 sec, OS thread id 3804 starting index read mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 368, 1 row lock(s) MySQL thread id 84, query id …

16 mysql  innodb  deadlock  ado.net 

を実行するとSHOW PROCESSLIST、多くの場合、「アイテムの解放」状態の多数のINSERT / UPDATEスレッドがあります。 MySQLのマニュアルでは、スレッドがこの状態になる理由の少なくとも一部がクエリキャッシュに関係していることを示唆しています。データの変更によりキャッシュクエリが無効になっていると考えられます。 ただし、my query_cache_sizeは0に設定され、クエリキャッシュが完全に無効になります。 この状態で非常に多くのスレッドを持つことには、他にどのような理由がありますか？ 関連するテーブルはInnoDBストレージエンジンを使用します。

16 mysql  innodb 

SOで、誰かが最近インデックスを使用してORDER BYを使用しないのはなぜかと尋ねました。 この状況には、3つの列と1万行からなるMySQLの単純なInnoDBテーブルが含まれていました。列の1つである整数にインデックスが付けられ、OPはその列でソートされたテーブル全体を取得しようとしました。 SELECT * FROM person ORDER BY age 彼はEXPLAIN、このクエリがfilesort（インデックスではなく）で解決されたことを示す出力を添付し、その理由を尋ねました。 インデックスが使用される原因となるヒントに もかかわらず、誰かが（他からのコメント/賛成をサポートして）選択された列がすべてインデックスから読み取られたときにソートにのみ使用されると回答しました（つまり、通常は列に出力）。インデックスを走査してからテーブルからカラムをフェッチすると、ランダムI / Oが発生するという説明が後で与えられました。FORCE INDEX FOR ORDER BY (age) Using indexExtraEXPLAINfilesort これが表示されますが、上のマニュアルの章の顔に飛ぶためにORDER BY最適化だけでなく、満足していることに強い印象伝え、ORDER BYインデックスからすると、確かに（追加のソートを実行することが好ましいが、filesortクイックソートとマージソートの組み合わせで、それゆえ 必要があります下の結合しました;順番にインデックスを歩きながらテーブルをシークする必要があります-したがって、これは完全に理にかなっています）が、次のように述べながら、この「最適化」の申し立てを無視することもできません。Ω(nlog n)O(n) 次のクエリは、インデックスを使用してORDER BYパーツを解決します。 SELECT * FROM t1 ORDER BY key_part1,key_part2,... ; 私の読書では、これはまさにこの状況の場合です（ただし、明示的なヒントなしにインデックスが使用されていませんでした）。 私の質問は： MySQLがインデックスを使用することを選択するために、選択されたすべての列にインデックスを付ける必要がありますか ある場合、これはどこに文書化されていますか（もしあれば）？ そうでない場合、ここで何が起こっていましたか？

15 mysql  index  innodb  order-by 

mysqld.logでこのメモを確認します。 [Note] InnoDB: page_cleaner: 1000ms intended loop took 15888ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) このようなことについてここで言及されているようです： 「同期インデックスを実行中」のMySQLインスタンスのストール 私の質問は、このメモがログに記録された場合、どのようなアクションが実行されるべきかということです。 MySQLおよびOSバージョン： mysql-community- server- 5.7.9 -1.el7.x86_64 centos-release-7-1.1503.el7.centos.2.8.x86_64 実行SHOW変数は「％InnoDBの」のような。提案されているように： innodb_page_cleaners | 1

15 mysql  innodb  optimization  logs  configuration 

WAMPディレクトリが誤って別のユーザーによって削除されます。MySQLのデータフォルダのみが使用可能です。また、データベースフォルダー（ "\ bin \ mysql \ mysql5.6.12 \ data \"内のフォルダーとデータベース名）のみが使用可能です。「\ bin \ mysql \ mysql5.6.12 \ data \」のルートにある「ibdata1」を含むすべてのファイルも削除されます。 データベースフォルダーには、以下の拡張子を持つファイルのみが含まれます。 * .frm、*。ibd および「db.opt」ファイル。 データベースをどのように回復できますか？ 私はすでにbdata1を回復しようとしました。しかし、それを取り戻すことができません。また、一部のデータベースにはMYISAMも含まれています。

15 mysql  innodb  recovery  wamp  ibdata 

これらのibdataファイルは、クラッシュリカバリ手順で重要な役割を果たすため、理解したいと思います。このための適切なリソースをウェブ上で見つけることができませんでした。

15 mysql  innodb  logs 

私は実行しEXPLAINます： mysql> explain select last_name from employees order by last_name; +----+-------------+-----------+------+---------------+------+---------+------+-------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-----------+------+---------------+------+---------+------+-------+----------------+ | 1 | SIMPLE | employees | ALL | NULL | NULL | NULL | NULL | …

14 mysql  innodb  index  optimization  explain 

700GBのInnoDBテーブルがあり、それ以上データを書き込みません（読み取りのみ）。保持している古いデータを削除し、そのディスク領域を再利用します（不足しているため）。削除部分は非常に簡単です。auto-incプライマリインデックスがあるので、それを使用してチャンク単位で繰り返し、行を削除できますが、スペースを取り戻すことはできません。私はOPTIMIZE TABLEそう思いますが、700GBのテーブルではそれが永遠にかかるかもしれませんので、見落としている別のオプションはありますか？ RolandoMySQLDBAによる編集 テーブルがmydb.mytableであると仮定すると、次のクエリを実行してここに投稿し、テーブルの縮小に必要なディスク容量を判断できるようにしてください。 SELECT FORMAT(dat/POWER(1024,3),2) datsize, FORMAT(ndx/POWER(1024,3),2) ndxsize, FORMAT((dat+ndx)/POWER(1024,3),2) tblsize FROM (SELECT data_length dat,index_length ndx FROM information_schema.tables WHERE table_schema='mydb' AND table_name='mytable') A; 許可されている場合は、テーブル構造も確認する必要があります。 ノーム編集 これはクエリの出力です： datsize ndxsize tblsize 682.51 47.57 730.08 これがテーブル構造です（SHOW CREATE TABLE） `CREATE TABLE `mybigtable` ( `id` int(11) NOT NULL AUTO_INCREMENT, `uid` int(11) NOT NULL, `created_at` datetime …

14 mysql  innodb 

LOAD DATA INFILEを介して100GBのファイルをロードしています。私はMyISAMで数時間成功しました。 私は今InnoDBを使って試しています。ロードは10MB /秒以上で高速に開始されます（テーブルファイルの増大を監視し、file_per_tableオンになっています）。 しかし、約5 GBのデータの後、2〜4 MB /秒の範囲に低下します。20GBを超えると、約2 MB /秒になりました。 InnoDBバッファープールのサイズは8Gです。そして、LOAD DATA INFILEコマンドを実行する前に次のことを行いました。 SET @@session.sql_log_bin=0; SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; alter table item_load disable keys; //Run LOAD DATA INFILE.... 開始が順調に進み、時間がたつにつれて速度が低下している理由がわかりません。 また、同じ設定を使用して、InnoDBとMyISAMおよび5GBテストデータセットを使用したテーブルで同じLOAD DATA INFILEコマンドを実行すると、MyISAMは20倍高速になりました。 InnoDB： mysql> LOAD DATA CONCURRENT LOCAL INFILE '/tmp/item' REPLACE INTO TABLE item_load; Query OK, 2630886 …

14 mysql  performance  innodb  myisam 

Mac上のローカルmysqlに大きなSQLダンプ（2GB）をインポートしようとしています。過去にこれを行うことができました（私はMAMPを使用していました）が、今では行7758でERROR 2006（HY000）を受け取ります：ダンプをインポートしようとするたびにMySQLサーバーがなくなっています。データベースにはinnodbテーブルが含まれます。 my-innodb-heavy-4G.cnfファイルをmy.cnfにコピーして、これらの設定が役立つかどうかを確認しましたが、うまくいきませんでした。 何を微調整するかについてのアイデアはありますか？ ここから「Mac OS X ver。10.6（x86、64ビット）、DMG Archive」を使用しています：http : //dev.mysql.com/downloads/mysql/

14 mysql  innodb  dump  mac-os-x 

VARCHAR（20）列を持つ大きなテーブルがあり、それをVARCHAR（50）列になるように変更する必要があります。通常、この特定のテーブルでALTER TABLEを実行（TINYINTを追加）するのに約90〜120分かかります。そのため、データベースのユーザーに影響を与えないために、土曜日または日曜日の夜にしかできません。可能であれば、その前にこの変更を行いたいと思います。 列にもインデックスが付けられますが、列の長さを変更した後にインデックスを再構築する必要があるため、ALTER TABLEが遅くなると思われます。 Webアプリは、MySQLレプリケーション環境（26個のスレーブと1個のマスター）でセットアップされます。一度どこかで、1つの方法は最初に各スレーブでALTER TABLEを実行し（ユーザーへの影響を最小限に抑える）、次にマスターでこれを行うことを思い出しますが、それからALTER TABLEコマンドをスレーブに複製しようとしませんか？ 私の質問は次のとおりです。ユーザーの混乱を最小限に抑えてこのテーブルを変更する最良の方法は何ですか？ 編集：テーブルはInnoDBです。

14 mysql  replication  index  innodb  alter-table