@@ -902,31 +902,31 @@ SQLチューニングは広範な知識を必要とする分野で多くの [本
902
902
903
903
##### スキーマを絞る
904
904
905
- * より早い接続を得るために、連続したブロックの中のディスクにMySQLをダンプする 。
905
+ * MySQLはアクセス速度向上のため、ディスク上の連続したブロックへデータを格納しています 。
906
906
* 長さの決まったフィールドに対しては ` VARCHAR ` よりも ` CHAR ` を使うようにしましょう。
907
907
* ` CHAR ` の方が効率的に速くランダムにデータにアクセスできます。 一方、 ` VARCHAR ` では次のデータに移る前にデータの末尾を検知しなければならないために速度が犠牲になります。
908
- * ブログ投稿などの大きなテキスト ` TEXT ` を使いましょう。 ` TEXT ` ではブーリアン型の検索も可能です。 ` TEXT ` フィールドを使うことは、テキストブロックを配置するのに用いたポインターをディスク上に保存することになります 。
909
- * 2の32乗や40億を超えてくる数に関しては ` INT ` を使いましょう
908
+ * ブログの投稿など、大きなテキストには TEXT を使いましょう。 TEXT ではブーリアン型の検索も可能です。 TEXT フィールドには、テキストブロックが配置されている、ディスク上の場所へのポインターが保存されます 。
909
+ * 2の32乗や40億以下を超えない程度の大きな数には INT を使いましょう。
910
910
* 通貨に関しては小数点表示上のエラーを避けるために ` DECIMAL ` を使いましょう。
911
911
* 大きな ` BLOBS ` を保存するのは避けましょう。どこからそのオブジェクトを取ってくることができるかの情報を保存しましょう。
912
- * ` VARCHAR(255) ` は8ビットで数えることができる中で最大の文字数ですが、このフィールドがしばしばRDBMSの中で大きな容量を食います 。
913
- * [ 検索性能を向上させる ] ( http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search ) ことが可能な箇所については ` NOT NULL ` 制約を設定しましょう
912
+ * ` VARCHAR(255) ` は8ビットで数えられる最大の文字数です。一部のDBMSでは、1バイトの利用効率を最大化するためにこの文字数がよく使われます 。
913
+ * [ 検索性能向上のため ] ( http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search ) 、可能であれば ` NOT NULL ` 制約を設定しましょう。
914
914
915
915
##### インデックスを効果的に用いる
916
916
917
- * クエリ(` SELECT ` 、 ` GROUP BY ` 、 ` ORDER BY ` 、 ` JOIN ` ) を用いて取得する列はインデックスを用いると速度を向上できる 。
918
- * インデックスは通常、対数的にデータを検索、挿入、削除する際に用いる [ B-tree ] ( https://en.wikipedia.org/wiki/B-tree ) として表現されています 。
917
+ * クエリ(` SELECT ` 、 ` GROUP BY ` 、 ` ORDER BY ` 、 ` JOIN ` ) の対象となる列にインデックスを使うことで速度を向上できるかもしれません 。
918
+ * インデックスは通常、平衡探索木である [ B木 ] ( https://en.wikipedia.org/wiki/B-tree ) の形で表されます。B木によりデータは常にソートされた状態になります。また検索、順次アクセス、挿入、削除を対数時間で行えます 。
919
919
* インデックスを配置することはデータをメモリーに残すことにつながりより容量を必要とします。
920
920
* インデックスの更新も必要になるため書き込みも遅くなります。
921
- * 大きなデータを読み込む際には 、インデックスを切ってからデータをロードして再びインデックスをビルドした方が速いことがあります。
921
+ * 大量のデータをロードする際には 、インデックスを切ってからデータをロードして再びインデックスをビルドした方が速いことがあります。
922
922
923
923
##### 高負荷なジョインを避ける
924
924
925
- * パフォーマンスが必要なところには [ 非正規化] ( #非正規化 ) を適用する
925
+ * パフォーマンス上必要なところには [ 非正規化] ( #非正規化 ) を適用する
926
926
927
927
##### テーブルのパーティション
928
928
929
- * メモリー内に保つために、分離されたテーブルを分割してそれぞれにホットスポットを設定する 。
929
+ * テーブルを分割し、ホットスポットを独立したテーブルに分離してメモリーに乗せられるようにする 。
930
930
931
931
##### クエリキャッシュを調整する
932
932
@@ -935,7 +935,7 @@ SQLチューニングは広範な知識を必要とする分野で多くの [本
935
935
##### その他の参考資料、ページ: SQLチューニング
936
936
937
937
* [ MySQLクエリを最適化するためのTips] ( http://20bits.com/article/10-tips-for-optimizing-mysql-queries-that-dont-suck )
938
- * [ VARCHAR(255)をそんなにたくさん使う必要ある ?] ( http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l )
938
+ * [ VARCHAR(255)をやたらよく見かけるのはなんで ?] ( http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l )
939
939
* [ null値はどのようにパフォーマンスに影響するのか?] ( http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search )
940
940
* [ Slow query log] ( http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html )
941
941
0 commit comments