mondでこの質問への回答を読んでみましょう
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ | mond
mondでこの質問への回答を読んでみましょう
MySQLでの、WHERE句のORにindexは効かないのか..?
概要 ネットでWhere句のORにindexが効くかどうか調べると、以下のような意見があって何が正解かわかりませんでした。なので、検証して真偽を確かめていこうと思います。 「OR演算子にインデックスは効かない」 「OR演算子にインデックスは効く」 「OR演算子の右辺はインデックスが効かない」 検証するDBはMySQL5.7.36です。 検証1 where句の片方の検索条件にindexがあり、もう片方の検索条件にはindexがないパターン country_id、laungage_idの２つのカラムを使います。 country_idにはindexが貼られていて、laungage_idには貼られていません。
雑なMySQLパフォーマンスチューニング
26. EXPLAIN mysql> EXPLAIN SELECT * FROM table_1 a JOIN `table_2` s ON a.user_id=s.`user_id` AND s.site_i d=120 WHERE app_id=8250G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: a type: ref possible_keys: PRIMARY,ix_table_1,ix2_table_2,ix3_table_1,idx_table_1_06,idx_table_1_07,idx_t able_1_09 key: idx_table_1_06 key_len: 4 ref: const rows: 13496 Ext
MySQL5.5から5.6にしたらICP(Index Condition Pushdown)で困った - Qiita
はじめに ついにAdventCalenderも２日ですね。 MySQL Casual Advent Calendar24日目の担当の@gotyooooです。 昨日は@kuwa_twさんのシェルスクリプトだけでMySQLからMongoDBへの移行しちゃうでした。 Mongoのメモリ食いまくりな仕様が気になってます・・・。RDBさいこーｗ MySQL界隈ではやっぱりMariaDBはRHEL7とかで標準になったりと、熱いですよね。適当なものでまずは試してみたいです。Galera clusterってそういばどうなったんだろ・・・。 本日の内容 標題の通りです。今更ながら5.5から5.6に移行したデータベースでICPにより問題が起こってしまいました。そのことを書こうと思います。 ICP(Index Condition Pushdown)とは？ 5.6の新機能 デフォルトON 簡単に機能説明 マルチカ
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ
この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI・機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る猫 TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI・機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ
SQLのインデックスとそのチューニングについてのオンラインブック
開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQL、Oracle、SQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 DB2Use The
[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)
[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でプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
PostgreSQLの行レベルセキュリティ(RLS)が実行計画に与える影響を確認してみた | DevelopersIO
マルチテナントなECサイトの注文データをイメージしています。tenant_nameのカラムにテナント名が入り、このカラムとDBユーザーの一致を行セキュリティポリシーよってチェックするようなイメージです。 テストデータ等の準備 それでは検証環境を準備していきましょう。今回の検証にはPostgreSQLバージョン11.11を利用しています。 まずはテーブルを作成 CREATE TABLE orders ( id SERIAL PRIMARY KEY, tenant_name text, product_code text, order_date timestamp ); CREATE TABLE 続いてマルチテナント用のDBユーザーを作成 CREATE ROLE user01 LOGIN; CREATE ROLE CREATE SCHEMA "saas"; CREATE SCHEMA GRAN
雑なクエリやインデックスは意味がない 原理を理解してB−Treeインデックスを正しく利用する
2013年から始まったJuly Tech Festaは、ITエンジニアに情報交換と人脈構築の場を提供するとともに、ITに係るエンジニアの知的興味を満足させるための祭典です。セッション内容はIoT、AI、機械学習、クラウド最新事情、コンテナ技術、DevOpsなど多岐に渡ります。橋本氏は、データベースにおけるインデックスについて発表をしました。 自分自身が「今さら聞けない」と思っているインデックスについて発表 橋本拓弥氏：では私、橋本から「結局インデックスってなんなんですか？」というお話をしようと思います。お願いします。 簡単に自己紹介だけさせてください。橋本と申します。株式会社サーバーワークスという、AWSのインテグレーションをやっているSI企業に所属してます。ロールは今Corporate Engineerです。 ふだんの業務ではこんな感じのことを触っています。業務フローとか、コーポレート的
新人研修でマスターするDBのパフォーマンスチューニング - GMOインターネットグループ グループ研究開発本部
D. M. です。今回は新人研修で扱う DB のパフォーマンスチューニングについてのお話です。 この記事を書こうと思ったキッカケ 私はここ数年新人やインターンの学生のメンターをよく担当しているのですが、学生と会社員エンジニアの間にはデータベース（ RDB ）の知見に大きな溝があると感じています。 研修で「とりあえずサービスを作ってみよう！」という課題を出すと、最近の新卒の方は平均的なレベルが高く、いいアイディアでさらっと Web サイトを立ち上げることができます。 ただそのサイトが毎日 100 万人が使うことを想定して充分なチューニングができる人は新人段階ではほんのわずかです。毎回同じようなことを指摘するのですが、特に多いのが DB 関連です。多くの方が DB の経験がほとんどなくあまり扱えないのです。コンピュータサイエンス専攻出身の方はプログラミングスキルをはじめとした技術的な知見を持っ
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
パーティショニング : 使い方 | Let's POSTGRES
1. UPDATE, DELETE へのルールの定義 8.1 以前では UPDATE, DELETE に対して『ルール (RULE)』の定義が必要です。古いバージョンでは検索条件による自動的な絞込みが行われないため、検索を効率化するためにルールを用いて不要なパーティションを除外してやる必要があるのです。 この作業には手間がかかると思いますので、作業が自動化された 8.2 以降を使うことをお勧めします。 2. constraint_exclusion による SELECT, UPDATE, DELETE の自動化 設定パラメータ constraint_exclusion が追加され、SELECT は 8.1 以降で、UPDATE, DELETE は 8.2 以降で、絞込みが自動的に行われるようになりました。constraint_exclusion = on を設定します。ただし、デフォルトの
オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
運用で役立つツールpg_repackのご紹介 - Qiita
この記事は PostgreSQL Advent Calendar 2015 - Qiita の9日目です。 8日目は osapon さんに書いていただきました。 この記事では、PostgreSQLを運用する上で役立つかもしれないツールの一つ pg_repack を紹介したいと思います。 pg_repackとは pg_repack はPostgreSQLの拡張ツール（エクステンション）の一つで、肥大化したテーブルやインデックスを再編成し、さらに指定したインデックスにしたがってレコードを並び替えることができます。 PostgreSQLの CLUSTER や VACUUM FULL コマンドと違って、pg_repackは処理の間対象テーブルへの排他ロックを保持し続けないため、オンライン中に動作させることができます。 どういうことなのか、説明していきますね。 テーブルやインデックスの肥大化 Pos
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
