問題タブ [database-tuning]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
sql - postgre 集計パフォーマンス
Postgres (8.3) の単純な集計パフォーマンスに問題があることに気付きました。問題は、(customer_id,order_id) によって一意であるテーブル (たとえば 2 億行) があるselect customer_id,max(order_id) from larger_table group by customer_id
場合、次のことを行う単純な Java/JDBC プログラムよりもクエリが桁違いに遅くなることです。
1) 空の HashMap customerMap を初期化します (これは ID -> 最大注文サイズをマップします) 2) 「select customer_id,order_id from large_table」を実行し、ストリーミング結果セットを取得します 3) 結果セットを反復処理し、すべての行で次のようなことを行います以下:
このパフォーマンスの違いは予想されますか? 上記は内部で起こっていることにかなり近いと思うので、そうは思わないでください。データベースに何か問題がある/正しく調整されていないという証拠ですか?
sql-server - SQL Server TuningAdvisorがインデックスの含まれる列にPRIMARYKEYを追加することを提案するのはなぜですか?
これを何度も見てきましたが、SQL Serverデータベースエンジンチューニングアドバイザーで分析を実行すると、次のようなインデックスを作成するように提案されます。
含まれる列のリストに主キー(クラスター化インデックス)列を含めることは本当に重要ですか?元の行へのリンクとしてデフォルトで含まれているといつも思います。私が間違っている?
更新: SELECT [PrimaryKeyColumn]FROM[dbo]。[SomeTable]WHERE... [Conditions] ...のようなクエリのインデックスを提案していることに注意することも重要だと思います。これは、パフォーマンスと実行プランに大きく影響します。私が理解している限り、インデックスには実際には「クラスター化インデックス」は含まれていませんが、行へのリンクが含まれているだけです。そうですか?
sql - 迅速なテストのために PostgreSQL を最適化する
典型的な Rails アプリケーションの SQLite から PostgreSQL に切り替えています。
問題は、PG で動作スペックが遅くなったことです。
SQLite では約 34 秒、PG では約 76 秒かかり、2 倍以上遅くなります。
そこで、コードを変更せずに仕様のパフォーマンスを SQLite と同等にするためのいくつかの手法を適用したいと考えています(理想的には、接続オプションを設定するだけですが、これはおそらく不可能です)。
私の頭の上から明らかなことのいくつかは次のとおりです。
- RAM ディスク (OSX で RSpec を適切にセットアップするとよいでしょう)
- ログに記録されていないテーブル (データベース全体に適用できるので、すべてのスクリプトを変更する必要はありませんか?)
ご存じかもしれませんが、私は信頼性やその他のことは気にしません (ここでは、DB はただの使い捨てです)。
PG を最大限に活用し、できるだけ速くする必要があります。
最良の答えは、理想的には、それを行うためのトリック、セットアップ、およびそれらのトリックの欠点を説明することです.
更新: fsync = off
+full_page_writes = off
時間は ~65 秒 (~-16 秒) に短縮されました。スタートは良かったが、目標の 34 にはほど遠い。
更新 2: RAM ディスクを使用しようとしましたが、パフォーマンスの向上は誤差範囲内でした。なので割に合わないようです。
更新 3:* 最大のボトルネックを発見し、仕様が SQLite と同じくらい高速に動作するようになりました。
問題は、切り捨てを行ったデータベースのクリーンアップでした。どうやら SQLite は速すぎるようです。
それを「修正」するために、各テストの前にトランザクションを開き、最後にロールバックします。
〜700回のテストのいくつかの数値。
- 切り捨て: SQLite - 34 秒、PG - 76 秒。
- トランザクション: SQLite - 17 秒、PG - 18 秒。
SQLite の速度が 2 倍になりました。PGの速度が4倍になります。
database - データベースのチューニングとデータベース クエリの最適化の違いは何ですか?
データベース チューニングとデータベース クエリ最適化の正確な違いを誰か教えてもらえますか?
ウィキペディアで次のリンクを読みました。
http://en.wikipedia.org/wiki/Query_optimization
http://en.wikipedia.org/wiki/Database_tuning
私の理解によると、データベースのチューニングは他に何もないように見えますが、それはデータベースクエリの最適化です。私はまだ混乱しています
2つの違いは正確には何ですか?
sql-server-2008 - MSSQL2008ExpressのDBチューニングアドバイザー
SQLExpressのTuningAdvisorを使用する方法はありますか?Express用のチューニングツールのようなものはありますか?DBAではないが、Webサイトのパフォーマンスを向上させたい人のために?
debian - postgresql.conf の最適化
私のpostgresqlサーバーは非常に遅いです。特に、異なるスレッドで同時に複数のクエリを実行すると、postgresql サーバーが 5 ~ 15 秒間応答しなくなることがあります。postgresql.confを間違えたのかな。
私の専用サーバーには、2 つのコアと 4 GB の RAM、および標準の SATA-2 ディスクがあります。postgres db (バージョン 8.4) には 6 GB のデータがあり、数百人のユーザーが同時に接続しています。JDBC を使用して postgress にアクセスし、データベースにアクセスする 1 ~ 10 の同時スレッドを実行しています。私のサーバーは debian lenny です。CPU は 100% 使用されておらず、メモリも使用されていません。
助けてくれてありがとう。
mysql - 最近使用されていない mysql テーブル インデックスを見つける
mysql データベースの (innodb) テーブルから重複したインデックスをクリーンアップしています。データベースには約 50 のテーブルがあります。
pt-duplicate-key-checkerを使用して重複キーをチェックできますが、すべてのテーブルから最近使用されていないインデックスを見つけるのに役立つツールがあるかどうか疑問に思っていました。
たとえば。、テーブル "A" に "index_1"、"index_2"、"index_3" と定義された 3 つのインデックスがあり、そのうち "index_3" が最も使用頻度が低い場合、テーブルで行われた 1/10000 クエリごとに使用されると仮定すると、出力スクリプトまたはツールの「index_3」にする必要があります。
データベースでこの分析を実行するのに役立つ良い方法またはツールはありますか?
前もって感謝します。
sql - SQL Server 監査ログアウトにより、膨大な数の読み取りが発生する
SQL Server Profiler を使用して、どのプロセスが SQL プロセスを消費しているかを調べています。イベント クラスAudit Logout
が膨大な数の読み取りを引き起こし、CPU プロセスを消費していることがわかりました。
それは正常ですか?または、SQL Server の構成に何か問題がありますか?
mysql - ブラックホール エンジンの最適化 / テーブル ロックの問題
BLACKHOLE エンジンを使用してテーブルに多くの行を追加しています。Processlist は、多くのクエリがテーブル ロックを待機していることを示しています。MySQL プロファイラーは、そのテーブルへの INSERT が、DB が過負荷になる最大の原因であることを示しています。すでに列とデータを最適化しています。私は大きなフィールドなどを持っていません。この問題を解決する方法を教えてもらえますか?
sql-server-2005 - 統計がテーブルに与える影響
テーブルにインデックスを追加すると、検索に明らかな利点がありますが、インデックスを更新する必要があるため、insert/update/delete ステートメントに関連するコストもあります。
テーブルに新しい統計を作成すると、インデックスと同様のコストが発生しますか?