タグ

インデックスに関するmytechnoteのブックマーク (6)

  • MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ

    こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、

    MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
  • Git入門 - Gitの仕組みを速攻で理解する

    Gitの場合も基的な運用では任意の場所にGitサーバを立てます。そして各自のローカルのTortoiseGitやEclipse,ターミナルなどで接続します。 ここまではSVNと一緒なのですが、gitの場合はここで各自のローカルにもリポジトリができあがります。当然、作業フォルダ(ワーキングツリー)も存在します。 ここでSVNユーザの方は「は?なにいってんの?」ってなると思います。たぶん。 ですが、このローカルリポジトリがなかなか便利なんです。 ここではまず、「gitにはリモートリポジトリ・ローカルリポジトリ・作業フォルダ(ワーキングツリー)」という3つの状態があることを覚えておいてください。 覚えておくべきGit用語まず最初にSVN脳からGit脳に切り替えていきます。 同じ用語が出てきますが、意味が変わってくるのでまずSVNと比較しながらGitの用語を覚えていきましょう。 リモートリポジトリ

    Git入門 - Gitの仕組みを速攻で理解する
  • 1日に100万レコード増える場合のテーブル設計

    MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

    1日に100万レコード増える場合のテーブル設計
  • 知って得するInnoDBセカンダリインデックス活用術!

    InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が

    知って得するInnoDBセカンダリインデックス活用術!
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.1 MySQL のインデックスの使用の仕組み

    インデックスは特定のカラム値のある行をすばやく見つけるために使用されます。 インデックスがないと、MySQL は関連する行を見つけるために、先頭行から始めてテーブル全体を読み取る必要があります。 テーブルが大きいほど、このコストが大きくなります。 テーブルに問題のカラムのインデックスが含まれている場合、MySQL はすべてのデータを調べる必要なく、データファイルの途中のシークする位置をすばやく特定できます。 これはすべての行を順次読み取るよりはるかに高速です。 ほとんどの MySQL インデックス (PRIMARY KEY、UNIQUE、INDEX、および FULLTEXT) は B ツリーに格納されます。 例外: 空間データ型のインデックスは R ツリーを使用します。MEMORY テーブルはハッシュインデックスもサポートします。InnoDB は FULLTEXT インデックスの逆のリスト

  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.6 マルチカラムインデックス

    MySQL は複合インデックス (つまり、複数のカラムに対するインデックス) を作成できます。 インデックスは最大 16 カラムで構成できます。 特定のデータ型では、カラムのプリフィクスにインデックスを設定できます (セクション8.3.5「カラムインデックス」を参照してください)。 MySQL では、インデックスで、すべてのカラムをテストするクエリーまたは最初のカラム、最初の 2 つのカラム、最初の 3 つのカラムというようにテストするクエリーにマルチカラムインデックスを使用できます。 インデックス定義の正しい順序でカラムを指定する場合、単一の複合インデックスにより、同じテーブルへの複数の種類のクエリーを高速化できます。 マルチカラムインデックスは、インデックス設定されたカラムの値を連結して作成された値を格納する行である、ソート済みの配列とみなすことができます。 複合インデックスの代わりに

  • 1