ja: Fix mistranslation in SQL tuning section (#305)

pull/341/head
SATO Yusuke 2019-12-09 12:35:44 +09:00 committed by Donne Martin
parent 3ea0b15b50
commit eaa447cc39
1 changed files with 11 additions and 11 deletions

View File

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