開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
Apacheのチューニングメモ - Qiita
個人的Apacheチューニングのメモ。 間違いがあったら教えて下さい！ prefork 前提 Apacheでは、リクエストはApacheの子サーバプロセスが処理する。 子サーバプロセスは動的にforkで生成されたり、殺されたりする。 が、forkはとても重い処理なので、forkが発生しないように設定するのがよい。 チューニング方針 負荷が高かろうが低かろうが常に一定数のプロセスが動いている状態にする。 preforkの動作 MaxClientsは絶対値。 子プロセス数はこの値を超えない。 （以下正確ではないですが簡単に） Apacheは負荷が高くなってきたら 子プロセスを生成していく アイドル状態の子プロセスはMinSpareServers以上になるよう維持 MaxClients以上の子プロセスは生成しない MinSpareServersよりMaxClientsが強い 負荷が低くなってきた
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
ＯＲＡＣＬＥ／オラクルＳＱＬリファレンス（チューニング）
サンプルコード付きの実践的なＯＲＡＣＬＥ ＳＱＬのリファレンスを公開しています。
上流エンジニアなんて死んじまえ
[居酒屋。サラリーマン風の男がグラスを片手にくだを巻いている。] もうさ、システムエンジニアなんて免許制にしちまえよ。 こんな複雑で難しい仕事、ロクにソフトウェア工学も修めてないトーシロがやろうってのが間違いなのよ。いやおれも含めての話よ？ 何か開発でポカやるじゃん。 ポカやったら、レビューが足りなかったとかさ、チェックが甘いとかさ、なるじゃん。 でもって、誰でもできるようにチェックリスト作ろうとか、手順書作ろうとかって話になるじゃんね。 違うんだよ。 例えばさ、医者の診察考えてみ？あれってチェックリストがあれば誰でもできるの？違うでしょ？ 6年間も大学通ってさ、人のからだの仕組みを隅から隅まで全部勉強して、国家試験パスして、研修医として経験積んで、それでようやく診察できるようになるわけでしょ。 今のIT業界、それもほんとに能力ある人が集まらない、底辺のIT業界って、 医者が足りない、でも
DoctrineとPropelのパフォーマンス比較 - しんふぉにゃん
# 2009/09/23 22:45 Fivestarさんからコメントで教えていただいたDoctrineのINSERTについてテスト1に追記しました。 # 2009/09/24 01:03 Fivestarさんからコメントで教えていただいたDoctrineのQueryCacheについてテスト3に追記しました。 symfonyとしては「これからはDoctrineがメイン」という方向性（symfony 1.3ではデフォルトのORMがDoctrineになっていますし）のようなので、いろいろな機能がDoctrineを基準に実装されていくことになるのだろうと思われますが、実際の案件に使っていくには、やはりパフォーマンスが気になるところです。 そもそもPropelでもPDOが採用された1.3が出るまではさんざん「遅い」と言われていて、それが「symfonyってもっさり」の原因になっていたのではないかと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コマンドによる「負荷」の原因切り分け
＠IT：連載記事 「Oracle SQLチューニング講座」