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

免責事項：データベースの内部に関する知識が不足していることをお許しください。ここに行く： データベースの定期的なクリーンアップジョブで大きなパフォーマンスの問題があるアプリケーション（私たちが作成したものではありません）を実行します。クエリは次のようになります。 delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); わかりやすく、読みやすく、標準SQL。しかし、残念ながら非常に遅いです。クエリを説明すると、既存のインデックスVARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_IDが使用されていないことがわかります。 mysql> explain delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( -> select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY -> where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); | id | select_type | table | type | possible_keys | key | …

9 mysql  index  join  delete  optimization 

私のアプリでは、dbとアプリの間の往復回数が減ったという理由だけで、可能な場合は複数行の挿入を行います。 しかし、気になったのですが、他にメリットはありますか？たとえば、次のように複数の行が一度に挿入された場合： insert into tbl (c1, c2) values (v1, v2) (v3, v4) 対： insert into tbl (c1, c2) values (v1, v2) insert into tbl (c1, c2) values (v3, v4) テーブルにインデックスがありますが、最初のケースではインデックスが1回計算され、2番目のケースでは2回計算されますか？それとも、挿入ごとに常に1回ですか？両方のクエリが同じトランザクションにあると仮定します。 PostgreSQLを使用しています。

9 postgresql  index  optimization 

やや複雑なSQL Server 2008クエリ（約200行のかなり高密度のSQL）があり、必要なときに実行されませんでした。時間の経過とともに、パフォーマンスは約0.5秒から約2秒に低下しました。 実行計画を見ると、結合を並べ替えることでパフォーマンスが向上することは明らかでした。私はそうしました、そしてそれは...約0.3秒にまで減少しました。これで、クエリに「OPTION FORCE ORDER」というヒントが追加されました。 今日、私はデータベースをクリーンアップします。行の約20％をアーカイブし、行を削除する以外は関連するデータベースでアクションを実行しません...実行プランは完全にホースされます。特定のサブツリーが返す行数を完全に誤って判断し、（たとえば）次のものを置き換えます。 <Hash> と <NestedLoops Optimized='false' WithUnorderedPrefetch='true'> これで、クエリ時間が約0.3秒から約18秒に急上昇します。（！）行を削除したからといって。クエリヒントを削除すると、クエリ時間は約2秒に戻ります。良いが悪い。 データベースを複数の場所とサーバーに復元した後、問題を再現しました。各テーブルから行の約20％を削除するだけで、常にこの問題が発生します。 強制結合順序がクエリの見積もりを完全に不正確にする（したがってクエリの時間を予測できない）のは、これが正常ですか？ 最適ではないクエリのパフォーマンスを受け入れる必要があるか、それともタカのように見て、頻繁に手動でクエリのヒントを編集する必要があると思いますか？または、すべての結合についてもヒントがありますか？.3sから2sは大ヒットです。 行を削除した後にオプティマイザが停止した理由は明らかですか？たとえば、「はい、サンプルスキャンを実行しました。データ履歴の前半でほとんどの行をアーカイブしたため、サンプルはスパースな結果を生成したため、ソートされたハッシュ演算の必要性を過小評価していました」 実行計画を見たい場合は、投稿できる場所を提案してください。そうでなければ、私は最も素晴らしいビットをサンプリングしました。これが根本的な誤推定です。括弧内の数字は（推定：実際の）行です。 / Clustered Index Scan (908:7229) Nested Loops (Inner Join) --< \ NonClustered Index Seek (1:7229) 内部ループは908行をスキャンすると予想されますが、代わりに52,258,441をスキャンすることに注意してください。正確であれば、このブランチは12秒ではなく、約2ミリ秒で実行されたはずです。行を削除する前に、この内部結合の推定は合計係数2だけオフであり、2つのクラスター化インデックスのハッシュ一致として実行されました。

9 sql-server  sql-server-2008  query-performance  optimization  hints 

次のようなクエリがあります。 SELECT col1 FROM MyTable WHERE DATEADD(dd, 0, DATEDIFF(dd, 0, GETDATE())) BETWEEN col2 AND col3 ; これにより、次のような実行プランのツールチップが表示されます。 dateadd求める述語の一部は、クエリ内のすべての行に対して実行されますか？または、SQL Serverはクエリ全体の値を1回計算しますか？

9 sql-server  sql-server-2008  sql-server-2008-r2  optimization 

たとえば、テーブルがあるとします。 Business(BusinessID, Lattitude, Longitude) もちろん、すべてに索引が付けられています。また、100万件のレコードがあります たとえば、106,5に最も近いビジネスを検索したい場合、どうすればよいでしょうか。 私が行った場合 SELECT * FROM Business WHERE (Some formula to compute distance here) < 2000 たとえば、または私が行う場合 SELECT * FROM Business TOP 20 理論的には、コンピューターはすべてのビジネスの距離を計算する必要がありますが、実際には、緯度と経度が特定の範囲内にあり、計算する必要があるビジネスのみが計算されます。 たとえば、PhPやSQLでやりたいことはどのようにしたらよいでしょうか。 これまでの答えに感謝しています。私はmysqlを使用していますが、それらには明らかな解決策よりも効率的なものはありません。MySQL空間には、距離計算機能もありません。

9 optimization  mysql-5.5  relational-theory  spatial 

OPTIMIZE TABLE tbl_nameMySQLサーバーでクエリを実行することで得られる利点（実際に実用的）を教えてください。 これを一度確認したところ、これを実行した後、フラグメントの再配置などが原因で次のDBヒットに時間がかかる可能性があることがわかりましたが、その後のヒットではパフォーマンスが表示され、クエリキャッシュがこのトリックを実行するかどうかわかりません最適化または最適化のみでこのトリックを行います。 MySQLでの作業が私たちのプロジェクトで重要性を増しているので、可能であれば、実際のパフォーマンスの差の値を誰かがガイドしてくれますか？

9 mysql  optimization 

クエリの実行に非常に長い時間（15秒以上）を要するクエリがあり、データセットが大きくなるにつれて、時間の経過とともに悪化します。私は過去にこれを最適化し、インデックス、コードレベルの並べ替え、その他の最適化を追加しましたが、さらに改良する必要があります。 SELECT sounds.*, avg(ratings.rating) AS avg_rating, count(ratings.rating) AS votes FROM `sounds` INNER JOIN ratings ON sounds.id = ratings.rateable_id WHERE (ratings.rateable_type = 'Sound' AND sounds.blacklisted = false AND sounds.ready_for_deployment = true AND sounds.deployed = true AND sounds.type = "Sound" AND sounds.created_at > "2011-03-26 21:25:49") GROUP BY ratings.rateable_id クエリの目的はsound id、最新のリリースされたサウンドのと平均評価を取得することです。約1500の音と200万の評価があります。 私はいくつかの指標を持っています sounds …

9 mysql  performance  index  optimization 

インデックスの「パディング」の量をどのようにして知ることができますか？

9 sql-server-2008  index  optimization  index-tuning  fill-factor 

2つの非常によく似たクエリがあります 最初のクエリ： SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' and a.TargetTypeId IN (1,2,3,4,5,6,7,8,9, 11,12,13,14,15,16,17,18,19, 21,22,23,24,25,26,27,28,29,30, 31,32,33,34,35,36,37,38,39, 41,42,43,44,45,46,47,48,49, 51,52,53,54,55,56,57,58,59, 61,62,63,64,65,66,67,68,69, 71,72,73,74,75,76,77,78,79) 結果：267479 計画：https : //www.brentozar.com/pastetheplan/?id=BJWTtILyS 2番目のクエリ： SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' …

9 sql-server  performance  query-performance  optimization  execution-plan 

SQL Server 2017実行プランでこの警告を見てきました： 警告：操作によりIOが残りました[sic]。実際に読み取られた行数は（3,321,318）でしたが、返された行数は40でした。 SQLSentry PlanExplorerからのスニペットは次のとおりです。 コードを改善するために、SQL Serverが関連する行にアクセスできるように、非クラスター化インデックスを追加しました。これは正常に機能しますが、通常は（大きな）列が多すぎてインデックスに含めることができません。次のようになります。 インデックスのみを追加し、列を含めない場合、次のようになります。インデックスを強制的に使用すると、 明らかに、SQL Serverは、キールックアップは残りのI / Oよりもはるかにコストがかかると考えています。（まだ）多くのテストデータを含まないテストセットアップがありますが、コードが運用環境に入ると、より多くのデータを処理する必要があるため、何らかの非クラスター化インデックスが必要だとかなり確信しています。 SSDで実行する場合、キールックアップは本当に高価ですが、私は（多くのインクルード列を含む）全脂肪インデックスを作成する必要がありますか？ 実行計画： https : //www.brentozar.com/pastetheplan/?id=SJtiRte2Xこれは、長いストアドプロシージャの一部です。を探しIX_BatchNo_DeviceNo_CreatedUTCます。

9 sql-server  optimization  execution-plan  sql-server-2017  nonclustered-index 

これに関する決定的なリソースをどこでも見つけるのに苦労しているので、グルがここで答えを出してくれるといいのですが。 列を追加する必要がある非常に大きなテーブルがあります。クラスタ化インデックスはかなり高度に断片化されておりALTER INDEX REBUILD、クリーンアップするために実行したいと思います。 また、通常はALTER TABLE REBUILD列を変更するときにも行います。これにより、その操作からのポインターまたは分割がクリーンアップされるためです。 クラスター化インデックス（基本的にはテーブル）について話しているので、両方を実行する必要がありますか？ 私の疑いは、ALTER INDEX REBUILDクラスター化された意志が意志のすべてを更新するわけではないALTER TABLEことですがALTER TABLE、インデックスの断片化がクリーンアップされないことも心配です。

9 sql-server  sql-server-2008-r2  optimization  fragmentation 

ツリー構造で再帰CTEを使用して、ツリー内の特定のノードのすべての子孫をリストしています。WHERE句にリテラルノード値を書き込むと、SQL Serverは実際にその値にのみCTEを適用し、実際の行数が少ないクエリプランなどを提供します。 ただし、値をパラメーターとして渡すと、CTEが実現（スプール）され、事実の後でフィルター処理されるようです。 私は計画を間違って読んでいた可能性があります。パフォーマンスの問題には気づきませんでしたが、CTEの実現により、特にビジーなシステムでは、より大きなデータセットで問題が発生する可能性があると心配しています。また、私は通常、このトラバーサルをそれ自体で複合します。祖先までトラバースし、子孫まで戻ります（すべての関連ノードを確実に収集するため）。私のデータが原因で、「関連」ノードの各セットはかなり小さいため、CTEの実現は意味がありません。また、SQL ServerがCTEを実現しているように見える場合、その「実際の」数には非常に多くの数値が含まれています。 クエリのパラメーター化されたバージョンをリテラルバージョンのように機能させる方法はありますか？CTEを再利用可能なビューにしたいと考えています。 リテラルを使用したクエリ： CREATE PROCEDURE #c AS BEGIN; WITH descendants AS (SELECT t.ParentId Id ,t.Id DescendantId FROM #tree t WHERE t.ParentId IS NOT NULL UNION ALL SELECT d.Id ,t.Id DescendantId FROM descendants d JOIN #tree t ON d.DescendantId = t.ParentId) SELECT d.* FROM descendants d WHERE …

8 sql-server  optimization  execution-plan  cte  recursive 

Microsoftはファイル数と並列処理に関してクエリオプティマイザーを変更しましたか？オプティマイザは、クエリの並列度を決定するためにファイル数を考慮しなくなりましたか？もしそうなら、誰がいつ変更が行われたか知っていますか？そうでない場合、そのトピックについて説明しているMicrosoftのドキュメント（SQL Server 2014または2016の現在のドキュメント）へのリンクを誰かが提供できますか？

8 sql-server  sql-server-2014  optimization  parallelism 

同じテーブル値関数（TVF）が20列で呼び出されるクエリを調整しようとしています。 最初に行ったのは、スカラー関数をインラインテーブル値関数に変換することでした。 CROSS APPLYクエリの複数の列で同じ関数を実行するために最高のパフォーマンスを発揮する方法を使用していますか？ 単純な例： SELECT Col1 = A.val ,Col2 = B.val ,Col3 = C.val --do the same for other 17 columns ,Col21 ,Col22 ,Col23 FROM t CROSS APPLY dbo.function1(Col1) A CROSS APPLY dbo.function1(Col2) B CROSS APPLY dbo.function1(Col3) C --do the same for other 17 columns より良い代替案はありますか？ X個の列に対して複数のクエリで同じ関数を呼び出すことができます。 これが関数です： CREATE …

8 sql-server  query-performance  optimization  sql-server-2016  functions 

式SQLite3を使用して（3.18）でインデックスを作成しようとしていますjson_extract。私の目的は、結果を生成するためにインデックスのみを必要とするクエリを実行することです。これは、json_extract大きなデータセットや値を操作するときにパフォーマンスを低下させる高価な操作であるためです。私は自分のニーズに合うカバリングインデックスが必要だと結論しました。 ステップ1-通常のテーブル構造を使用して理論をテストする CREATE TABLE Player ( Id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, FirstName TEXT NOT NULL, MiddleName TEXT, LastName TEXT NOT NULL ); CREATE INDEX Player_FirstName ON Player ( FirstName ASC, LastName ASC ); EXPLAIN QUERY PLAN SELECT FirstName, LastName FROM Player WHERE LENGTH(LastName) > 10 ORDER BY FirstName …

8 index  optimization  execution-plan  sqlite