3

WHERE 句と ORDER BY 句ですべて使用できる 129 個のフィールドを持つテーブルを持つマルチテナント アプリケーションがあります。最適なインデックス作成戦略を見つけるために 5 日間を費やしました。多くの知識を得ることができましたが、まだいくつか質問があります。

1) インデックスを作成するときは、常に最初に tenant_id を持つ複合インデックスにする必要がありますか?(すべてのクエリには、WHERE 句に tenant_id = ? があります)

2) WHERE 句と order by 句の両方ですべての列を使用できるため、すべての列にインデックスを作成する必要がありますか? （インデックスのない列で注文すると、約1,500,000行のテナントで実行するのに6秒かかることを知っています）

3) PK (tenant_id, ID) を作成しますが、これはそのテーブルへの結合に影響しませんか?

これを処理する方法についてのアドバイスは大歓迎です。

====== データベースエンジンは InnoDB

=======

構造 ：

ID bigint(20) auto_increment primary
tenant_id int(11)
created_by int(11)
created_on Timestamp
updated_by int(11)
updated_on Timestamp
owner_id int(11)
first_name VARCHAR(60)
last_name VARCHAR(60)
.
.
.
(some 120 other columns that are all searchable)
4

1 に答える 1

5

質問に対するいくつかの簡単な回答。私が見る限り、あなたは使用に混乱していますindexes

比率が -

Consideration 1-

(列の一意のエントリ数)/(列の合計エントリ数) ~= 1

つまり、特定の列の DISTINCT 行の数が多いです。

エクストラ を作成すると、index常に MySQL サーバーのオーバーヘッドが発生するため、すべての列を作成してはなりませんindex. 1 つのテーブルが持つことができるインデックスの数にも制限があります = テーブルごとに 64


あなたがすべての検索クエリに存在する場合は、それをまたは であるtenant_idと見なす必要があります。indexcomposite key

ただし、

Consideration 2- の数は の数よりUPDATEs少ないSELECTstenant_id


Consideration 3-indexeは、 に関してできるだけ小さくする必要がありdata typesます。インデックスを作成してはいけませんhttp://www.mysqlperformanceblog.com/2012/08/16/mysql-indexing-best-practices-webinar-questions-followup/varchar 64


Point to Note 1- 任意の列をインデックスとして宣言しても、MySQL オプティマイザーはそれをクエリ実行の最適なプランとは見なさない場合があります。そのため、常にEXPLAIN何が起こっているかを知るために使用してください。http://www.mysqlperformanceblog.com/2009/09/12/3-ways-mysql-uses-indexes/


Point to Note 2- クエリを検索したい場合があるcacheため、次のような予期しないステートメントをSELECTクエリで使用しないように注意してください。NOW()

最後に、PK (tenant_id、ID) を作成しても、テーブルの結合には影響しません。
そして、一般的なすべての質問に答える素晴らしいリンク - http://www.percona.com/files/presentations/WEBINAR-MySQL-Indexing-Best-Practices.pdf

于 2012-12-30T04:56:48.800 に答える