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