Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
![[MySQL]大量のレコードをDELETEする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/745e1ea7d251c7714f5ad03be79df802c055d09b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGODYwNzUlMkZwcm9maWxlLWltYWdlcyUyRjE2Mzk5OTc3Mjk_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9YjUzOTYwYjMwNTlmYjcxNTM2ZDg5YTUzMDBhNjk2ZDQ%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D1e70476a1a17aabe70be40bc09ef5743%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCTXlTUUwlNUQlRTUlQTQlQTclRTklODclOEYlRTMlODElQUUlRTMlODMlQUMlRTMlODIlQjMlRTMlODMlQkMlRTMlODMlODklRTMlODIlOTJERUxFVEUlRTMlODElOTklRTMlODIlOEImdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz02MjEwNzcwMjFiYTNmNGQyMDQ1MTQ1ODBlNWM0MWFjZg%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBzYW95YWdpMiZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPTRiN2U3YmM0MWFlZTVlNDQxNzQ5NmIwODQ3ODU5OGVk%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D2c0135ca827f8557e7f774f639b68b45)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 数年やってないと記憶の彼方に飛んでいきそうだったので、MySQLのクエリ改善方法のテンプレを自分用に明記。 スロークエリを除去する事。 初めはとにかく観察。スロークエリを出力させて、観察する。 indexが効かないクエリを排除する。 indexが予期できない条件分岐によるクエリを廃止する。 場合によってはソートをさせない。コード側でソートさせる。 JOINをわざとさせないのも一つの手。後にDB分離レベルのシャーディング等が発生する可能性のあるようなシステムでは、JOIN禁止にする事は決して間違ってはいない。 indexを必ず効かせる レ
以前投稿したbgwokerで超簡易クラスタ管理を進化させたpg_keeperについて投稿。 コンセプト このツールのコンセプトは**「PostgreSQLの自動フェイルオーバーを簡単に設定する」です。 Pacemaker/corosyncやrepmgrを使えばより細かく、柔軟に設定することが出来ますが、その一方設定が面倒だったり、多くのケースではそこまで柔軟な設定は必要ないと思ったので、「マスタ、スレーブ2台構成でもっと簡単に可用性を向上させたい」**と思い作りました。 監視プロセスはPostgreSQLのプロセスの一つとして動作するので、高機能なクラスタリングミドルウェアによくある監視プロセス自体の起動・停止・監視等の作業は発生しません。 ただし、pg_keeperが対応しているのはマスタ1台、スタンバイ1台で同期レプリケーションを使用した場合のみです。 スタンバイを2台以上使用するケー
取得したデータを DB に格納 集めてきた Tweet データを DB に格納する部分。 MySQL 用のドライバを利用して、Python から MySQL を操作する。 Python で Twitter からの情報収集 (環境構築編) 環境構築等はこちら MySQL 用ドライバ 環境構築時にインストールしたものを利用する。 サンプルコード 実際の使用法はサンプルコードを見てもらう方が早いはず。 サンプル中の execute_sql() 関数のようにしてやると、指定したDBでSQLを実行できる。 mysql_tools.py #!/usr/bin/env python # -*-coding:utf-8-*- import MySQLdb ### Functions def main(): local_db = { "host": "localhost", "user": "root",
<?php ini_set('display_errors', 1); error_reporting(E_ALL); function get_pdo() { $dsn = sprintf('mysql:dbname=%s;host=%s;charset=%s' , 'database' , 'localhost' , 'utf8' ); $username = 'root'; $password = 'password'; $options = [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]; return new PDO($dsn, $username, $password, $options); } function fetch_array() { $pdo = get_pdo(); $statement = 'select * from
MySQL または MariaDB で2つのデータベースの定義がどう異なるのか、調べたいことってありますよね? mysqldump を使って diff で差分を取得することをまず考えるかもしれませんが、もしその差分をなくす、つまり一方に行った変更を他方に反映したい場合に、まさかそこから手動で ALTER TABLE 文を書こうなんてエンジニアはいないと思います。 そんなわけで mysqldiff コマンドの出番です。 mysqldiff コマンドについて mysqldiff は Python で実装された Oracle 公式の MySQL 向けユーティリティツール群である MySQL Utilities に含まれるツールのひとつです。2つの異なるデータベースを比較し、その差分を出力することができます。 Perl製のツール MySQL::Diff について mysqldiff で検索すると同
「ユニークキーの GROUP BY」 を 「LATERAL」 に書き換えることで、クエリを性能改善できる可能性があります。 ここでは、非常にシンプルな書き換えの例を示します。 テーブルの準備 まずは、以下のような「部署」、「書籍」、「部署ごとの書籍在庫数」を管理する3つのテーブルを準備します。 なお、「書籍」テーブルは、データベースの状況をイメージしやすいように用意しているだけで、以降のクエリ書き換えでは特に使いません。 -- 部署のIDと名前を管理するテーブル department を作成 CREATE TABLE department (dept_id INTEGER PRIMARY KEY, name TEXT); -- 部署の情報を5件登録 COPY department (dept_id, name) FROM stdin; 1 総務部 2 開発部 3 財務部 4 企画部 5 購
環境 Go :go version go1.6.2 darwin/amd64 IDE :VSCode1.1.0 echo:Echo v2.(beta) MySQL: Ver 14.14 Distrib 5.7.12, for osx10.11 (x86_64) OS:Max OSX El Capitan 俺 :Go初めて3日目 MySQLはHomebrewで入れました。 トランザクションとは トランザクションとは、連続する複数のデータ操作のまとまりのこと 特徴として: ユーザはトランザクション単位(複数のデータ操作)での取り消しと確定ができます(トランザクション処理) 複数のデータ操作が連なっている時、「複数の更新処理を連続して行う際に、すべての処理が成功したときにのみデータベースへの変更を有効としなければならないデータ操作」では、このトランザクション処理は必須です。 ただのロックとは違い
この記事を見て、結果に疑問を持ったので、AuroraとRDS MySQL 5.7のベンチマークを取ってみました。 動作環境 サーバ Aurora 5.6.10a / db.r3.large / SingleAZ MySQL 5.7.10 / db.r3.large / SingleAZ io1 / 100GB / 1000iops 設定はそれぞれ以下を変更 sync_binlog = 0 innodb_flush_log_at_trx_commit = 2 クライアント 4.1.17-22.30.amzn1.x86_64 / c4.2xlarge sysbench 0.4.12 サーバとクライアントはすべて同じAZ 並列数を高くできるように以下の値を増やした max_connections max_prepared_stmt_count nofile テストスクリプト --oltp-tab
CodeIgniterをバージョンアップしたところ、思わぬ形でPHPのバグを踏んでしまいました。 MySQLのバッファモード トラブルに見舞われるまで知らなかったのですが、PHPからMySQLを使う場合には、「バッファモード」と「非バッファモード」があります(リファレンス)。 バッファモード…SQLを発行すると、自動的にPHP側へ全データを取ってくる。デフォルト設定。 非バッファモード…SQLを発行した段階ではまだデータを取ってこない。 一見すると、非バッファモードのほうが便利そうに見えるのですが、1つ大きな問題があります。非バッファモードの場合、一度投げたクエリを始末し切るまで次のクエリが投げられないのです。もちろん、それを意識した上でPDOなりMySQLiなりを直接叩くのであればまだ使いでもあるのですが、(非バッファモードに対応しない)フレームワーク経由でDB接続するとなると、どこでク
先日 Lambda の VPC サポート実装がアナウンスされてたので試してみました。 VPC サポートの実装により、Lambda と RDS, ElasticCache などを連携させられるようになりました。 使ってみた所感としては、今まで用途が限定されていた気がする Lambda の使いどころがかなり広がったんじゃないかと思います。 小規模な案件なら本当にサーバいらなくなるんじゃないでしょうか。 諸々インストール フレームワークは jaws の後継 serverless を使います。 動作には node V4 が必要です。 作業は適当に立ち上げた EC2 インスタンス上で行いました。 $ git clone git://github.com/creationix/nvm.git ~/.nvm $ source ~/.nvm/nvm.sh $ nvm ls-remote # 最新のバージョ
CREATE TABLE reports ( id bigserial NOT NULL, user_id bigint NOT NULL, time_of_report timestamp without time zone NOT NULL, previous_report_id bigint REFERENCES reports (id), elapsed_time integer NOT NULL DEFAULT 0, CONSTRAINT reports_id_pkey PRIMARY KEY(id), CONSTRAINT reports_user_id_fkey FOREIGN KEY(user_id) REFERENCES users(id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE ); CREATE INDEX
SELECT COUNT(*) INTO before_count FROM table1; ... INSERT INTO table1 ...; ... SELECT COUNT(*) - brefore_count INTO registered_count FROM table1; なにかTABLEへの追加処理をしてますが、意図通りにできたかどうか、前後で COUNT(*)をとって、その差分を報告させようとしています。 複数のプロジェクトの複数のオーナーのコードで見かけたので、こんな初級アンチパターンも共有しときます。 なにがまずいの? COUNTは、シーケンシャル・スキャンしないと出てこない値なのです。アンチパターンでは、テーブル全体が対象ですから、主キーインデクスを総なめです。小さいテーブルのうちはいいのですが、運用の1000万行を越えるような巨大テーブルだと、主キーインデック
Wantedlyは今までRDSを初期設定のまま使っていました。ごめんなさい。 今回ちゃんとチューニングしてみたのでやってみた過程と結果を書きます。 ちなみにWantedlyはDBを幾つか持っていて、その中のDBの一つの最適化結果です。 NewRelic での測定の結果、平均31ms ぐらいかかっていたのが、 平均23ms ぐらいになっているので25%ぐらいの改善になりました。 インスタンスタイプ 使っているDBのインスタンスタイプです モデル: r3.4xlarge vCPU: 16 メモリ: 122GB SSDストレージ: 1 x 320G デフォルト値 RDSはパラメータグループを調節します。 それぞれのデフォルト値は書かれてないですが、以下のSQL出だすことができます。 => SELECT name,setting,unit FROM pg_settings; name | sett
概要 このへんの本を読んで復習がてらに書いてく 計算式 (物理RAMの合計) ― {max_connections x (スレッドバッファによる消費) + グローバルバッファによる消費} > 0 グローバルバッファ + スレッドバッファで消費されるであろうメモリサイズが物理メモリサイズを超えないようにする 物理RAM:r3.2xlargeで61GB グローバルバッファ(サーバ全体に設定されるオプション) すべての接続とクエリに影響する mysqldが獲得できるRAMの量を計算し、バッファサイズの合計がこれを超えないようにする オプション query_cache_size innodb_additional_mem_pool_size innodb_buffer_pool_size innodb_log_buffer_size key_buffer_size 消費メモリ計算式(GB表示) S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く