SELECT: Snowflake cost observability and optimizationThe Snowflake optimization and cost management platformGain deep visibility into Snowflake usage, optimize performance and automate savings with the click of a button.
Snowflake Query Optimization: 16 tips to make your queries run faster
Snowflake's huge popularity is driven by its ability to process large volumes of data at extremely low latency with minimal configuration. As a result, it is an established favorite of data teams across thousands of organizations. In this guide, we share optimization techniques to maximize the performance and efficiency of Snowflake. Follow these best practices to make queries run faster while als
GET_QUERY_OPERATOR_STATS 最速解説
筆者 @indigo13love は Snowflake で Principal Cloud Support Engineer をやっていますが、この記事は個人的な記事であり、所属企業の意見などは含まれておりません。 この機能は、日本時間の 12 月 16 日頃にリリースされたバージョン 6.41.2 にて Public Preview として追加された機能となりますが、この記事はもともと 20 日目の記事として書き始められました。 …が、Advent Calendar を眺めていたらちょうど 12 月 15 日の予定が消えていたので、最速解説の名をほしいままにするために急ピッチで書き上げられ、2 日遅れの 12 月 17 日に公開されたものとなりますので「機能のリリース日が Advent Calendar の日付よりも後……？」と思っても大目に見てください。 はじめに 12 月 16 日
RDS for MySQL または Aurora MySQL で CPU 使用率が増加する問題を解決する
Stay up to date with the latest from the Knowledge Center. See all new Knowledge Center articles published in the last month, and re:Post’s top contributors. Amazon RDS for MySQL または Amazon Aurora MySQL 互換 DB インスタンスの CPU 使用率が高い場合のトラブルシューティングと解決方法を教えてください。 簡単な説明 複数の要因で、CPU 使用率が増加する可能性があります。要因には、ユーザーが開始したワークロードの負荷が高い場合、複数の同時クエリ実行、長時間実行されるトランザクションなどが含まれます。 DB インスタンスにおける CPU 使用率の原因を特定する方法について、次のリソースを確
MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub
こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした！障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー
Introducing Sqlcommenter: An open source ORM auto-instrumentation library | Google Cloud Blog
Introducing Sqlcommenter: An open source ORM auto-instrumentation library Object-relational mapping (ORM) helps developers to write queries using an object-oriented paradigm, which integrates naturally with application code in their preferred programming language. Many full-stack developers rely on ORM tools to write database code in their applications, but since the SQL statements are generated b
ぐるぐるSQLは止めてくださいという話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 1
「うわっ…弊社のサービス、遅すぎ…？」を New Relic で劇的に速くした話 - Sansan Tech Blog
Eight事業部 Platform Unit / Engineering Manager の 藤井洋太郎(yotaro) です。 私が属するPlatform Unitはいわゆる基盤チームとも呼ばれ、「アーキテクチャ刷新」「データ基盤整備」「セキュリティ」「環境整備」など多方面での開発・改善を行っています。 その中でも今回は「APIパフォーマンス改善」の取り組みを取り上げたいと思います。 アプリケーション監視 / New Relic さて、Eightではアプリケーションのパフォーマンス監視のために、New Relic を利用しています。 New Relic は多機能で、モバイル向け/インフラ向けのサービスも展開されています。眺めているだけでも楽しいNew Relic。 が、それゆえ何から手をつけていいかわからない。。となりがち！？ そこで今回は Eight での New Relic を使った
カーディナリティについてまとめてみた - Qiita
カーディナリティとは テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティという。 具体例 カーディナリティが低い場合 例えば性別なら、男と女の二種類である。 カラムのデータの種類が、テーブルのレコード数に比べて二種類と少ない。このことを カーディナリティが低い という。 カーディナリティが高い場合 一方顧客番号ならたくさんの種類(番号)が存在することになる。 カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い という。 カーディナリティを踏まえたインデックスの張り方 基本的に、 カーディナリティの高い列に作成する 必要がある。 はじめに、カーディナリティは カラムの値の種類の絶対値と書いたが、先程の例で言うと性別のカーディナリティは2になる。他にも例えば１年間の日付なら1〜
MySQLでorder byにインデックスが効かないケース･ﾟﾟ(ﾟ-ﾟ*; )ｵﾛｵﾛ( ;*ﾟ-ﾟ)･ﾟﾟ
order byにインデックスが効かないケースの前に・・・order byにインデックスが使用されるのは、どんな時？ 単独でインデックスが張られているカラムをorder byに指定したとき。 Where節内で使用したカラムとorder byで指定したカラムと合わせて複合インデックスが張られているとき（ただし、Where内では定数が指定されていること） この通りに指定してもインデックスが効かないケースがあります。 それが下記です。 ※ key1はkey_part11で構成されるインデックス、key2はkey_part21とkey_part22で構成されるインデックスとしています。 order by句に複数のインデックスを使用する SELECT * FROM t1 ORDER BY key_part11, key_part21, key_part22; この例では２つ以上のインデックスをord
MySQLのチューニングについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? MySQLのSELECT時にORDER BYを使用した時のソートの話 テーブルにINDEXが貼られている事が前提ですが、 例えば３テーブルを結合し、ソートをかける時などに、 全てのテーブルの結合を行った後にマスターとなるテーブルで並び替えると、 Using filesortが発生し、SELECTの実行が遅くなる場合があります。 回避方法として、カラムの表示用のマスターテーブルと、ソート用に使うマスターテーブル(別名付け)を用意し 用途を分けたSELECT文にするなどがあります。 #sample.sql SELECT tbl1.col1,
MySQL EXPLAINのそれぞれの項目についての覚書 - Qiita
id/select_type/table どのテーブルがどの順番でアクセスされているか id 実行順番を表す 数字が同じなら複数のクエリが１つのクエリとして実行されている select_typeの詳細 SIMPLE 単一のテーブル サブクエリが絡む場合 PRIMARY 外部クエリ SUBQUERY 相関関係の無いサブクエリ DEPENDENT SUBQUERY 相関関係のあるサブクエリ UNCACHEABLE SUBQUERY 実行する度に結果が変わる可能性のあるサブクエリ DERIVED FROM句で用いられているサブクエリ table 対象テーブルの名称 partition どのpartisionテーブルを使用したか 複数にまたがる時は複数の値が表示される type レコードアクセスタイプ typeの詳細 const pk or uniqueインデックスを使用したルックアップによるアク
kintone の性能改善について紹介します - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。 今回は、サイボウズ製品のひとつである kintone に対して行った性能改善の成果を紹介したいと思います。kintone は面倒なコーディング無しに業務アプリケーションのようなものを作ることができ、様々なデータを格納したり、複雑な条件で検索したりソートしたり、アクセス権もきめ細やかに設定したりできるというサービスです。この kintone はサービスの性質上、多種多様で複雑なクエリを発行します。またデータ量も膨大で MySQL だけで計数十テラバイトのデータが存在しており、クエリの処理時間が長時間かかってしまうこともあります。 サイボウズでは kintone の性能改善に力を入れており、今回はその成果を紹介しようと思います。 はじめに kintone はテナントごとに大きく使い方が異なり、性能改善が効くケースもあれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDS の CPU 使用率がほぼ 100％ どう調査する？ 実例から学ぶ原因と解決策 〜オペ部だより〜 | DevelopersIO
Oracle Database Technology Night #48 津島博士のパフォーマンス講座 - SQLチューニングは実行計画から
Amazon.co.jp: 失敗から学ぶRDBの正しい歩き方 (Software Design plus): 曽根壮大: 本
Amazon.co.jp: プロとしてのSQLチューニング入門: 福田武志: 本
Amazon.co.jp: プログラマのためのSQL 第4版: ジョー・セルコ (著), Joe Celko (著), ミック (監修), ミック (翻訳): 本
GitHub - salsify/goldiloader: Just the right amount of Rails eager loading
)
Cardinality (SQL statements) - Wikipedia