【MySQL】インポート時間短縮のためのDBパラメータチューニング / 開発者向けブログ・イベント | GMO Developers
バイナリ互換性がないMySQLバージョン間（5.6→8.0）のDB移行が必要となり、DBを停止して、mysqldumpによるデータ移行を計画しました。その際にDBのダウンタイムをなるべく短くするため、インポートにかかる時間をパラメータチューニングによって短くできないか検証しました。 注意点 本記事の内容は、筆者の個人的な見解や認識に基づいて作成しているため、正確性、信頼性、完全性、最新性を保証するものではありません。 本記事は、2023/04/25 時点の情報をもとに作成しております。 最新の情報については、他の情報源と照らし合わせてご確認ください。 今回紹介するパラメータはインポート時に一時的に設定するパラメータと仮定しており、運用時は適さないパラメータもあります。 インポートが完了したら運用に適したパラメータへの変更をお願いします。 前提条件 インポートするデータ スキーマ毎にmysq
MySQL – ごく単純なUPDATEがなぜか遅い時がある | memorandum-plus
先日不可解な事象に直面しました、ごく単純な1行のUPDATE文が稀に非常に遅くなる時があったのです。稀に、といいますが検証してみたところ、50回実行して1～2回程度の発生頻度。 軽く「UPDATE 遅い」などで調べてみたところ、どれにも該当しないように見えました。 ググった情報 当方の状況 といった感じです。 うーん、わからん！ということで検証して調査しました。 検証方法 わたしの環境の具体的な名称などはぼかしますが、問題が発生していたSQLは、ほぼ以下のようなモノでした UPDATE `table_name` SET `col_name` = 'ランダムな文字列' WHERE `id` = 'PRIMARYなID' カラム`id`はPRIMARYです、1カラムで一意に特定できるのでクッソ早いはず。 検証では’ランダムな文字列’をphp側で毎回生成し、’PRIMARYなID’は対象を1レコ
innodbのcount遅い？遅くないしっ！Σ(ﾟдﾟlll)
innodbのcount遅い？遅くないしっ！Σ(ﾟдﾟlll) 2013/7/24 2015/9/7 MySQL 「MySQLのinnodbはcountすると遅い」…という知識だけが先行してしまい、イケてない設計をしてしまった。。。 それは、ソーシャルアプリでよくある「未確認通知数」を算出するために発生した。 ↓こーいうの パッと思いついた設計は以下の3つ。 通知テーブルに確認フラグを持っておき、未確認の件数をcountする。 ☆メリット ：シンプル。生産性＆保守性UP。 ★デメリット：速度が遅い（と思っていた）。 KVSに未確認件数を保持しておく。 ☆メリット ：速度が速い。 ★デメリット：KVSはトランザクションが無いので整合性の保障がない。 専用のテーブル＆列を作ってカウントアップ・ダウンする。 ☆メリット ：取得対象が1レコードなので速度が速い。 ★デメリット：同一ユーザへのアクシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fake on Twitter: "MySQLの日時の計算はUNIX_TIMESTAMP経由じゃなくてTIMEDIFF/ADDTIMEが正解か。2038年問題もあるけど、BENCHMARKしてみたら、TIMEDIFF+TIME_TO_SECの方が倍ぐらい速かったのにもびっくりした。"
Loading...
