https://ameblo.jp/studionabu/ 説明必ずしなければですか？ ja シリーズ（？）の開始は多く使用する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編を準備中。
]]> https://ameblo.jp/studionabu/entry-11247016291.html Thu, 10 May 2012 18:57:49 +0900 2. HDDは、いつ破損してもおかしくありません。
3. SSD! 最高！
4. できればRAID5を使ってください。 RAID0は怖いです。RAID1は、Backupではない。Backupは、入念に！
5. SSDを使用するときは、SATA3のSSDを使用してください。SATA2との速度差が！
6. お使いのDBの容量が小さければ、ramdiskも考えてください。
7. リアルタイムのMySQLバックアップが必要ですか？Replicationを使用してください
8. SSDを使用すると、MySQL（myisam）のチューニングが減少します。
9. セキュリティが心配な場合はPHPのsuhosinモジュールを使用してください。PHP Appsレベルの注意が必要です。（韓国のPHP Appsは...はぁ...）
10. memcache vs redisで悩んでいます。memcacheがもっと例が多く、運営スタッフに説明しやすいですね。最終的にmemcacheを選択しました。
11. ログインとセッションの管理を完全にmemcacheを使用する予定です。
12. nginxはいつもありがとうございます。最高！
13. Linuxにうまいと言う人の大半は、特定のディストリビューションに上手と言う。
14. 韓国企業95％のサーバー管理者にLinuxは、CentOS

私は、Windowsに本当に未熟である。
IT側の仕事は本当に大変だ。しかし、楽しさがある。（本当に？） ]]> https://ameblo.jp/studionabu/entry-11231023733.html Mon, 23 Apr 2012 06:37:26 +0900