ChatGPTにSQLチューニングさせてみた - Qiita
ChatpGPT（モデルはGPT-4を利用）にシンプルなSELECT文とテーブル・インデックス定義を与えてSQLチューニングの案出しをしてもらいました。 ちなみに、プロンプトやChain of Thought などの工夫は一切せず、シンプルに質問をぶつけています。 以下、注意事項。 実務利用と比べるとシンプルすぎるのでお遊びの範囲を超えていません。 どのチューニング案が適切かは多くの要素（例えば以下）が関わってくるので、一概に判断できず実際に測定を行い確認する必要があります。 データ量やその分布 ハードウェアやRDBMSの種類・バージョンなどの環境 性能要件（何秒以内のレスポンスが必要か、同時実行数はいくつかなど） ChatGPTへの質問とその回答 1. 単純なインデックスが不足しているケース 質問 以下のSQL文の性能を改善するにはどうしたらよいでしょうか。 select custome
DBからの更新日時に基づく差分データ抽出 - Qiita
（この方法は dbt のincremental modelsに関するドキュメントの models/stg_events.sql を参考にしています） この方法は差分データ抽出する際にデータソース側でデータ変更が発生していなければ概ね問題ないのですが（データソース側でレコードがDELETEされるケースを考慮しなければ）、データソース側でデータの追加・更新が発生している場合は、差分データを抽出し損ねる可能性があります。 例えば以下のようなケースです。 トランザクション①が購入ID=101のレコードをINSERTするが、何かの原因（別の処理をする、ネットワークで少し待たされるなど）でコミットはすぐにはされない。 トランザクション②が購入ID=102のレコードをINSERTし、すぐにコミットされる。 1回目の差分データ抽出の処理が動く。この時点で購入ID=102のレコードはコミット済みのため抽出さ
ぐるぐるSQLは止めてくださいという話 - Qiita
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
