SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH
テストで実際に見たウェブサーバの「遅い」状態とは - Qiita
さくらインターネットのアドベントカレンダー25日目が空いてしまったので、ウェブサーバのチューンナップについて書くことにしました。 私は今日からお休みですが、さくらインターネットは年末年始も休まずに働いていますので、ご安心ください。 年末年始のシフトに入ってくれた社員の皆さんに感謝です。 ということで、責任を持って空いたカレンダーの埋め合わせをさせて頂きますｗ サーバのレスポンスが遅いとは？ なんだかサーバのレスポンスが悪いなぁってことは皆さんも体験されたことあると思います。 原因としては大きく分けて2種類あり、ひとつはApacheやnginxなどのウェブサーバソフトウェアの設定において同時に処理できる上限に達しているケースと、サーバ自体の負荷が高まっているケースです。 前者はApacheでいうとMaxClientsを調整することで対応できますが、そもそもサーバの性能以上にMaxClient
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
チェックリストでリスクを見つけてプロジェクトを幸せにしよう - Qiita
リスク要因を洗い出してリスク管理！ プロジェクト管理とはリスク管理とイコールだ！と言っても過言ではありません。 すべてのリスクを回避すれば、プロジェクトは 期限通りに、 要件通りに、 お客様も満足して、 幸せに、 終わるはずなのです。 ITプロジェクトのリスク予防への実践的アプローチ IPAが、そんな幸せへの最短ルートと言うべきドキュメントを出しています。それが、 ITプロジェクトのリスク予防への実践的アプローチ(PDF) です。 長いですが、一読の価値はあるというか、百読の価値あるドキュメントです。 プロジェクトの最初に、プロジェクトの途中で、プロジェクトが終わってから、それぞれ違う読み方が出来ると思います。 ただ、長いので、簡潔なチェックリストにしてみました。 これをチェックするだけでも、割といい線でリスクの洗い出しが出来るはずです。 リスクが見つかったら、対応方法を考えなければいけま
MySQL Cache メモ - Qiita
メモと言う名のコピペ ちょっと古い、5.1 だけど日本語ドキュメントがそこしか無かったのと、英語読む気力ないけど、とりあえずめも 動作とかごにょごにょ クエリ キャッシュは、SELECT SQL_CALC_FOUND_ROWS ... のクエリで動作し、後続する SELECT FOUND_ROWS() クエリで返る値を格納します。FOUND_ROWS() は前のクエリがキャッシュからフェッチしていても、正確な値を返します。これは、検索したレコードの数をキャッシュで保管しているためです。SELECT FOUND_ROWS() クエリ自体はキャッシュの対象ではありません。 クエリをキャッシュする設定である場合、その結果 (クライアントに送信したデータ) を、結果の読み出し中に、クエリ キャッシュに格納します。そのため、データの扱いは、ひとまとめではありません。つまり、クエリ キャッシュで、デー
Apache Benchでサクッと性能テスト - Qiita
使ってみる 例えば、100ユーザが同時にhttp://www.example.co.jp/ に1リクエストを発行した場合を想定。 ab -n 100 -c 100 http://www.example.co.jp/ 同時に100ユーザが、1ユーザーあたり10リクエストを発行した場合を想定。 -nには100 x 10 = 1000を指定します。 ab -n 1000 -c 100 http://www.example.co.jp/ 接続先にベーシック認証がかかっている場合。 -Aの後にベーシック認証ユーザとパスワードを:（コロン）で区切って指定します。 ab -n 100 -c 100 -A hogeuser:hogepass http://www.example.co.jp/ 同時接続数よりTotal発行リクエスト数が少ないとエラーメッセージが表示されます。 同時に100人で合計10リクエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLはインデックスされた文字列型カラムに数値型カラムをインデックスを使って結合できない - Qiita
中規模サイトのApacheチューニング - Qiita