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

部門間で転送される画像ヘルプデスクチケット。チケットが開いている日ごとに、各チケットの1日の終わりに部門が何であるかを知りたい。テーブルには、営業日ごとの各チケットの最後の部門が含まれ、部門の変更がある（チケットが最初に開かれた日付と閉じられた日付の行を含む）。データテーブルは次のようになります。 CREATE TABLE TicketAssigment ( TicketId INT NOT NULL, AssignedDate DATE NOT NULL, DepartmentId INT NOT NULL); 必要なのは、Dateで順序付けられた前のTicketAssigment行のDepartmentIdを使用して、各TicketIdの欠落している日付を入力することです。 このようなTicketAssigment行がある場合： 1, '1/1/2016', 123 -- Opened 1, '1,4,2016', 456 -- Transferred and closed 2, '1/1/2016', 25 -- Opened 2, '1/2/2016', 52 -- Transferred 2, '1/4/2016', 25 -- Transferred and closed この出力が必要です： 1, …

13 sql-server  sql-server-2012  optimization  date 

SentryOne Plan Explorerは広告どおりに機能しますか？それは合法ですか？気をつけるべきことや心配することはありますか？ SSMSの悪夢のような実行計画の見方と比較して、ホットパスを色で示しているように見えます。 私の懸念は-悪意のあるデータやその他のデータを変更しますか？ 編集：私はそれについて聞いたばかりで、会社について聞いたことがありません。

13 sql-server  query-performance  optimization  execution-plan 

最適化を使用する可能性のあるクエリを識別するために、サーバーで低速クエリロギングを有効にしようとしています。単純に聞こえますが、私のファイルは書き込まれていません。エラーなどは発生しませんが、遅いクエリを記録しているようには見えません。構成を変更した後、mysqlを再起動することを覚えています。 MySQL Ver 5.1.61を使用しています。my.cnfの内容は次のとおりです。 slow-query-log=1 slow-query-log-file=/var/logs/my.slow.log long_query_time=1 ファイル/var/logs/my.slow.logには所有者としてmysqlがあります。これもデバッグのために、ログファイルのすべてに読み取り/書き込みを許可しました。 上記のlong_query_timeが1に設定されているのは、それが機能しているかどうかだけを見たいからです。私はそれを低く設定しようとしました（例えば0.3）が、まだ何も記録されていません。アプリの実行中のクエリには1秒以上かかることがわかってSELECT sleep(10);います。また、テストのためにターミナルで意図的にログクエリ（）を実行しましたが、ログはまだ空です。 私はこれが機能するはずであると私が見ることができるものから、ドキュメントに目を通しました。誰が私が間違っているのかについての提案はありますか？アドバイスをいただければ幸いです。 編集：コメントで尋ねられたように、私はクエリを実行しました： `SELECT variable_value FROM information_schema.global_variables WHERE variable_name IN ('slow_query_log','slow_query_log_file','long_query_time');` 結果： 10.0000000 /var/run/mysqld/mysqld-slow.log OFF これらはデフォルトであると考えているため、明らかに私の構成の変更は考慮されていません。変更しているmy.cnfファイルが、無効な値を入力した場合にmysqlが再起動時にエラーになるように解析されていることは確かです。ここで何が起こっているのでしょうか？ 別の編集： @RolandoMySQLDBAのアドバイスを受けて、遅いクエリ設定行を[mysqld]私の設定の下に移動すると、保存されているようです。上記のvariable_valueクエリの結果は次のとおりです。 1.0000000 /var/logs/my.slow.log ON ただし、ファイルmy.slow.logが書き込まれているのを見ていません。私は、ファイルがmysqlのが所有しているとして、それはアクセス許可の問題だとは思わないし、私は、ファイル上のすべてのユーザーのすべての権限を追加しました。誰もこれが機能しない理由を考えることができますか？ 編集：解決しました！スロークエリログへのパスが間違っていた、/var/log/my.slow.logの代わりに/ var / *ログインしている必要がありますS * / my.slow.logを。助けてくれてありがとう、私は割り当てを学んだ！

13 mysql  optimization  slow-log 

この接続アイテムのサンプルコード バグを示します SELECT COUNT(*) FROM dbo.my_splitter_1('2') L1 INNER JOIN dbo.my_splitter_1('') L2 ON L1.csv_item = L2.csv_item 正しい結果を返します。ただし、次の例では誤った結果が返されます（2014年、新しいCardinality Estimatorを使用） SELECT (SELECT COUNT(*) FROM dbo.my_splitter_1('2') L1 INNER JOIN dbo.my_splitter_1('') L2 ON L1.csv_item = L2.csv_item) L2の結果が共通のサブ式スプールに誤ってロードされ、L1の結果の結果が再生されるためです。 2つのクエリの動作の違いがなぜなのか興味がありました。トレースフラグ8675は、動作search(0) - transaction processingするものが入り、失敗するものが入っていることを示していますsearch(1) - quick plan。 したがって、追加の変換ルールの可用性は動作の違いの背後にあると考えられます（BuildGbApplyまたはGenGbApplySimpleを無効にすると、たとえば修正されるようです）。 しかし、これらの非常によく似たクエリの2つの計画で、異なる最適化フェーズが発生するのはなぜですか？私が読んだことからsearch (0)、少なくとも3つのテーブルが必要であり、最初の例ではその条件は確かに満たされていません。

12 sql-server  optimization  database-internals 

複合WHERE句を含むクエリを作成する場合、たとえば： SELECT * FROM MyTable WHERE BitField = 1 AND VarcharField = 'asdf' また、そのbit比較を含めると、比較で除外されるのと同じフィールドが除外されるだけですvarcharが、そのbitフィールド比較が存在するとパフォーマンスが向上しますか？

12 sql-server  optimization 

クエリパフォーマンスの向上に関するこの質問に続き、デフォルトでインデックスを使用する方法があるかどうかを知りたいと思います。 このクエリは約2.5秒で実行されます。 SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; これは約33msで実行されます。 SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' ORDER BY [DateEntered], [DeviceID]; [ID]フィールド（pk）にクラスター化インデックスがあり、[DateEntered]、[DeviceID]に非クラスター化インデックスがあります。最初のクエリはクラスター化インデックスを使用し、2番目のクエリは非クラスター化インデックスを使用します。私の質問は2つの部分です。 なぜ、両方のクエリに[DateEntered]フィールドにWHERE句があるため、サーバーは2番目ではなく最初のクラスター化インデックスを使用するのですか？ orderbyがなくても、このクエリでデフォルトで非クラスタ化インデックスを使用するにはどうすればよいですか？（または、なぜそのような振る舞いを望まないのでしょうか？）

12 sql-server  sql-server-2008-r2  index  optimization 

SQL Server 2008でストアドプロシージャの記述を始めたばかりで、30以上のパラメーターがあります。10個以上のパラメーターを持つものを書いたことはありません。 コンテキストのために...この手順は、本質的になりますINSERT単一のテーブルに単一の行を。非常によく似たものもあります。やや小さいが; 同じテーブルでUPDATEを実行するバージョン。ほとんどの列は比較的小さく、intと文字列が混在しています（varchar(200)）。 問題は何ですか。良いか悪いか; 多数のパラメーターを含む手順を作成すること、および他のパターンの検討を開始するしきい値はどれくらいですか？

12 sql-server-2008  database-design  performance  optimization 

Microsoftのデータベース開発試験70-433に関する本：Microsoft SQL Server 2008 Database Developmentによると： NOTロジックではなく先頭のワイルドカード文字のいずれも、クエリオプティマイザーがインデックスを使用して検索を最適化することを許可しません。最適なパフォーマンスを得るには、NOTキーワードと先頭のワイルドカード記号を使用しないでください。 することを取った私はそうNOT IN、NOT EXISTSなど さて、このSOの質問に関して、@ GBNが選んだ解決策は上記の声明に違反すると考えました。 どうやら、そうではありません。 だから私の質問は：なぜですか？

12 sql-server  index  optimization 

どちらが速いですか SELECT * FROM X INNER JOIN Y ON x.Record_ID = y.ForignKey_NotIndexed_NotUnique または SELECT * FROM X INNER JOIN Y ON y.ForignKey_NotIndexed_NotUnique = x.Record_ID

12 sql-server  performance  join  optimization 

Postgres初心者はこちら。 このクエリが最適化されているかどうか疑問に思っていますか？100％必要な値だけを結合し、すべての動的条件をWHERE句に残そうとしました。下記参照。 SELECT * FROM myapp_employees JOIN myapp_users ON myapp_users.user_id=myapp_employees.user_id JOIN myapp_contacts_assoc ON myapp_contacts_assoc.user_id=myapp_users.user_id JOIN myapp_contacts ON myapp_contacts.contact_id=myapp_contacts_assoc.contact_id WHERE myapp_contacts.value='test@gmail.com' AND myapp_contacts.type=(1)::INT2 AND myapp_contacts.is_primary=(1)::INT2 AND myapp_contacts.expired_at IS NULL AND myapp_employees.status=(1)::INT2 AND myapp_users.status=(1)::INT2 LIMIT 1; 注：コンテキストについては、このプロシージャはユーザーが従業員でもあるかどうかを確認しています（昇格された特権/別のユーザータイプ）。 とにかく、これは正しい方法ですか？たとえば、JOIN ONには、expired_at IS NULLのチェックなど、より多くのステートメントを含める必要がありますか？なぜ、またはなぜこれが意味をなさないのですか？

12 postgresql  join  optimization 

インスタンスがMAXDOP1に設定されていて、クエリヒントを使用して特定のクエリを並列化できる場合、SQLは並列処理のコストしきい値を使用して、実際に並列化するかどうかを決定しますか？ このリンクはCTFP MAXDOPが1の場合は無視されることを示唆していますが、私はこの特定の情報を掘り下げることができませんでした。これは、クエリのヒントなしでは意味がありませんMAXDOP。 これら2つのリクエストの予想される動作を誰かに教えてもらえますか？ 例1： Instance Maxdop: 1 CTFP: 50 Query hint: Maxdop=2 Query cost: 30 例2： Instance Maxdop: 1 CTFP: 50 Query hint: Maxdop=2 Query cost: 70

11 sql-server  sql-server-2012  optimization  parallelism  maxdop 

PostgreSQL 9.2を使用すると、比較的大きなテーブル（2億を超える行）でクエリが遅くなるという問題が発生します。クレイジーなことは何もしていません。単に歴史的な価値を加えているだけです。以下は、クエリとクエリプランの出力です。 私のテーブルレイアウト： Table "public.energy_energyentry" Column | Type | Modifiers -----------+--------------------------+----------------------------------------------------------------- id | integer | not null default nextval('energy_energyentry_id_seq'::regclass) prop_id | integer | not null timestamp | timestamp with time zone | not null value | double precision | not null Indexes: "energy_energyentry_pkey" PRIMARY KEY, btree (id) "energy_energyentry_prop_id" btree (prop_id) …

11 postgresql  index  optimization  postgresql-performance 

tempdbイベントへの流出（遅いクエリの原因）が発生すると、特定の結合で行の見積もりがずれることがよくあります。マージイベントとハッシュ結合で流出イベントが発生し、ランタイムが3倍から10倍に増えることがよくあります。この質問は、流出事故の可能性を減らすことを前提として、行の見積もりを改善する方法に関係しています。 行の実際の数40k。 このクエリの場合、プランは不適切な行の見積もり（11.3行）を示しています。 select Value from Oav.ValueArray where ObjectId = (select convert(bigint, Value) NodeId from Oav.ValueArray where PropertyId = 3331 and ObjectId = 3540233 and Sequence = 2) and PropertyId = 2840 option (recompile); このクエリの場合、プランは適切な行推定（56k行）を示しています。 declare @a bigint = (select convert(bigint, Value) NodeId from Oav.ValueArray where PropertyId = 3331 and …

11 sql-server  optimization  join 

私が見た中でのドキュメントの違いをcount(*)してcount(pk)。の存在を知らないままcount(pk)（pkはSERIAL PRIMARY KEY）を使用していたcount(*)。 私の質問はPostgresの内部最適化についてです。SERIAL PRIMARY KEYすべての行にa が存在し、偽になることはなく、行をカウントするだけであることをピックアップするのに十分スマートですか？それとも各行に対して冗長な述語チェックを行いますか？これはおそらく無意味な最適化では多すぎると私は同意しますが、私は興味があるだけです。 私はの出力で見ていたEXPLAINとEXPLAIN VERBOSEのためにcount(*)、count(id)そしてcount(id > 50)かどうかを確認するためにEXPLAIN、その出力に述語をチェック述べました。そうではありません。

11 postgresql  optimization  count 

3つのテーブル： product：列あり： ( a, g, ...a_lot_more... ) a: PK, clustered g: bit-column main：列あり： ( c, f, a, b, ...a_lot_more... ) c: PK, clustered f: bit-column (a, b): UQ lookup 列あり： ( a, b, c, i ) (a, b): PK, clustered a: FK to product(a) c: UQ, FK to main(c) i: …

11 mysql  mysql-5.5  optimization