サブライブラリーサブテーブルの問題をインデックス化した後、

概要

最近、私は、遅いSQLに遭遇したライブラリのインデックス集合とサブサブテーブルのリレーションシップの後、調査の過程で見つかった、次の質問をまとめました。

問題

在庫の健康のアプリケーションの間に、我々は遅いSQLが見つかった
以下の

select brandgoodid from brandgood_0020
where  userid = xxx AND
brandgoodid  in("xxx1","xxx2")

テーブル構造、ユーザーIDに応じて、サブテーブル。

CREATE TABLE`brandgood_0020` (
  `brandgoodid` char(30) NOT NULL COMMENT ,
  `user_id` int(10) unsigned DEFAULT NULL COMMENT '用户id',
  `created` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  `last_modified` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `deleted` bit(1) NOT NULL DEFAULT b'0',
  PRIMARY KEY (`brandgoodid`),
  KEY `idx_userid` (`userid`) USING BTREE,
) ENGINE=InnoDB DEFAULT CHARSET=utf8

explainあなたが、フィルタbrandgoodid値にインデックスキーの多くをスキャンしたいので、ここでは、ユーザは、商品がたくさんある、とbrandgoodidの多くを持つことになりますので、非常に遅いがあるかもしれない、インデックスで見つかったユーザーIDを取っています。
人々が行くことを期待し、むしろ「ユーザID」のインデックスよりも、SQLを記述するための主キーのインデックス。主キーのインデックスと、主キー走査をN回（Nは、での数を示す）であるからです。

分析

直接明白な理由

このMySQLのクエリでオプティマイザが誤解され、間違ったインデックス
クエリでは、多くの場合、MySQLサーバの判断に影響を与えます。主な違いは、それほど頻繁に矛盾したインデックスの選択を表示され、走査線の異なる数に影響しますした値の数です。また、まとめの前にSQLのINを必ずしもインデックスそれを取ります

解きます

brandgoodlidユーザクエリが特定の寸法のグループで定義されているため、brandgood対応するグループは、典型的には10未満、このビジネスで、制限されています。だから、主キーインデックス、高効率化を使用して、この場所。このソリューションは、必要とされるところであり、force indexPRIMARYインデックスを離れて強制的に。

スプレッド

サブライブラリーサブテーブルインデックスの後

題しなぜサブライブラリーのサブテーブル、直接およびサブライブラリーサブテーブルの発行後インデックスがああ問題ではありませんか？
トラブルシューティングを行うときなので、ミスを犯しました。その後特定のbrandgood_0020テーブルへのルート、プライマリ・キー・インデックスを照会するために直接brandgoodidの方法。いくつかは信じているし、分散データベース（カサンドラ）は、そのようなクラスタ化キー+パーティションキーインデックスデータです。キーは、データを分割するノードクラスタをブロックし、ローカルインデックスに従って対応するデータを見つけることができます。

しかし、実際にはMySQLのサブライブラリーのサブテーブルは、キーのサブテーブルがインデックス化されていない、同じではありませんが、クライアントのルート。対応するテーブルを見つけるためにのみ責任を負います。表の後に単一テーブルのクエリおよびロジックと同じです。

キーサブテーブルがインデックスが、クエリは、キーポイントテーブルをとる必要があるされていないのでことを意味共同インデックスに大部分に組み込まれたインデックステーブルの私たちのサブライブラリーのサブテーブルの後にサブインデックステーブルキー+キー。

それ以外の場合は、テーブルから、当社の問合せ選択xxのパーティションテーブルのキー= XXXであり、A = xxxは、関節のインデックスを歩くことができませんでした。あなただけの単一のインデックスを取ることができます。問題のインデックス選択に直面する単一のインデックスMySQLサーバ。

もちろん、それは私が引用したように上記の場合のように、絶対的なものではありません。他のポイントテーブルインデックスを見て、この考え方によります。案の定、テーブル上のインデックスのほとんどは非接合インデックスされている、または単一コピーのテーブルインデックスから直接来ます。これらのインデックスは、すべてそのユーザーIDのインデックスので、基本的には役に立ちません。

インデックスの選択問題

MySQLのそれは間違っているインデックス、を詳しく見てだろう、なぜ10 | MySQLの理由は時々間違ったインデックスを選ぶだろう

当社は、理由のスキャンラインの問題の数のこのケースを判断します。