Databaseのチューニング全般についての話をして、仕上げは、システムのストレージ層を適切に設計する話に進んで行くようにします。それが目標（？！）
シリーズ（？）の開始は多く使用するMySQLのチューニングのレビュー。
1。開発者を苦しめる。
2。slow queryの基準値を1に設定してindexを使用していないqueryは無条件ください。（ますます問題になると、最後にはinnodb使うようになったよ）
3。innodbを使用すると、メモリ配分することが難しい。特にJoinするqueryの頻度が高い場合は、さらにinnodb書け。
4。innodbはcommitをサポートします。commitをサポートするという話は、トランザクション単位でconnectionが可能であることを意味。
5。myisamを使うときもrand/ read_key_bufferオプションを適切に調整しなければならない。
6。Languageでprepared構文をサポートする場合は、必ず使用してください。大部分のprepared文法はPoolingをサポートします。Poolingを使用すると、Loadが高い状態でconnection値に大きな違いが見えます。
7。connectionの値を減らすことがチューニングの1回原則。
8。その次こそQueryとindex調整。
9。それでもダメならHardwareにたくさんのお金を投資してください。
10。担当する開発者がいなくてもHardwareにたくさんのお金を投資してください。
11。エンジニアとチューニング/メンテナンスのことで契約するよりもコストが安くならその投資しろ
12。当然のことながら管理するDBのサイズがめちゃくちゃ大きい場合（Hardwareを限界まで使用している場合）のエンジニアが安い。一種のトレードオフ。
13。チューニング/メンテナンスの仕事をさせて欲しい、少なくとも2～3枚の文書を用意しておこう（履歴は知りましょう。）
14。解析ソフトウェアをあまり信じてはならない。大きな枠組みは捉えたが、最終的には、真理のCase by Caseます。
15。オンラインコミュニティを運営している場合、セッションに基づいて、同時接続者状況なんてみたい。可能であればDBMSよりmemcached（or redis）を使用しましょう。
16。小さな機能のためのソフトウェアを実装したこれ完全に問題（例えばDBMS）になることがある。常にシステム全体を考えてソフトウェアを導入しよう。
一応ここまで。いつになるか分からないが、2編を準備中。