ChatGPTにSQLチューニングさせてみた - Qiita
ChatpGPT（モデルはGPT-4を利用）にシンプルなSELECT文とテーブル・インデックス定義を与えてSQLチューニングの案出しをしてもらいました。 ちなみに、プロンプトやChain of Thought などの工夫は一切せず、シンプルに質問をぶつけています。 以下、注意事項。 実務利用と比べるとシンプルすぎるのでお遊びの範囲を超えていません。 どのチューニング案が適切かは多くの要素（例えば以下）が関わってくるので、一概に判断できず実際に測定を行い確認する必要があります。 データ量やその分布 ハードウェアやRDBMSの種類・バージョンなどの環境 性能要件（何秒以内のレスポンスが必要か、同時実行数はいくつかなど） ChatGPTへの質問とその回答 1. 単純なインデックスが不足しているケース 質問 以下のSQL文の性能を改善するにはどうしたらよいでしょうか。 select custome
2008-06-29
mysqlを利用していて、indexをちゃんと張っているのにパフォーマンスが出ない。 explain でも type = ref / key = INDEX 等が表示されているのにすごくクエリーが遅かったりする。 思い切って index を消したら逆にパフォーマンスが改善した! why? データ件数が数万件を越えたあたりからパフォーマンスが劇的に下がった。 と、悩んでいたりしませんか? そんな悩みのひとつの解決策になってくれるかもしれません。 テストは vmplayer 上の debian etch で行います。 ホスト環境 intel Q6600 メモリ2Gの WindowsXPです。 クエリーをキャッシュされないように、クエリキャッシュを 0 にします。 /etc/mysql/my.cnf query_cache_size = 0 #no cahce debug swapで遅くなると困
パフォーマンスを求めて - お前の血は何色だ!! 4
結局、わかったことは、 次の4つ。 index から 実体へのシークは遅い。 すべてがindex内で完結するクエリーは早い。 limit をつけても where や order by すると意味がない。 indexを張るなら Using indexe をゲットできないと負けかな。 では、select で取得する値すべてに index を張りますか? 場合によっては可能ですが、テーブルに文字列なんかがふんだんに含まれていると難しいものがあり、現実的ではありません。 そこでこんな方法を提案します。2段階にわけてクエリーを打ちます。 A. task テーブルの 2008/6/5 〜 2008/6/18 のデータを開始日順にならべて、先頭5件だけ表示せよ。 select SQL_CALC_FOUND_ROWS * from task where task.task_starttime <= '20
Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
最強のJVMチューニング・ツール: GCログを可視化するGCViewerとリモート接続でプロファイリング可能なVisualVM
まずは倍率を１０００倍から５０００倍に上げます。 Data Panelも一旦非表示にします。 さて、これを見ると、使用済みヒープと使用済みNew領域は比例しつつ一定の間隔で上下しています。 ここからは特異点は見えないので、一旦非表示にします。 イニシャル・マークレベル（黄色の線）も一定で、分析対象としづらいので非表示にします。 すっきりして少し見やすくなりました。 ここから、 最も時間がかかっているのはイニシャル・マーク イニシャル・マークは1分間に２回程度発生している ということが読み取れます。 イニシャル・マーク では、そもそも、コンカレントGCにおけるイニシャル・マークとは何なのでしょうか。 OracleのドキュメントのReviewing GC with the CMSによると、New領域から参照されているオブジェクトをマークするのだと。 Stop the Worldを伴い、マイナー
MySQL 5.6ではprofilingが非推奨になってしまった件 | GMOメディア エンジニアブログ
こんにちは、DBAのたなかです。 べんりなべんりなprofilingですが、5.6からは非推奨になってしまいました。 mysql56> SET profiling= 1; Query OK, 0 rows affected, 1 warning (0.03 sec) mysql56> SHOW WARNINGS; +---------+------+----------------------------------------------------------------------+ | Level | Code | Message | +---------+------+----------------------------------------------------------------------+ | Warning | 1287 | '@@profiling' is
MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記
InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1＋InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト：今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip：元テキストをgzipコマンドで圧縮したものです。 MyISAM：記事をMyISAMのテーブルに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsパフォーマンス・チューニング入門
SQLチューニング入門 入門編
ヤフー社内でやってるMySQLチューニングセミナー大公開