Covering Index と self-join と MySQL - blog.nomadscafe.jp
某サービスのクエリチューニングのお話。 ブログとか日記とかそういうサービス系で次のようなテーブルがあったとします。 CREATE TABLE entries ( id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, user_id INT UNSIGNED NOT NULL, posted_by TINYINT UNSIGNED NOT NULL, --#PC、mobileなどどこから投稿されたかのフラグ title VARCHAR(512) NOT NULL, body TEXT NOT NULL, created_at DATETIME NOT NULL, updated_at TIMESTAMP NOT NULL, status TINYINT UNSIGNED NOT NULL, INDEX (user_id,created_at
Ring
Ringとは、リクルートグループ会社従業員を対象にした新規事業提案制度です。 『ゼクシィ』『R25』『スタディサプリ』など数多くの事業を生み出してきた新規事業制度は、 1982年に「RING」としてスタートし、1990年「New RING」と改定、そして2018年「Ring」にリニューアルしました。 リクルートグループの従業員は誰でも自由に参加することができ、 テーマはリクルートの既存領域に限らず、ありとあらゆる領域が対象です。 リクルートにとって、Ringとは「新しい価値の創造」というグループ経営理念を体現する場であり、 従業員が自分の意思で新規事業を提案・実現できる機会です。 Ringフロー その後の事業開発手法 Ringを通過した案件は、事業化を検討する権利を得て、事業開発を行います。 さまざまな事業開発の手法がありますが、例えば既存領域での事業開発の場合は、 担当事業会社内で予算や
SQLパフォーマンスの「見える化」をプロセス全体に適用する
アプリケーションライフサイクルとSQLパフォーマンス 過去2回にわたって見てきたSQLパフォーマンスチューニングの手法を、今回は、アプリケーションライフサイクル全体のなかでとらえなおしてみましょう。 SQLのパフォーマンス問題の多くは、テスト段階でチェックされるべきものかもしれませんが、実際には、運用段階に入ってから問題が顕在化することもあります。また、開発の初期段階から、設計的にパフォーマンスを発揮できない構造を採用していたり、実装中に、パフォーマンス劣化を引き起こす遠因となるコードが混在してしまうかもしれません。 今回は、アプリケーションライフサイクルの各フェーズで、それぞれどのようなSQLパフォーマンスに対する対処が考えられるのかを見ていこうと思います。 設計変更が引き起こすパフォーマンス問題 データベース設計は、最終的にSQLパフォーマンスにも影響を与えます。前回の記事で紹介したよ
データベースの構造上のボトルネックを「見える化」する
パフォーマンス向上の指針 前回、SQLプロファイリングの概要と簡単なチューニングの例を紹介しました。SQLパフォーマンス問題を「見える化」することによる効果をご覧いただきましたが、実際のデータベースでは、より広範な要素がチューニングにかかわります。全体像を容易に理解できることも「見える化」の効果なのですが、より複雑で詳細な分析を必要とするときに、その全体像からドリルダウンして特定の箇所を調べることができるのも、「見える化」のメリットです。 例えば、ハードウェア性能がそもそも処理要求に追いついていない場合。これは、CPU時間がハードウェアに搭載されたCPU数を大きく上回る場合です。前回紹介したプロファイリング情報を見れば、CPU負荷が高い場合を見分けられます。 一方、ひとつのSQLの処理に大きな時間がかかっている場合には、そのSQL文の書き方やクエリプラン（実行計画）を見直す必要があるでしょ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
