参考： https://time.geekbang.org/column/article/113440
1.遅いクエリの失敗につながるないインデックスを、
ほとんどの場合、クエリなどの非インデックス列へのデータのテーブルで数千万、非常に時間のかかるクエリの場合、このようなクエリは間違いなく遅いSQLクエリです。データクエリ、大量の、クエリを最適化するための適切な指標を確立する必要性のためにそう。
多くの時間は、インデックスを確立しますが、特定のシナリオでは、インデックスがまだ失敗する場合がありますので、インデックスが遅いクエリが失敗の主な原因の一つではあるが。
2.ロック待機
のみテーブルロックをサポートして一般的に使用されるストレージエンジンInnoDBテーブルとMyISAMの、かつてのサポートラインロックとテーブルロックがあります。
オーダーテーブル場合は、データベースがアップデートするとき、あなたは、テーブル全体をロックする必要があり、想像の下で実施し、動作テーブルロックに基づいてされている場合、（クエリを含む）他のデータベース操作の多くは深刻なシステムに影響を与える可能性があり、待機状態になります同時パフォーマンス。
このとき、InnoDBストレージエンジンは、行ロックが高い並行性のシナリオに適してサポート。しかし、InnoDBストレージエンジンを使用した場合、可能なロックテーブルに行ロックのエスカレーションに特別な注意を払います。場合バッチ更新操作、行ロックは、おそらくテーブルロックにエスカレートであろう。
多数の行は、MySQLは、テーブルのロックを信じている場合は、他のトランザクションが長いロックを待機させると、MySQLが行ロックにアップグレードされますので、より多くのロックの競合は、パフォーマンスに重大な減少が生じ、発生した可能性がある、取引の効率の低下につながるだろうテーブルロック。また、更新操作時に、条件インデックスが失敗した場合、行ロックは、インデックスプラスロックに基づいて、行ロックがテーブルロックにエスカレートします。
そのため、手術台のデータベースロックに基づいて、このように実行速度に影響を与える、SQLブロック待ちを引き起こします。更新操作（挿入\更新\削除）よりも大きいか、または読み出し動作に等しい数の場合には、MySQLのMyISAMストレージエンジンは推奨されません。
ロックのエスカレーション、相対的に言ってロックテーブルの行ロックに加えて、より細かい粒度が、同時容量を向上させるだけでなく、新たな問題をもたらし、それがデッドロックされています。したがって、行ロックを使用する場合には、デッドロックを回避します。
3.不適切なSQL文
不適切な使用のSQLステートメントのSQLは、最も一般的な原因の遅いです。例えば、慣用<SELECT *>、<SELECT COUNT（*）> SQL文、などをソートするために大規模なデータ<LIMIT M、N>ページングクエリ、ならびに非索引フィールドで使用されるテーブルを使用。