タグ付けされた質問 「performance」

このようなKimberly TrippによるSQL Serverプランのキャッシュに関するいくつかの素晴らしい記事を読んでいます：http : //www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/ 「アドホックワークロード向けに最適化する」オプションさえあるのはなぜですか？これは常にオンにすべきではありませんか？開発者がアドホックSQLを使用しているかどうかに関係なく、それをサポートするすべてのインスタンス（SQL 2008+）でこのオプションを有効にしないのはなぜですか？

49 sql-server  performance  query-performance  memory  cache 

MySQLでvarcharサイズにパフォーマンスの違いはありますか？たとえば、varchar(25)およびvarchar(64000)。そうでない場合、スペースが不足しないようにするために、すべてのvarcharを最大サイズで宣言しない理由がありますか？

45 mysql  performance  datatypes  varchar 

概念的な質問：個々のクエリは結合よりも高速ですか、またはクライアント側で必要なすべての情報を1つの SELECTステートメントに絞り込もうとするか、便利だと思われるだけ使用する必要がありますか？ TL; DR：結合されたクエリに個々のクエリを実行するよりも時間がかかる場合、これは私のせいですか、これは予想されることですか？ まず、データベースに精通していないので、私だけかもしれませんが、複数のテーブルから情報を取得する必要がある場合、個々のテーブルで複数のクエリを使用してこの情報を取得する方が「多くの場合」高速であることに気付きました単純な内部結合を含む）、1つのクエリですべてのデータを取得できる（複雑な）結合クエリを作成しようとするクライアント側でデータをパッチします。 私は非常に単純な例を1つまとめようとしました。 SQLフィドル スキーマのセットアップ： CREATE TABLE MASTER ( ID INT NOT NULL , NAME VARCHAR2(42 CHAR) NOT NULL , CONSTRAINT PK_MASTER PRIMARY KEY (ID) ); CREATE TABLE DATA ( ID INT NOT NULL , MASTER_ID INT NOT NULL , VALUE NUMBER , CONSTRAINT PK_DATA PRIMARY KEY …

44 performance  join  tuning  application-design 

以下を行うメンテナンスプランを継承しました。 古いデータをクリーンアップする DBの整合性をチェックします データベースとトランザクションログのバックアップを実行します インデックスを再編成します 統計の更新 古いバックアップとメンテナンスプランファイルを削除する 23分間のメンテナンスプランのうち、統計の更新には13分間という驚異的な時間がかかります。この13分間、データベースへのアクセスはブロックされます（または、少なくとも、このDBから他のデータベースへのレプリケーションは一時停止されます）。 私の質問は： 統計をいつ更新する必要がありますか？ これは、毎日よりも頻繁に行うべきではないように思えます。私は、不必要なメンテナンスを行うという「理由」の考え方から抜け出そうとしています。

42 sql-server  performance  maintenance  statistics 

私はずっと前にどこかで読んだことがあります。この本は、SQL Serverでネストされたビューを持つことを許可すべきではないと述べています。私たちがそれができない理由がわからないか、間違った記述を覚えているかもしれません。 学生 SELECT studentID, first_name, last_name, SchoolID, ... FROM students CREATE VIEW vw_eligible_student AS SELECT * FROM students WHERE enroll_this_year = 1 先生方 SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers CREATE VIEW vw_eligible_teacher AS SELECT * FROM teachers WHERE HasCert = 1 AND enroll_this_year = 1 学校 CREATE …

42 sql-server  performance  database-design  view 

私はPostgreSQLに積極的にデータベースを自動バキュームさせようとしています。現在、自動バキュームを次のように構成しています。 autovacuum_vacuum_cost_delay = 0＃コストベースのバキュームをオフにする autovacuum_vacuum_cost_limit = 10000＃最大値 autovacuum_vacuum_threshold = 50＃デフォルト値 autovacuum_vacuum_scale_factor = 0.2＃デフォルト値 自動バキュームは、データベースに負荷がかかっていないときにのみ作動することに気付きました。そのため、ライブタプルよりもはるかに多くのデッドタプルが存在する状況に陥ります。例については、添付のスクリーンショットを参照してください。テーブルの1つには23個のライブタプルがありますが、16845個のデッドタプルがバキュームを待っています。それは非常識です！ テスト実行が終了し、データベースサーバーがアイドル状態になると、自動バキュームが開始されます。これは、データベースが既に稼働しているため、デッドタプルの数が20％のライブタプル+ 50を超えるたびに自動バキュームを開始したいので、これは望ましくありません設定済み。サーバーがアイドル状態のときの自動バキュームは、私にとって役に立たない。なぜなら、実稼働サーバーは、サーバーが負荷がかかっている場合でも実行するために自動バキュームが必要な理由で、持続時間にわたって1000更新/秒に達することが予想されるためである。 不足しているものはありますか？サーバーの負荷が高いときに自動バキュームを実行するにはどうすればよいですか？ 更新 これはロックの問題でしょうか？問題の表は、挿入後トリガーを介して移入されるサマリー表です。これらのテーブルはSHARE ROW EXCLUSIVEモードでロックされ、同じ行への同時書き込みを防ぎます。

42 postgresql  performance  performance-testing  vacuum 

SQL Server 2016 Standard Edition 64ビットが、割り当てられた合計メモリの正確に半分（128GBの64GB）で完全に制限されているように見えるという奇妙な問題に遭遇しました。 出力@@VERSIONは次のとおりです。 Microsoft SQL Server 2016（SP1-CU7-GDR）（KB4057119）-13.0.4466.4（X64）2017年12月22日11:25:00 Copyright（c）Microsoft Corporation Standard Edition（64ビット）on Windows Server 2012 R2 Datacenter 6.3（ビルド9600：）（ハイパーバイザー） 出力sys.dm_os_process_memoryは次のとおりです。 クエリを実行するsys.dm_os_performance_countersと、Target Server Memory (KB)がで131072000ありTotal Server Memory (KB)、その半分以下にあることがわかります65308016。ほとんどのシナリオでは、SQL Serverがそれ自体のメモリをさらに割り当てる必要があると判断していないため、これは正常な動作であると理解しています。 ただし、2か月以上にわたって〜64GBで「スタック」しています。この期間中に、一部のデータベースでかなりの量のメモリを消費する操作を実行し、さらに40個近くのデータベースをインスタンスに追加しました。合計292個のデータベースがあり、それぞれに4GBの256 MBの自動成長率の事前割り当て済みデータファイルと、128MBの自動成長率の2GBのログファイルがあります。毎晩12:00 AMにフルバックアップを実行し、月曜日から金曜日の午前6時から午後8時まで、15分間隔でトランザクションログのバックアップを開始します。これらのデータベースは、全体的なスループットが比較的低いですが、SQL Serverが高速化されていないため、何かがおかしいのではないかと疑っています。Target Server Memory 当然、新しいデータベースの追加、通常のクエリの実行、および実行されたメモリ集約型のETLパイプラインを通じて。 SQL Serverインスタンス自体は、12 CPU、144GBのメモリ（SQL Serverに128GB、Windows用に16GBを予約）、および15K SASドライブを備えたvSANの上にある合計4つの仮想ディスクを備えた仮想化（VMware）Windows Server 2012R2サーバーの上にあります。Windowsは、32GBのページファイルがある64GB C：ディスクに自然に配置されます。データファイルは2TBのD：ディスクに、ログファイルは2TBのL：ディスクの上に、tempdbは256GBのT：ディスクに置かれ、8x16GBのファイルは自動拡張されません。 サーバーで実行されているSQL Serverの他のインスタンスが以外にないことを確認しましたMSSQLSERVER。 このサーバーは完全にSQL Serverインスタンス専用であるため、メモリを消費する可能性のある他のアプリケーションやサービスは実行されていません。 分析にはRedGate …

39 sql-server  performance  sql-server-2016  memory  sp-blitz 

TL; DR この質問は引き続き意見を得るので、ここで要約して、新参者が歴史に苦しむ必要がないようにします。 JOIN table t ON t.member = @value1 OR t.member = @value2 -- this is slow as hell JOIN table t ON t.member = COALESCE(@value1, @value2) -- this is blazing fast -- Note that here if @value1 has a value, @value2 is NULL, and vice versa これはすべての人の問題ではないかもしれませんが、ON句の感度を強調することで、正しい方向を見るのに役立ちます。いずれにせよ、元のテキストは将来の人類学者のためにここにあります： 元のテキスト …

39 sql-server  performance 

主にInnoDBテーブルを持つ本番OLTPシステムを想定 システムの調整ミス/構成ミスの一般的な症状は何ですか？ どの設定パラメーターをデフォルトから最もよく変更しますか？ 問題が発生する前に、潜在的なボトルネックをどのように見つけますか？ アクティブな問題をどのように認識してトラブルシューティングしますか？ 特定のstatus変数と診断の詳細を示す逸話をいただければ幸いです。

39 mysql  performance  innodb 

RAMの重要性は確立された事実ですが、MySQLによるCPUの使用に関しては、コアとマルチスレッドの重要性に関する資料はほとんどありません。MySQLを4コア対6コア対8コアなどで実行することの違いについて話しています。 ストレージエンジンによってCPUの使用方法は異なりますか？

38 mysql  performance 

結果セットが大きくなる可能性がある特定のデータベースクエリでパフォーマンスの問題が発生しています。 問題のクエリAND、WHERE句に3つの 句の順序は重要ですか？ 同様に、ASI_EVENT_TIME句を最初に配置すると（すべての句から結果のほとんどが削除されるため）。 それはクエリの実行時間を改善しますか？ クエリ： SELECT DISTINCT activity_seismo_info.* FROM `activity_seismo_info` WHERE activity_seismo_info.ASI_ACTIVITY_ID IS NOT NULL AND activity_seismo_info.ASI_SEISMO_ID IN (43,44,...,259) AND ( activity_seismo_info.ASI_EVENT_TIME>='2011-03-10 00:00:00' AND activity_seismo_info.ASI_EVENT_TIME<='2011-03-17 23:59:59' ) ORDER BY activity_seismo_info.ASI_EVENT_TIME DESC クエリの説明： +----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref …

38 mysql  performance  mysql-5 

Ubuntu 12.04でPG 9.1を使用します。 現在、データベースで次の形式の多数のUPDATEステートメントを実行するのに最大24時間かかります。 UPDATE table SET field1 = constant1, field2 = constant2, ... WHERE id = constid （IDで識別されるオブジェクトのフィールドを上書きしているだけです。）値は外部データソースから取得されます（テーブル内のDBにはまだありません）。 テーブルにはそれぞれ少数のインデックスがあり、外部キー制約はありません。最後までCOMMITは行われません。 pg_dumpデータベース全体をインポートするには2時間かかります。これは、合理的に対象とすべきベースラインのようです。 PostgreSQLのデータセットを何らかの方法で再インポートするカスタムプログラムを作成する以外に、バルクUPDATEパフォーマンスをインポートのパフォーマンスに近づけるためにできることはありますか？（これは、ログ構造化されたマージツリーがうまく処理できると信じている領域ですが、PostgreSQL内でできることはないかと考えています。） いくつかのアイデア： すべての非IDインデックスを削除し、その後再構築しますか？ checkpoint_segmentsを増やしますが、これは実際に長期的なスループットの持続に役立ちますか？ ここで述べたテクニックを使用しますか？（新しいデータをテーブルとしてロードし、新しいデータにIDが見つからない古いデータを「マージ」する） 基本的に試してみることがたくさんありますが、最も効果的なものが何か、他のことを見落としているかどうかはわかりません。今後数日間は実験に費やしますが、ここでも同様に質問すると思いました。 テーブルには同時ロードがありますが、読み取り専用です。

37 postgresql  performance  update  bulk 

SQL Server 2005を使用します。 where句のない巨大なDELETE FROMを実行しています。基本的にTRUNCATE TABLEステートメントと同等です-TRUNCATEの使用が許可されていないことを除きます。問題は、テーブルが巨大である-1000万行であり、完了するまでに1時間以上かかることです。以下なしで高速化する方法はありますか？ 切り捨ての使用 インデックスを無効化または削除しますか？ t-logはすでに別のディスクにあります。 どんな提案も歓迎します！

37 sql-server  performance  delete 

バックグラウンド 私は、約12の異なる「テーブル」を結合および/または左結合するSQL Server 2008 R2に対してクエリを実行しています。データベースはかなり大きく、5000万行を超える多くのテーブルと約300の異なるテーブルがあります。全国に10の倉庫がある大企業向けです。すべての倉庫は、データベースに対して読み取りと書き込みを行います。だから、かなり大きくてかなり忙しい。 私が問題を抱えているクエリは次のようになります： select t1.something, t2.something, etc. from Table1 t1 inner join Table2 t2 on t1.id = t2.t1id left outer join (select * from table 3) t3 on t3.t1id = t1.t1id [etc]... where t1.something = 123 結合の1つが非相関サブクエリ上にあることに注意してください。 問題は、今朝から、システムに変更を加えずに（私または私のチームの誰もが知っている）、クエリの実行に通常約2分かかり、実行に1時間半かかることです。まったく走った。データベースの残りの部分はうまくいっています。私は通常実行するsprocからこのクエリを取り出し、同じスローネスでハードコードされたパラメータ変数を使用してSSMSで実行しました。 奇妙なことに、非相関サブクエリを取得して一時テーブルにスローし、サブクエリの代わりにそれを使用すると、クエリは正常に実行されます。また、このコードをクエリの最後に追加すると、クエリが非常によく実行されます（これは私にとって最も奇妙なことです）。 and t.name like '%' これらの小さな実験から、スローダウンの理由は、SQLのキャッシュされた実行計画の設定方法によるものであると（おそらく間違って）結論付けました-クエリが少し異なる場合、新しい実行計画を作成する必要があります。 私の質問は次のとおりです：高速で実行されていたクエリが深夜に突然遅くなり、このクエリ以外に何も影響を受けない場合、どのようにトラブルシューティングし、今後発生しないようにするのですか？ ？SQLが内部で何をして非常に遅くするかを知るには（悪いクエリが実行された場合、実行計画は取得できますが、実行されません-予想される実行計画が何かを与えるでしょうか？）この問題が実行計画に関連している場合、SQLが本当にくだらない実行計画は良いアイデアだと考えないようにするにはどうすればよいですか？ また、これはパラメータースニッフィングの問題ではありません。SSMSで変数をハードコーディングした場合でも、パフォーマンスが低下するため、これは以前見たことがありますが、そうではありません。

36 sql-server  performance  sql-server-2008 

次のコードを実行すると、22.5分かかり、1億6千万回の読み取りを行います。ただし、内側のselectステートメントだけを実行すると、15秒しかかからず、264kの読み取りが実行されます。補足として、選択クエリはレコードを返しません。 なぜIF EXISTSそれが非常に長く実行され、非常に多くの読み取りを行うのでしょうか？select文も変更しSELECT TOP 1 [dlc].[id]て、2分後に殺しました。 一時的な修正として、count（*）を実行し、その値を変数に割り当てるように変更しました@cnt。次に、IF 0 <> @cntステートメントを実行します。しかしEXISTS、selectステートメントでレコードが返された場合、少なくとも1つのレコードが見つかったらスキャン/シークの実行を停止count(*)し、完全なクエリを完了するため、より良いと思いました。私は何が欠けていますか？ IF EXISTS (SELECT [dlc].[ID] FROM TableDLC [dlc] JOIN TableD [d] ON [d].[ID] = [dlc].[ID] JOIN TableC [c] ON [c].[ID] = [d].[ID2] WHERE [c].[Name] <> [dlc].[Name]) BEGIN <do something> END

35 sql-server  performance  exists