私のmysqlデータベースが増えるにつれ、私のオプションは何ですか

Question

どうすればこのクエリを改善できますか？ DBだけ大きくなっている

自分のソーシャルネットワークとしてここに私のすべての私のオプションを教えてください。このクエリは、この表は百万と言うか、更には2万行あるとき私のオプションどのようなものがあり

SELECT friend_friend.friendid, friend_reg_user.disp_name, friend_reg_user.pic_url, friend_reg_user.online 
FROM friend_friend 
INNER JOIN friend_reg_user ON friend_friend.friendid = friend_reg_user.auto_id 
WHERE userid =1 
AND friend_friend.status =1 
ORDER BY autoid DESC 
LIMIT 59535 , 15 


##################################################################################################################################### 
# id # select_type # table   # type # possible_keys # key  # key_len # ref      # rows # Extra  # 
##################################################################################################################################### 
# 1 # SIMPLE  # friend_friend # ref  # userid  # userid # 5  # const     # 59843 # Using where# 
# 1 # SIMPLE  # friend_reg_user # eq_ref # PRIMARY  # PRIMARY # 4  # friend_friend.friendid # 1  #   # 
##################################################################################################################################### 

2.1231秒かかりました大きい？このテーブルは、ユーザーが誰であるかを判断するために使用されます

Answer 1

私は自分のデータベースで800万レコードを処理しているプログラマーを知っています。適切なインデックスを作成し、効率的な方法でデータを取得していることを確認するだけです。 （関係の数値IDは本当に便利です）

また、ほとんどの場合、あなたのクエリは本当にベアボーンです。あまりにも派手ではない。サーバーの待ち時間になるかもしれません。

Answer 2

あなたのスキーマは本当にわかりませんが、本当にLEFT JOINが必要ですか？ INNER JOINを使用できませんか？

（私はしばしば、パフォーマンスが良いかもしれないと聞きましたが、それは少ない行しか返しません;あなたの場合は、1人の男の子が欲しい場合は、左の参加者のポイントが表示されません。いいえ、「リンク」、そして、そう、「リンク」テーブルのエントリを持っている）

は

また、あなたが使用するフィールドのインデックスを持っていることを確認してください。？

• 条件に（どちらか「どこで」または "参加する"）。ここでOKのようですか？
• ソート用。自己はインデックスを持っていますか？

MySQLはいくつかのアプリケーションでは本当に大きなテーブルで使用されており、インデックス/設定が正常であれば本当に高速に回答できます。だから、私たちがここでできるはずのものがあります;-)

脇役として：あなたはテーブルの名前の前に接頭辞を付けています（フィールドの名前に重複があるためです） ;どうしてあなたはいつもそうですか？クエリをちょっと分かりやすくします;-)

Answer 3

WHERE句の列がインデックスである限り、大丈夫です。私は大量のテストデータを生成し、いくつかのベンチマークを実行します。

さらに重要なことは、MySQL's EXPLAINの構文に身を任せていることです。これは、実際にクエリで使用されている行の数を判断するのに役立ちます（クエリとテーブルインデックスを最適化するための素晴らしいツールです）。

Answer 4

あなたは何が遅くなっているのかを知るべきです。

データベースはメモリに収まりますか？もしそうでなければ、もっと - いいえ、本当に。あなたがそれを見ても、ディスクは遅いです。

あなたの質問が絶対にディスクを使用しなければならない場合（あなたのデータベースは妥当なメモリであるとは言えないが、100G +と言っても過言ではない）、必要なIO操作の数を最小限に抑える必要があります。

実際には、これはある程度の非正規化を意味します（本当に結合が必要ですか？xrefテーブルに必要なすべてのフィールドを（コピーして）保存することはできませんか？）、カバーするインデックスを賢明に使用できますか？

InnoDB（ここではInnodbを使用していると仮定します）では、主キーがクラスタリングされています。これは、プライマリキーを使用するクエリでは、インデックスが同じページにデータとともに格納されるため、他のインデックスよりIOが少なくなることを意味します。なぜなら、各行に対して個別にIOを実行する必要がないからです。セカンダリインデックスで必要です。

基本的な原理は次のとおりです。

1. 生産スペックのハードウェア上のデータの生産レベルを使用して問題を再現非本番環境で
2. それ
3. がどのように変更します原因となっている診断
4. 修正プログラムのパフォーマンスを検証するために、同じプロダクション仕様の非プロダクション環境を使用して、再度測定してください。あなたが問題を解決するために十分な性能を持ってまで、
5. 繰り返し

、成功した場合、あなたはどのような通常のQA手続きを行うことができます（たとえば、回帰テストなど）（あなたの顧客をなどなだめるために）解放することです変化。

場合によっては、大規模なデータ移行が必要になるため、展開するには大きな頭痛になります（10Tbのデータテーブルのスキーマを変更する必要があるとします）。