1 - 38 件 / 38件
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
今回は、SQLを書く上で特にパフォーマンスに影響のあるSQLの実行計画の読み方について解説します。実行計画はデータベース製品によってさまざまに差異がありますが、ここでは比較的どのデータベース製品でも共通する内容について解説します。 実行計画とは記述したSQLが実際にデータベースの内部でどのように処理されて結果を返すか、その処理方法を記述した情報です。 A5:SQL Mk-2では、SQLエディタで実行計画を見たい SQL の上にキャレットがある状態でメニューから [SQL(S)] – [SQLの実行計画(J)] または、Ctrl+E で表示できます。 表示の仕方はデータベース製品ごとに異なりますが、多くのデータベース製品ではツリー状の情報として表現されます。(このため A5:SQL Mk-2でもツリービューで実行計画を表示します。) ツリーのリーフ(端)から処理が行われ、ルート(根)に向かっ
まいえすきゅーえりたい ぽすぐれない おらくるってる(狂ってる)tomoです。 今日はいつものMySQLリファレンスを読むではなく、夏休みの宿題にしていたこれをやってみます。 MySQLとOracleDBの実行計画を比較してみた さて同じようなテーブルで同じデータを載せて。 実行計画を取ってみた時、どのくらい情報量が違うのか簡単に違いを見てみましょう。 前提として、以下をご認識ください。 一方はOSSのDBエンジン、もう一方はガチガチ商用DBエンジンです。情報量が違うのは当たり前であって、良し悪しを比較したいのではありません。そして製品比較をしたいのではありません。いつも商用DBメインで使っているエンジニアが、OSSのDBにこうゆう情報も出してほしいな!というのをお願いしたいと思っていて、それを考える元ネタメモだと思ってください。 OSSでこれだけの情報出せるMySQLや、今回紹介しません
SQL実行の流れ まずはSQLがどのような流れで実行されるのかを見ていきます。 SQL実行の流れは大まかに捉えると以下のようになります。 パーサ パーサでは、ユーザーから送信されたクエリを受け取り、その文法的な正確さを検証します。SQLクエリが正しくフォーマットされているか、必要な構文要素が全て含まれているかをチェックし、例えばFROM句で指定されたテーブルが存在するかどうかも確認します。 文法的なエラーがある場合、例えばカンマの欠落や存在しないテーブルの参照など、クエリはエラーとして返されます。 エラーがない場合は、クエリは「抽象構文木」というデータ構造に変換されます。これにより、データベースはクエリをより効率的に解析し、次の処理ステップに進めることができます。 オプティマイザ SQLクエリがパーサを通過した後、次にクエリの最適化を行うのが「オプティマイザ」です。オプティマイザの主な役割
こんにちは、ECプラットフォーム部の権守です。普段はID基盤やAPI Gatewayの開発を行い、ZOZOTOWNのリプレイスに携わっています。 本記事では、ID基盤で開発・導入したMySQL実行計画の簡易検査を行うツールを紹介します。 ツール開発の経緯 RDBにおけるテーブル設計は利用するクエリに応じて適切なインデックスを設定するなど専門的な知識を必要とし、設計できる人が限られてきます。しかし、アプリケーション上で利用されるクエリは機能の追加・改修に伴って日々変化していくため、それら全てに目を通し、漏れなく適切な設計することは困難です。そこで、専門的な知識がなくても設計に問題がないかの簡易的な検査を行えるツールを開発し、CIに組み込むことで自動的に問題を検出できるようにしました。 ツール開発のアプローチ ID基盤ではDBMSとしてAmazon Aurora MySQLを使用しています。そ
お知らせ 本記事をベースに新しい記事を公開しました。 PostgreSQL インデックス肥大化とインデックスコストへの影響(再モデル化) - ぱと隊長日誌 新しい記事ではインデックスコストモデルの正確性を向上させました。 新しい記事を参照いただけますと幸いです。 概要 PostgreSQL のインデックスサイズは一度大きくなると、その後小さくなるタイミングが限られています。 「[改訂新版]内部構造から学ぶPostgreSQL-設計・運用計画の鉄則」でインデックスファイルサイズが小さくなるのは以下のタイミングとしています。 DROP INDEX でインデックス自体を削除した場合 TRUNCATE TABLE でテーブル全体を空にした場合 REINDEX でインデックスを再構成した場合 [改訂新版]内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design p
はじめに 以前こんなツイートをしました。 すると、リプライで色々とコメントを頂きました。(疑問を投げかけたら答えてくれる方々、本当にいつもありがたいです🙇♂️) ということで、本記事では推定行数と実際の行数の乖離を減らすために何をやったのかを備忘として書きます。 ただ、実際のSQLや実行計画を書くことはできないので、あくまでどんな考え方をしたのか、ということを書きます。 対処法1(対象のテーブルのautovacuum頻度を変更) 対象のテーブルはかなり更新の激しいテーブルだと聞いていたので、まずは統計情報が最新化されているかを考えました。 更新が激しくてautovacuum時の自動ANALYZEが追い付いていないんじゃないかと考え、対象のテーブルだけ自動ANALYZEの頻度が上がるように設定を変更しました。 PostgreSQLの設定パラメータは基本的にはpostgresql.conf
Merpay Advent Calendar 2020 の11日目は、メルペイ Solutions Team の apstndb がお送りします。 色々な場所で既に書かれている通り、メルペイはサービス開始当初から主要なデータベースとして Google Cloud Platform(GCP) の DBaaS である Cloud Spanner を使っています。 この記事ではメルペイにおける Cloud Spanner の実行計画の活用のために取り組んだことについて紹介します。 Cloud Spanner の特性である外部一貫性による強い一貫性保証、レプリケーションによる高い可用性、水平分散による高いスケーラビリティ、リレーショナルデータモデルによるスキーマ、フルマネージドなことによる低い運用負荷などは多くの業界にとってメリットがあるものですが、金融サービスであるメルペイも例外ではありません。
岸田総理大臣が掲げる「新しい資本主義」の全体の構想と実行計画が決まりました。人への投資を重点的に行うとして、およそ100万人を対象に能力開発や再就職の支援を行うことや、個人の金融資産を貯蓄から投資に促すための「資産所得倍増プラン」を策定することなどが盛り込まれました。 持ち回りの臨時閣議で決まった全体構想と実行計画では、官民連携のもと気候変動や少子高齢化など社会的課題の解決を図りながら経済成長を目指すとして「人」、「科学技術・イノベーション」「スタートアップ」「グリーン、デジタル」の4つの分野に重点的な投資を行うとしています。 ▼「人」への投資ではさらなる賃上げへの取り組みとともに、およそ100万人を対象に、非正規も含めた能力開発や再就職の支援を行うなどとしています。 そして、個人の金融資産を貯蓄から投資にシフトさせるため、個人投資家向けの優遇税制「NISA」や、「個人型」の確定拠出年金=
こんにちは!プロダクトマネージャーのひまらつ(@himara2)です。 「戦略」とはどこか掴みどころのない言葉です。会社の事業戦略を考えたりそれをプロダクト戦略に落とし込んだりを定期的に行っていますが、戦略とは何を考えることなのか、いまいち解像度があげきれずにいました。 最近、プロダクトの行く先を考えるなかでその意味するところが少しわかった気がしました。戦略とは何か?戦略を立てるときに何に気をつければよいのか?このnoteで自分の理解を整理してみます。 戦略とはなにか?戦略とは「目的地に向かうルートを決めるもの」、というのが自分の理解です。 目的地というのは、大きく捉えればビジョンです。「こういう世界をつくりたい」というビジョンを叶えることが事業の最終的な目的地といえます。 もう少しミクロだと、事業として重要な地点にいくことが目的地です。PMFするとか、広く市場に受け入れられるとか、グロー
こんにちは、会計チームでエンジニアをやっている ut (@utdoi1) です。最近はレポート周りの開発を主に担当しています。 先日あった機能リリースにおいて、大量のデータを対象とした移行タスクを実行する機会がありました。 タスクの概要としては、freee会計に登録されている事業所1つごとにデータ移行をしていくものでした。 今回はfreee会計にアカウントを作成している全ての事業所に対してタスクを流す必要があったため、普通に実行していたら完了までいったい何日かかるのか分からないくらいの規模感でした。 そのため、並列実行も考慮に入れて割としっかりめに実行計画を立てて臨みました。 この記事では、その実行計画を立てた時の作業の流れと、それぞれの過程における細かい作業内容を紹介します。 計画策定までの流れ 全体としては以下のような流れで作業を進めていきました。 タスク実行時間に関係するデータの度数
マルチテナントなECサイトの注文データをイメージしています。tenant_nameのカラムにテナント名が入り、このカラムとDBユーザーの一致を行セキュリティポリシーよってチェックするようなイメージです。 テストデータ等の準備 それでは検証環境を準備していきましょう。今回の検証にはPostgreSQLバージョン11.11を利用しています。 まずはテーブルを作成 CREATE TABLE orders ( id SERIAL PRIMARY KEY, tenant_name text, product_code text, order_date timestamp ); CREATE TABLE 続いてマルチテナント用のDBユーザーを作成 CREATE ROLE user01 LOGIN; CREATE ROLE CREATE SCHEMA "saas"; CREATE SCHEMA GRAN
私は「Spanner でも他の RDBMS で当たり前に行われているのと同程度には実行計画を理解する」ことをテーマに情報の公開や社内での啓蒙・トラブルシューティングなどの活動を行ってきました。 Cloud Spanner as a SQL System Cloud Spanner の実行計画の活用に関する取り組み Cloud Spanner Unofficial Hacks 私見として、 2017年の Spanner のリリースから8年経った今も実行計画の最適化についての世の中の情報は多くありません。 実行方法が自明ではない SQL をどう現実的に実行可能な程度に最適化するかというような話はまだあまり増えていないと感じています。 この文書は私が株式会社メルペイを退職する前から社外に公開するという約束で書いていたものですが、一年半以上放置してこのまま墓場まで持っていくことになる可能性が出てき
JR北海道は、単独では維持困難とする赤字8区間(通称・黄色線区)の存続に向け、2026年度までに赤字総額を23年度比で3割削減する「高い目標」を掲げた。できる限り赤字を圧縮し、国や北海道、沿線自治体と維持費分担の議論に入る環境を整えるのが狙いだ。今後、利用促進やコスト削減を本格化させるが、人口減が続く中での目標達成は容易ではない。自治体や道は財政負担が膨らむことを警戒しており、26年度末までに区間ごとの抜本的な改善方策をまとめるハードルも高いままだ。 「黄色線区維持には収支改善が不可欠。できるところまで改善し、(国や道、沿線自治体と)残った赤字をどうするか相談していきたい」。JRの村林健吾取締役は4日の記者会見で、収支改善の必要性を繰り返し強調した。...
はじめに こんにちは、SREセクションの子安です。 Oisixのサービスでは、データベースに Amazon RDS for Oracle Enterprise Edition (EE) を採用し、可用性とスケーラビリティを確保するために Active Data Guard 構成を組んでいます。 サービスの特性上、商品の情報を閲覧するような「読み取り(参照系)」の処理がとても多いのが特徴です。 そのため、読み取り専用の リードレプリカ に処理を逃がすことで、書き込みを行う プライマリDB の負荷を減らし、サービス全体のパフォーマンスを安定させています。 今回は、この構成ならではの「リードレプリカでだけSQLのパフォーマンスが急に悪化する問題」と、それを解決するためにデータベースエンジニアとしての経験を活かして取り組んだ、ちょっとした工夫についてお話しします。 そもそも「実行計画」ってなんだっ
Amazon Web Services ブログ 本日閣議決定された『デジタル・ガバメント実行計画』を"クラウドのレンズ"で読み解く 本日令和2年(2020年)12月25日、『デジタル・ガバメント実行計画』が閣議決定に至りました。 今回のブログでは、335ページの大部の政策集となった『デジタル・ガバメント実行計画』(以下、『実行計画』。全文はこちら)を、クラウドの観点から読み直すことで、特に政府部門・公共部門の各お客様にクラウド導入をご検討いただく判断の一助となることを目指します。昨年版から120ページ以上も大幅加筆された最新の『実行計画』では、何が謳われているのでしょうか? 今回のデジガバ実行計画の"柱" 今回の『実行計画』には、(昨年までのバージョンでは見られなかった)4本のメイン・アイディアが新規に配置されています。トップページには、"社会全体のデジタル化を進めるために、まずは国・地方
Amazon Athena でクエリ実行計画の可視化と、実行結果の統計情報を取得出来るようになりました いわさです。 Amazon Athena では1年前のアップデートでクエリパフォーマンスを改善するための実行計画を利用することが出来るようになりました。 そして、本日のアップデートで実行計画の可視化機能が提供され、さらに実行済みクエリから統計情報が取得出来るようになりました。 この記事では、以下のような料金情報CSVを集計するクエリを例にご紹介したいと思います。 実行計画の可視化 以前から、EXPLAIN を実行する機能は Athena でも可能で、以下のような情報を出力することが出来ていました。 しかし、結果の解析に少しコツで、可視化など行いたい場合は別のツールを使って可視化する必要がありました。 今回のアップデートで、実行ボタンの隣に「説明」ボタンが追加されています。 こちらはクエリ
インデックスの詳細解説 インデックスの役割 たとえば漢字辞典において「『氵』を部首とする漢字をしらべたい」という時に「部首」という属性で索引を持っていると便利なように、検索対象となる属性の値をもとにインデックスは通常作られます。そして、漢字辞典で「部首」の索引と「よみ」の索引が別々にあるように、インデックスは通常その属性ごとに作成されます。 このような辞書的な索引のインデックスは属性値が何かの値に一致するデータを検索するためのものでしたが、それ以外にもたとえば数値や日付時刻属性をもつデータに対してある範囲内の属性値をもつデータを取得したい、というような場合にもインデックスは使われます。 さらに、インデックスは、ある属性の値でデータを並び替えしたい、というような場合にも利用できます。後で述べますが、インデックスという仕組みはあらかじめその属性の値でデータを並べておくようなものなのです。インデ
MySQL EXPLAINとは EXPLAINとは、MySQLがどのような実行計画でクエリ実行するかを表示するコマンド。EXPLAINの結果を見ることで効率の悪いクエリを見つけたり、改善結果を確認できる。 EXPLAIN ( SELECT f.film_id, f.title, f.release_year, a.first_name, a.last_name FROM film f INNER JOIN film_actor fa ON fa.film_id = f.film_id INNER JOIN actor a ON a.actor_id = fa.actor_id ); JOIN時のEXPLAINの見方 JOINする場合は、駆動表が一番最初に表示される。 先程の例だと、actorテーブルが駆動表になっているということになる。 駆動表を固定したい場合は、MySQL 8.0からはJ
こんにちは、エンジニアの末武です。 今回はSQLserverの実行計画の見方についてお話します。 システムを作った経験のある方なら、一度は必ずデータベース周りの遅延やパフォーマンス周りに頭を抱えた経験があるのではないでしょうか。 データベース周りの悲鳴が止むことはありませんが、SQLがどのようにデータベースのストレージやメモリにアクセスしているのかを示してくれる実行計画の見方を知ることは、それに対抗する手段として非常に有用です。 それでは早速SQLserverの実行計画を見ていきましょう! 実行計画とは、SQLserverがユーザーが発行したSQLを解析し決定した実データに対して、どのようにアクセス・計算を行うかが記載されている計画書です。 SQLはDBの「どの」データを取得するかをユーザーが指定しますが、「どのように」そのデータを探して取得するかはSQLserverのオプティマイザ機構が
JR北海道は4日、単独では維持困難とする赤字8区間(通称・黄色線区)で、2024〜26年度に沿線自治体と取り組む収支改善の実行計画を正式発表した。8区間の赤字額について、昨年度より32.7%少ない約100億円までの圧縮を目指す。目標達成は路線存続の条件とはしない。JRの村林健吾取締役は同日の記者会見で、26年度までに自治体と維持費分担の議論に入ると明言した。...
excite_techcon2023__RDS_performance_insightと実行計画 との付き合い方__DBとINDEXを学ぼう
YugabyteDBの実行計画を眺める (NewSQL/分散SQLデータベースよろず勉強会 #3 発表資料) 2023年2月16日(木) NTTデータ 技術開発本部 先進コンピューティング技術センタ 笠原 辰仁
テーブル作成とデータ投入 [unix] シェルを使って、テストデータ生成でテストデータを作ったので、SQLiteにデータを投入してみよう。 まずはテーブルのDDLを作成する。 $ cat create_table.sql create table if not exists Test1 ( id integer primary key , name text , last_modified text ); create index if not exists idx_Test1_name on Test1 ( name ); テーブルに投入するデータも作成しよう。 $ paste -d, \ <(seq 10000) \ <(LC_CTYPE=C tr -dc 'A-Za-z0-9' </dev/urandom | fold -w8 | head -n10000) \ <(LC_CTYPE
こんにちは、エンジニアの末武です。 今回はSQLserverの実行計画の見方についてお話します。 システムを作った経験のある方なら、一度は必ずデータベース周りの遅延やパフォーマンス周りに頭を抱えた経験があるのではないでしょうか。 データベース周りの悲鳴が止むことはありませんが、SQLがどのようにデータベースのストレージやメモリにアクセスしているのかを示してくれる実行計画の見方を知ることは、それに対抗する手段として非常に有用です。 それでは早速SQLserverの実行計画を見ていきましょう! 実行計画とは、SQLserverがユーザーが発行したSQLを解析し決定した実データに対して、どのようにアクセス・計算を行うかが記載されている計画書です。 SQLはDBの「どの」データを取得するかをユーザーが指定しますが、「どのように」そのデータを探して取得するかはSQLserverのオプティマイザ機構が
こんにちは。データアナリティクス事業本部の松村です。 早いものでもう入社から1年が経ちましたが、これまでの投稿ペースは平均して月1本、そして間隔にはかなりばらつきがあります。今後はコンスタントに月2本を達成したいなあと思う次第からの、2年目初の投稿です。 RedshiftにおけるPrimary Key制約の役割 Redshiftが一般的なRDBMSとは異なっていることのひとつとして、Primary Key制約が実際には制約として機能しない、というものがあります。かなり有名なのでご存じの方も多いと思います。 しかしながらマニュアルによると、実行計画の作成時には利用されるそうです。 CREATE TABLE Important Primary key constraints are informational only. They aren't enforced by the system,
Oracle Databaseの実行計画を中心にしていますが、他のDatabaseの実行計画も合わせて載せるかもしれません。 基本的に、全部俺で予定していますが、どうーーーしても、どうーーーしても、俺、私にも書かせろ! という方は、ご連絡ください。:)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 最近学んでいるSQLのパフォーマンスチューニングについて簡単に記事にしてきます! 本記事ではSQLのパフォーマンスを意識する上で重要な実行計画の確認をしていきます SQLが実行される流れ SQLが実行されると後はデータベース管理システム(DBMS)があれやこれやと働いて結果を返してくれます。 ではSQLが実行されてからDBMSは一体何をしているのでしょうか? 主に以下のことをしてくれています🦑 1パーサ SQL文の構文解析が行われます。 構文が正しいかどうかをチェックします。 ※(注記)この段階で文法エラーがあればここで止まります。
免責事項 この記事は個人メモとして書き留めておいたものを、分かりやすく纏めてみたものです。記事内容に間違い・補足事項等の指摘があれば適宜修正したいと思いますが、記事の内容を100%保証するものではありません。予めご了承ください。 はじめに (私だけかもしれませんが)インデックスがきちんと利用されているかを、実行計画で確認したりせずに、永らくSQLを利用してきました。『(最近の)オプティマイザは優秀なので、ある程度は自動的に的確な形でSQL実行計画を立ててくれる』という記事を鵜呑みにしてきたからです。それはきっとある程度正しく、またよく使うクエリはDB内でのキャッシュ機構が働くため、中小規模のシステムであれば、問題が表面化することも少ないと思います。 しかし、何事でもそうですが、特にIT系の仕事に於いては、きちんと『基本』を抑えておくことは極めて重要です。 この記事は、SQLServerに作
参考:経済産業省|2050年カーボンニュートラルに伴うグリーン成長戦略 1洋上風力・太陽光・地熱「洋上風力・太陽光・地熱」は、再生可能エネルギーの中でも重要な分野であり、脱炭素社会の実現に向けて積極的に取り組んでいます。具体的には、以下のような目標や施策があります。 洋上風力発電: 2030年までに1,000万kW、2040年までに3,000万kW〜4,500万kWを導入することを目指しています。また、系統・港湾のインフラを計画的に整備し、海底の長距離直流送電の整備も検討しています。 太陽光発電: 2030年を目途に、次世代型太陽電池の研究開発を重点化し、グリーンイノベーション基金の活用も検討しています。また、アグリゲーションビジネスやPPAモデルなど関連産業の育成・再構築を図りつつ、地域と共生可能な適地の確保などを進めています。 地熱: 次世代型地熱発電技術の開発を推進し、超臨界地熱発電
政府は8日、首相官邸で新しい資本主義実現会議(議長・岸田文雄首相)を開き、科学技術分野の成長戦略を議論した。首相は人工知能(AI)や量子技術など先端技術に関する国家戦略を策定すると表明した。今春をメドにまとめる「新しい資本主義」の実行計画に反映させる。首相は会議で「研究開発投資の抜本強化が必要だ。私自身が先頭に立ち、実行計画に科学技術政策について強い国家意思を盛り込みたい」と強調した。AIに関
AWS の Aurora MySQL v1 の EoL が迫り、また MySQL 5.7 の EoL もそう遠い話ではなくなった現在、Aurora MySQL v3 や MySQL 8.0 への移行が進んでいるのではないかと思います。 ※(注記)いや、前者は少ないでしょうね、おそらく。 バージョンアップ時、既存の SQL 文の実行計画が変わってしまい、処理が遅くなるケースがあります。 その対処としてオプティマイザヒントを使うのが今回のネタです。 どんなケースで遅くなる? MySQL 5.6(Aurora MySQL v1)→ MySQL 5.7(Aurora MySQL v2)のバージョンアップで最も有名なのはこちらでしょう。 MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話(freee Developers Hub) こちらは MySQL 5.6(Aurora MySQL
postgres=# EXPLAIN ANALYZE SELECT * FROM Shops; QUERY PLAN -------------------------------------------------------------------------------------------------- Seq Scan on shops (cost=0.00..1.60 rows=60 width=28) (actual time=0.024..0.029 rows=60 loops=1) Planning Time: 0.093 ms Execution Time: 0.053 ms (3 行) Seq Scan・・・プラン演算子のひとつ。クエリを実行するための内部的な処理の種類。Seq Scanはテーブルフルスキャンを指します cost(左)・・・初期コスト。検索結果の1行
本記事の目的 本記事では MySQL(InnoDB) の SQL 性能調査・改善のために、実行計画の主要な確認ポイントを整理します。 また、SQL の重要な要素であるインデックスについても基本を簡単におさらいします。 なお、MySQL 実行計画の各種項目の意味は公式サイトに記載があるが、ぱっと見た時にどれが SQL の性能において重要度が高いのか少しわかりずらかったりしたので、今後のためにも記事に残すことにしました。 SQL パフォーマンスまわりで参考になった書籍や記事も最後に紹介していますので、ぜひそちらも合わせて参考にしてみてください。 インデックスとは インデックスはデータベースの中で特有の構造を持ち、CREATE INDEX 文で作成可能です。 SQL の性能に関わる重要な要素です。 データベースのインデックスは、分厚い紙の辞書から特定の用語を検索することに似ています。あらかじめ順
こんにちは。エンジニアリング本部 プラットフォームエンジニアリングチームの徳富です。 この記事は、 Timee Product Advent Calendar 2024 の 20 日目として、EXPLAINを使用した実行計画の見方についてご紹介します。 背景 タイミーでは、会社の成長に伴い、パフォーマンスチューニングが喫緊に求められています。このような課題に対処するため、クエリのパフォーマンスチューニングにはEXPLAINを使用した実行計画の確認が非常に重要です。しかし、実行計画の解釈には社内でばらつきがありました。この問題を解消するために、実行計画の見方を社内でまとめ、共有することにしました。ただし、この情報を社内だけに留めておくのはもったいないと考え、テックブログを通じて広く公開することに決めました。 実行計画の基本的な見方 MySQLのEXPLAIN文は、SQLクエリがどのように実行
はじめに こんにちは。新卒3年目のchoreii です。 今回はPostgreSQLの実行計画について記事を書こうと思います。 私が初めて実行計画について知った時は難しそうなイメージが先行しており、実際に調べてみても情報量が多くハードルが高かったです。ですが調べていくうちに自分が難しく感じていた理由がわかりました。 それは、多くの記事が「実行計画の基礎知識」と「実行計画をどのようにパフォーマンス改善に活かすか」という2種類の情報を織り交ぜて記載されていたからです。 今回はできるだけ情報量を削減し、「実行計画の基礎知識」にフォーカスした記事を作成しました。これから実行計画を学ぶ人の最初の一歩となれば幸いです。 実際のパフォーマンスのチューニング方法や、検証するための大量データの登録に興味がある方は下記のブログもご覧ください。 tech-blog.rakus.co.jp tech-blog.r
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く