mysql count クエリが非常に遅い場合はどうすればよいですか? mysqlクエリ速度最適化ソリューション

MySQL のクエリ速度が遅すぎるため、著者は時間をかけて mysql クエリ速度の最適化計画を整理しました。質問や間違いがありましたら、遠慮なく連絡して修正してください。一緒に学び、進歩しましょう。

大きなテーブルの MySQL count() 最適化

推奨される関連する mysql ビデオ チュートリアル: "mysql チュートリアル"

この記事を書くことは、皆さんの疑問を解消し、本題に戻るのにも役立ちます。 B+ ツリーと組み合わせたデータ 実験結果の推測に基づく構造と判断

今日は、MySQL の count() 操作の最適化を実験しました。以下の説明は、mysql5.7 InnoDB Windows オペレーティング システムに基づいています。

作成したテーブルの構造は以下の通りです(データ量は100万)

まず、mysqlのcount(*)、count(PK)、count(1)のどれなのかが問題です。 ) の方が速いです。
実装結果は以下の通りです:



違いはありません! WHERE 句を追加すると、3 つのクエリにかかる時間が同じになるため、写真は掲載しません。

以前、会社にいた頃、SQL 文 select count(*) from table を書いたのですが、データが多いと非常に遅かったです。では、どのように最適化すればよいのでしょうか? select count(*) from table的SQL语句，在数据多的时候非常慢。所以要怎么优化呢？

这要从InnoDB的索引说起, InnoDB的索引是B+Tree。

对主键索引来说：它只有在叶子节点上存储数据，它的key是主键，并且value为整条数据。 
对辅助索引来说：key为建索引的列，value为主键。

这给我们两个信息： 
1. 根据主键会查到整条数据 
2. 根据辅助索引只能查到主键，然后必须通过主键再查到剩余信息。

所以如果要优化count(*)操作的话，我们需要找一个短小的列，为它建立辅助索引。 
在我的例子中就是status，虽然它的”severelity”几乎为0.

先建立索引：ALTER TABLE test1 ADD INDEX (status); 
然后查询，如下图： 
 
可以看到，查询时间从3.35s下降到了0.26s，查询速度提升近13倍。

如果索引是str这一列，结果又会是怎么样呢？ 
先建立索引: alter table test1 add index (str) 
结果如下： 

可以看到，时间为0.422s，也很快，但是比起status这列还是有着1.5倍左右的差距。

再大胆一点做个实验，我把status这列的索引删掉，建立一个status和left(omdb,200)(这一列平均1000个字符)的联合索引，然后看查询时间。 
建立索引： alter table test1 add index (status,omdb(200)) 
结果如下： 
 
时间为1.172s 
alter table test1 add index (status

これは InnoDB のインデックスから始まります。 InnoDB のインデックスは B+Tree です。

主キーインデックスの場合: データはリーフノードにのみ保存され、 そのキーは主キーで値はデータ全体です。
補助インデックスの場合: key はインデックス付けされる列、value は主キーです。
これにより、次の 2 つの情報が得られます:

1. データ全体は主キーに基づいて検索されます。

2. 主キーのみが補助インデックスに基づいて検索され、残りの情報は主キー。
そのため、 count(*) 操作を最適化したい場合は、短い列を見つけて、そのための補助インデックスを作成する必要があります。

私の場合、それは status ですが、その「重大度」はほぼ 0 です。

最初にインデックスを作成します。 ALTER TABLE test1 ADD INDEX (status) ;

次に、以下に示すようにクエリを実行します。

クエリ時間が 3.35 秒から 0.26 秒に短縮され、 クエリ速度が約 13 倍増加していることがわかります。

インデックスが str 列の場合、結果はどうなりますか? 最初にインデックスを作成します: alter table test1 addindex (str) 結果は次のとおりです:

時間は 0.422 秒で、これも非常に速いことがわかりますが、 と比較するとstatus 欄はそのままです 1.5倍ほどの差があります。

もっと大胆に実験してみるために、status 列のインデックスを削除し、status と left(omdb,200) を作成しました。 > (この列には平均 1000 文字があります) ジョイント インデックスを作成し、クエリ時間を調べます。

インデックスの作成: alter table test1 addindex (status,omdb(200))

結果は次のとおりです: 🎜 🎜時間は 1.172 秒 🎜alter table test1 addindex (status code>,imdbid);🎜🎜補足! ！ 🎜インデックスの失敗に注意してください! 🎜インデックスを確立した後の通常の外観: 🎜🎜 key_len が 6 で、追加の説明がインデックスを使用していることがわかります。🎜🎜 そして、インデックスが失敗した場合: 🎜🎜🎜🎜 インデックスが失敗する状況は数多くあります。関数の使用、! = 操作など。詳しくは公式ドキュメントを参照してください。 🎜🎜上記は、B+ ツリーのデータ構造と実験結果に基づいた私の判断に基づいています。不足がある場合は、修正してください。 🎜🎜関連記事: 🎜🎜🎜SQL Server2005 クエリ速度を最適化する 50 の方法のまとめ🎜🎜🎜🎜 クエリ速度の向上: SQL Server データベース最適化計画🎜🎜🎜 🎜

以上がmysql count クエリが非常に遅い場合はどうすればよいですか? mysqlクエリ速度最適化ソリューションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。