実行計画の話第14回 中国地方DB勉強会 in 福山の登壇資料です。 https://dbstudychugoku.github.io/events/event-014.html 合わせてこちらのYouTube動画を見ることをオススメします。 PGCon 2014 Tokyo【D3】PostgreSQ…
「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターン
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
[SQL]JOINの3種類のアルゴリズムについて
SQLのJOINには3種類のアルゴリズムあるということを最近知ったのでまとめてみる。 JOINのアルゴリズム Nested Loop Sort/Merge Hash 基本知識 DBMSごとの実装状況 Oracle 3種類全部 MySQL Nested Loopのみ PostgreSQL 3種類全部 外部表(駆動表)と内部表 外部表(駆動表) JOINするときのベースになる表。以下のSQLでいえば、table1 内部表 外部表にくっつける表。以下のSQLでいえば、table2 特徴 Nested Loop Join 外部表にある全行に対して、内部表から結合キー列の値がマッチするものを探して結合する 上記に関連して、外部表にあるレコードが少ないほうがループ数を少なくできるため高速にできる 内部表の結合キー列にインデックスがある場合、インデックスを用いて検索できるため高速に処理できる Sort
![[SQL]JOINの3種類のアルゴリズムについて](https://cdn-ak-scissors.b.st-hatena.com/image/square/584c3d5d6610b3cf7bb2d1c5109eb598fde56373/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--lpDahPPq--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BSQL%25255DJOIN%2525E3%252581%2525AE3%2525E7%2525A8%2525AE%2525E9%2525A1%25259E%2525E3%252581%2525AE%2525E3%252582%2525A2%2525E3%252583%2525AB%2525E3%252582%2525B4%2525E3%252583%2525AA%2525E3%252582%2525BA%2525E3%252583%2525A0%2525E3%252581%2525AB%2525E3%252581%2525A4%2525E3%252581%252584%2525E3%252581%2525A6%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3A%2525E3%252581%2525B6%2525E3%252582%25258B%2525E3%252583%2525BC%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2ExYjQxNmE0NzYuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか（1） | gihyo.jp
はじめに 結果として、SQLのような関係型の言語は非手続き型の言語と呼ばれるが、これはユーザは「いかに」ではなく「何を」を指定する―つまり、獲得するための手続きを指定することなしにユーザは何が欲しいかをいう―からである。 ── Christpher J. Date[1] Webの入力フォームであれ、コマンドラインツールであれ、インタフェースにかかわらず、リレーショナルデータベースに対する操作はSQLという専用の言語で行われます。ユーザ（プログラマ含む）が意識的にコーディングするのは通常このSQLレベルまでで、あとはDBMSが処理を終え、結果を返却するのを待つのみです。SQLとRDBMSにおいては、ユーザはデータのありかを知る必要もなければ、そこへのアクセス方法も考えません。そういう仕事は、全部DBMSに任せています。 このプロセスは、通常「プログラミング」と呼ばれるものとはかなり異なりま
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
今すぐ ALB のアクセスログをクエリする - クックパッド開発者ブログ
クックパッドマートでサーバーサイドなどのソフトウェアエンジニアをしている石川です。 この記事では、クックパッドマートとは全然関係なく、私が正社員として新卒入社する前、2020 年初頭に技術部 SRE グループで就業型インターンをしていた際に実装したシステムについてご紹介します。 ALB のアクセスログ 弊社では AWS の Elastic Load Balancing (ELB) を多用しており、Application Load Balancer (ALB) が多くのウェブアプリケーションで利用されています。 ところで ALB はアクセスログを Amazon S3 に保存することができます。このアクセスログにはアクセス先の IP アドレスやリクエスト URL の他、レスポンスのステータスコード、レスポンスまでにかかった時間、User-Agent などの情報が記録されています。 これらの情報
ActiveRecordのcountとlengthとsize - メグリ株式会社
lengthの場合、SQLの実行結果の行数をカウントするため、COUNTを使ってカウントするcountやsizeの方が処理は軽くなります。 しかし、countはキャッシュを使わないため、毎回COUNTのSQLを実行してしまいます。 行数のカウントだけであれば、キャッシュの有無で判断してくれるsizeを使ったほうが良さそうです。 ちなみに今のRailsはSQLを遅延実行するようになっているので、たとえば以下の様なSQLが2回発行されるようなコードでも、 pry(main)> clients = Client.all Client Load (0.3ms) SELECT `clients`.* FROM `clients` pry(main)> clients.count (0.3ms) SELECT COUNT(*) FROM `clients` => 5 メソッドチェイン
『JOIN』と『SELECT列のサブクエリー』の性能検証
「JOIN」と「SELECT列のサブクエリー」は、他のテーブル情報をキーを使って取得するという点においての効用としては似ています。 私の場合は、JOINで取れるものは、サブクエリーは基本使いませんが、その理由は「可読性」もありますが「性能的」にもサブクエリーは劣っているという印象もあります。 しかし、昨今のオプティマイザや処理の最適化が行われている、RDBではどのような結果になるのか気になったので、単純なサンプルを使って代表的なデータベースそれぞれの性能的な違いを検証してみました。 （PC環境やデータベースのバージョンやドライバやデータ件数、使用ツールの違いで結果が異なる場合があるので、あくまで参考として頂ければと思います。） 検証用テーブル ※リレーションは、[M_PRODUCT.PRODUCT_ID] 1 – 0..N [T_ORDER.PRODUCT_ID]
SQLでサブクエリを上手に使う6パターン
はじめまして。Souki.Tです。 SQLを書く上で、使いどころが難しいのがサブクエリです。何でもかんでもJOINして運用するのは格好わるい、サブクエリを使ったら何かカッコいい、結局サブクエリを使いすぎて訳の分からなくなり、作った自分でも手が出せなくなった経験は私だけではないはずです。今回はサブクエリを使う場面をパターンに分けて上手なつき合い方を考えてみたいと思います。 サブクエリとは何かということを説明するのは私には手に余るので誰か説明の上手な人に任せます。どこかにいい解説があったら教えてください。 サブクエリを使わない理由サブクエリの特徴を一言でいうと「重い」。ともかく重い。使い方を間違えたら劇的に重くなることはもちろんのこと、適切に使ったとしても重いものは重いです。普通にJOINで結合して解決するのであれば、使うべきではありません。 それでもサブクエリを使うパターンとはいえ、サブクエ
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
MySQLでインデックスを使って高速化するならCovering Indexが使えそう - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者：松信 嘉範 販売元：翔泳社 発売日：2009-09-17 おすすめ度： クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho
ずっと前から積ん読状態だった「SQLアンチパターン」を読みました。 何年積んでたか分からないSQLアンチパターン読み終わったー。噂に違わずいい本ですねー。もっと早く読むべきだった。— @ketancho (@ketancho) 2018年3月6日 噂通りとても良い本で、まさに「エンジニアとしての血肉本」と言えます。1, 2年目の頃に読んでおくべきだったなーと少し後悔しています。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る 読んで終わりだと身につかないと思うので、自分なりのチェックポイントを言語化しておこうと思います。長くなってしまったので、章ごとに4つに分けたいと思います。この記事はその第一弾と
【保存版】Railsエンジニアとして内定後、実務で必要とされる知識をつけるために1ヶ月で必死で読んだ13冊 - 銀行員からのRailsエンジニア
はじめに こんにちは。ゆうすけです。 僕はRailsエンジニアとして内定後、勤務が始まるまでの１ヶ月で技術書１３冊（金額にして3.4万円(汗)）を読んできました。 内定先のマネージャーにおすすめされた本も多く、Railsエンジニアに転職を検討されている方、実務レベルの知識を習得したいという方の参考になればと思い、１ヶ月で読んできた本を紹介します。 無料でPDFが公開されているものもあるので、是非参考にしてみてください。 当然ですが１ヶ月で全てを理解出来た訳ではなく、今後繰り返し読んでいこうと思っているので、自分の現状の備忘も含めて書きました。 はじめに 読んだ本 基礎知識 Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) プログラミング一般 プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 オブジェ
ディレクターがSQLを使えてよかった話 - クックパッド開発者ブログ
こんにちは。ディレクターの川原田です。 クックパッドでお気に入りレシピを保存する「MYフォルダ」のサービス開発や、保存・記録に関する新規サービスの検討・開発を担当しています。 ディレクターの仕事は様々ありますが、今回は私が身につけたことで仕事領域が広がった！と感じているSQLについてお話ししたいと思います。 いきなりですが、SQLが使えてよかった点をまとめると以下です。 よかったこと 数値抽出から分析まで自己完結 エンジニアとのコミュニケーションがスムーズに 仕事が増えていそうで実は効率アップ 周囲の知的好奇心を刺激 それぞれ具体例を交えてお話します。 数値抽出から分析まで自己完結 事例１：ログ構造を理解でき後の仕事がスムーズに 昨年、アプリのサービス開発を担当した際、エンジニアの設定したログが、実際に送信されるかどうかを事前チェックをしました*1。 アプリのリリースはタイミングが決められ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQL Training 2021