サービス稼働中にMySQLでALTER TABLEしたら Waiting for table metadata lock が溢れて死んだ - Qiita
サービス稼働中にMySQLでALTER TABLEしたら Waiting for table metadata lock が溢れて死んだMySQL ALTER TABLEすると以下のような挙動でカラム変更されるようです 他のセッションからのREADを許可し、WRITEをブロック 新しいtable定義の一時テーブルを作成 一時tableに元tableのデータをすべてコピー 一時tableを元table名にリネームして元tableを削除 ブロックされていたWRITE系クエリを反映 全コピしてるので、ALTER TABLEを実行する時にどでかいtableのサイズの場合は長い時間WRITEがブロックされるので注意が必要です。 ALTER TABLEを実行した環境 上記を踏まえた上で、以下のようなテーブルにALTER TABLEを実行してカラム追加する事にした レコード数はちょっとしかない READ
MySQLに重いSQLを投げて、帰って来ない時は - takami_hiroki’s blog
重い集計SQLなんかを実行したけど、いつまでたっても帰ってこない時の対処についてです。 まずは、topコマンドで確認します。大抵、以下の例のように、mysqldがリソースを使い切っています。 [root]# top top - 16:20:17 up 15 days, 6:50, 1 user, load average: 5.39, 5.14, 5.04 Tasks: 177 total, 2 running, 175 sleeping, 0 stopped, 0 zombie Cpu(s): 33.7%us, 66.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st Mem: 1048752k total, 826136k used, 222616k free, 194584k buffers Swap: 562264k total
MySQL EXPLAINのそれぞれの項目についての覚書 - Qiita
id/select_type/table どのテーブルがどの順番でアクセスされているか id 実行順番を表す 数字が同じなら複数のクエリが１つのクエリとして実行されている select_typeの詳細 SIMPLE 単一のテーブル サブクエリが絡む場合 PRIMARY 外部クエリ SUBQUERY 相関関係の無いサブクエリ DEPENDENT SUBQUERY 相関関係のあるサブクエリ UNCACHEABLE SUBQUERY 実行する度に結果が変わる可能性のあるサブクエリ DERIVED FROM句で用いられているサブクエリ table 対象テーブルの名称 partition どのpartisionテーブルを使用したか 複数にまたがる時は複数の値が表示される type レコードアクセスタイプ typeの詳細 const pk or uniqueインデックスを使用したルックアップによるアク
MySQLのINSERT ... ON DUPLICATE KEY UPDATEでレコードの挿入/更新を便利に実行 - Qiita
MySQLのINSERT ... ON DUPLICATE KEY UPDATEでレコードの挿入/更新を便利に実行JavaMySQLSQLDatabase 概要 MySQLのINSERT文には"INSERT ... ON DUPLICATE KEY UPDATE"という構文があります。レコードを挿入または重複があった場合は更新したい場合に、INSERT文とUPDATE文を別個に書くよりはるかに便利になります。 本記事ではそんな"INSERT ... ON DUPLICATE KEY UPDATE"の使い方、便利なポイント、その他仕様についてまとめます。 準備 以下のようなテーブルを使います。 select version(); +-----------+ | version() | +-----------+ | 8.0.17 | +-----------+ CREATE TABLE us
[MySQL Workbench] VISUAL EXPLAIN でインデックスの挙動を確認する
Lookup: where col = 1 のような等価比較 VISUAL EXPLAIN でインデックスの挙動を確かめる（本題） 本題です。青→赤の順にコストが大きいことだけ分かっていれば、詳細に見方を覚えなくても使えます。 今回使うのは下の2つのテーブルです。どのユーザがコンバージョンしたかを持っておく cv テーブルと、それが紐付く広告の ad テーブルです。 今回実験のためにざっくり作成したデータについて下に列挙します。 インデックスは簡単のためこの時点で PRIMARY KEY のみ cv は約100万件、 ad は約4000件 cv の status と ad の type はそれぞれ10種類で偏りなし 時刻を保存するカラムは UNIX TIME でここ一ヶ月のデータを格納 ER 図はせっかくなので MySQL Workbench で出力しました。 Workbench は外部キ
![[MySQL Workbench] VISUAL EXPLAIN でインデックスの挙動を確認する](https://cdn-ak-scissors.b.st-hatena.com/image/square/c361eb0b9ed35a0934d2f7c1e008d4330adf3c7c/height=288;version=1;width=512/https%3A%2F%2Fvos.line-scdn.net%2Flandpress-content-v2_1761%2F1666852622685.png%3FupdatedAt%3D1666852623000)
MySQLについて 壱
日本でフリーのデータベース・サーバといえばPostgreSQLが支配的であり、MySQLは永遠の二番手という印象があります。 例えば、@ITのLinux Squareにおける第2回 読者調査結果発表（2000/12/12）によれば、 Web連携コミュニケーションでは､PostgreSQLの一人勝ち Web連携業務システムでは、PostgreSQLとOracleがシェアを争う だそうです。 確かに、二年前はこんなもんでしょうが、日本語化が後発となってしまったMySQLも現在シェアを伸ばしつつあるようです。 amazon.co.jpで検索するとPostgreSQLは19件、MySQLは10件の書籍が検索されました（ちなみにOracleは112件でした）（2002/10/20）。 ※2004年8月20日現在、PostgreSQLは31件、MySQLは25件、Oracleは181件でし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
