1.DDL（データ定義言語）の実行
オンラインサーバー、テーブルの構造を更新し、DDLを実行するには、この操作は慎重な取り扱いが必要です。
DDL、構造変化が排他的にロックされ、完全なテーブルになります。それはまだ良いInnoDBのであれば、このタイムテーブルで、メンテナンス状態、動作不能状態のため。（5.6サポートオンラインDDL効果が大幅に改善した後、大幅にロック時間を短縮）。
：DDL使用のテーブル構造を維持し、コピー戦略である
タスク：インデックスを追加し、列を追加します：
アイデア：
、新しいテーブルを作成するには、新しい構造を満たしています。
（読み出し動作）新しいテーブルのデータに古いテーブルを導入し、一つ一つを導入しました。少ない使い捨てロックされたコンテンツを保証し、テーブルの上に他のタスクを実行することができます。
インポート処理中に、新たに更新された操作履歴テーブル。ログの形式で記録を完了します。
インポートが完了したら。更新ログは、新しい表に再度やり直し。
新基準は、テーブルに古い曲を置き換えます。アプリケーションが完成し、またはデータベースの名前を変更され、ビューが完成されます。
2.データのインポート文
データを復元するとき、それは、データのインポートの多くを必要とします。これは、急速な輸入を確保するために、いくつかのスキルが必要です。
インポートすると、インポートが完了した後、インデックスと制約を無効にして、ワンタイムインデックスを作成するには、インデックスと制約を回します。
alter table table-name disable keys;
alter table table-name enable keys;
InnoDBは、トランザクションストレージエンジンについては、完了したトランザクションでは、SQLの数とすることができます。
begin;
多条导入；
commit；
InnoDBの順序は、入力データ自体が主ソートキー、比較的高速の導入率に応じて導入され、主キーです。Perpareは、インポート操作は、SQLコンパイラ同じ構造の数を減らすために実行されるプリコンパイルされたプログラムを使用してもよいです。
3.大規模なページ数、リミットオフセット、リミット
制限を使用する際には大きなは、オフセットしないことを確実にしてください。
100000、10を制限する;
アイデアはフィルタリング条件を利用することで、データをフィルタリングが完了し、代わりにクエリデータへのスキップのオフセットされています。
4.select *少ないです
必要なフィールドを選択するようにしてください。
問題は非常に深刻ではありません。
我々のモデルのORMフレームワークは、*選択に使用されています。
ランド（）によって5.order、使用しないでください
ロジック：ランダムな順序
mysql> select * from t_student order by rand() limit 5;
+--------+------------+-----------+--------+-------+--------------------------------------+----------+
| id | first_name | last_name | gender | user | password | class_id |
+--------+------------+-----------+--------+-------+--------------------------------------+----------+
| 643727 | 2bc9f | e6155 | 1 | 602-f | a4787d8d-cce8-4b1a-813e-6a67670b5eef | 353 |
| 583044 | 0077a | 0b151 | 2 | 5b8-4 | b6a1f25e-962b-47ef-8d02-1017cc4f7433 | 240 |
| 648485 | 62b4d | 82efc | 2 | 68c-5 | ca06c084-2f77-4966-a315-b26853efea29 | 191 |
| 85567 | a2911 | 7ffe6 | 2 | a09-b | 71da7a3f-75f6-4c74-b2ac-7c1bff65d4e5 | 114 |
| 360811 | edd74 | 5e815 | 2 | 30b-d | e05b0fae-2e1f-4a7b-8141-a0774644e11b | 508 |
+--------+------------+-----------+--------+-------+--------------------------------------+----------+
5 rows in set (2.98 sec)
問題は、生成された乱数の大規模な量が、それぞれのレコードを生成する必要があるということであるだけで5つのレコードが必要です。不要ランダムに生成されました。
一般的なアプローチ：アプリケーション、データベースの主キージェネレータランダムに良い使用は、主キーを取得します。
mt_rand（MIN、MAX）
6.単テーブルマルチテーブルクエリ
単一表：各照会テーブルのみに関連する
マルチテーブル：サブクエリは、複数のクエリテーブルによって行われたクエリに参加し、
単一のテーブルのクエリの代わりにマルチテーブルクエリを利用します。パフォーマンスの問題の原因は、の次の側面に反映
マルチテーブルクエリの実行：、サブクエリに参加し、それを行うためのテーブルもあります。、どこへ行くの合併の結果を実行します。
分布、単一テーブルのクエリを算出し、加側を計算します。マルチテーブルのクエリは、データベースへの圧力を計算します。
マルチテーブルクエリは、テーブルには、ロック時間が長くなります。プログラムの同時パフォーマンスを低下させます。
単一テーブルのクエリは、プログラムの複雑さを増します。ORMモデルを使用して、モデルは、単一テーブルのプロセスを完了するために多くの仕事を持っています。
7.count（*）問題
何の問題に対応するMyISAMテーブルは、データのMyISAMの合計量が自動的にテーブルに格納されます。
InnoDBのためではなく、内部カウンタ。統計は一定で仕事している場合。私たちは、統計を完了するために、所有する必要があります。
テーブル内のレコード数、追加の記録：
| ID | テーブル（ユニーク） | カウント |
|---|---|---|
| 1 | t_student | 700000 |
| 2 | t_calss | 1000年 |
（ID）をカウントし、統計IDフィールドがヌルの数ではない
数（1）、COUNT（*）と同様。レコードの数をカウントします。
8.limit 1
。判断された場合にのみ推奨1プラスリミット取り出す
。、1つのフレームの操作クエリの制限を自動的に増加します。