ChatGPTにSQLチューニングさせてみた - Qiita
ChatpGPT（モデルはGPT-4を利用）にシンプルなSELECT文とテーブル・インデックス定義を与えてSQLチューニングの案出しをしてもらいました。 ちなみに、プロンプトやChain of Thought などの工夫は一切せず、シンプルに質問をぶつけています。 以下、注意事項。 実務利用と比べるとシンプルすぎるのでお遊びの範囲を超えていません。 どのチューニング案が適切かは多くの要素（例えば以下）が関わってくるので、一概に判断できず実際に測定を行い確認する必要があります。 データ量やその分布 ハードウェアやRDBMSの種類・バージョンなどの環境 性能要件（何秒以内のレスポンスが必要か、同時実行数はいくつかなど） ChatGPTへの質問とその回答 1. 単純なインデックスが不足しているケース 質問 以下のSQL文の性能を改善するにはどうしたらよいでしょうか。 select custome
DBスキーマ変更管理ツール sqldef を試してみた - Qiita
1. sqldef とは sqldef は "The easiest idempotent MySQL/PostgreSQL/SQLite3/SQL Server schema management by SQL." と謳っているDBスキーマ変更管理ツールです。 通常の開発において DDL 文を管理する場合、環境を１から作るように CREATE TABLE 文など新規作成 DDL 文を準備すると共に、既に作成済みの環境でテーブルを変更するために ALTER TABLE 文など差分適用 DDL 文を準備する必要があります。この２種類の DDL 文を二重管理しないといけないというのは DBA にとっては頭の悩ましい問題でした。（差分適用 DDL 文のみ準備し、１から環境を作る場合も全ての変更を適用するという手もありますが…） sqldef を利用すると、変更適用先 DB の現在の状況と新規作成
ぐるぐる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ページを開く
