Skip to content
GitLab
Menu
Projects
Groups
Snippets
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
wwwanlingxiao
system-design-primer
Commits
eaa447cc
Commit
eaa447cc
authored
Dec 09, 2019
by
SATO Yusuke
Committed by
Donne Martin
Dec 08, 2019
Browse files
ja: Fix mistranslation in SQL tuning section (#305)
parent
3ea0b15b
Changes
1
Hide whitespace changes
Inline
Side-by-side
README-ja.md
View file @
eaa447cc
...
...
@@ -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
)
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment