ベースの統合スクリプトの開発が可能になっています。リソースを消費します。ユーザが、高速かつ効率的に複雑なフィルタを作成する方法を理解できるようにすることです。適切に作成されたフィルタのほとんどは一瞬で完了します。同じデータを返すような非効率的なフィルタは時間がかかり、完了まで数分かかることもあります。フィルタのパフォーマンスを最適化するには、次のように操作することをお勧めします。データベースがロードおよび処理する必要のあるテーブル行の数を最小限に抑えます。エンティティのテーブルの列でフィルタを使用するのが最も効率的です。テキスト一致フィルタは、低速であり、同じ目的に対して自身で使用できないため、使うのを避けます。フィルタの例は、次のような理由で動作が低速です。with)など)であるため、データベースを評価する速度が低下します。これらのテキスト一致フィルタに照らしてチェックする必要のあるバージョンの数が膨大で、すべてのバージョンが対象になります。フィールドを対象にしているため、データベースがフィルタの評価のために他のテーブルからデータを取得する必要があります。テーブルは最も高速で拡大することが多いテーブルであるため、このフィルタの速度は時間が経つにつれて徐々に低下します。複雑なフィルタのパフォーマンスを向上させるためには、検討対象から多くのバージョンを効率的に除外できるフィルタを追加します。これにより、多数のバージョンに関して低速のテキスト一致クエリーを評価する必要がなくなります。ユーザに最適なフィルタはワークフローによって異なります。フィルタに大きく依存する場合は、バージョンまたは他のエンティティを効率的にフィルタできるようにワークフローを微調整する必要があります。フィールドの活用があります。グループを追加しています。つのフィルタによりスタジオの大部分のバージョンが除外されることで、この複雑なフィルタが改善されます。フィールドを使用する低速なフィルタを評価するバージョンはかなり少なくなります。[が次と等しい](is)フィルタを使用してプロジェクトを明示的に制限しています。これにより、これにあてはまらない過去と現在のすべてのプロジェクトからすべてのバージョンが効率的に除外されるため、スタジオに多くのプロジェクトがある場合は大きな違いが生まれます。編集バージョンを収集するため、プロジェクトが最新の状態になるようにワークフローの変更が必要になることがあります。プラクティス」になります。ページをフィルタして、関連する少数の新しいバージョンのみを簡単に表示できます。コンテンツを効率的にフィルタして減らすのに便利です。テキスト一致フィルタが低速であるテキスト一致フィルタが低速な理由は、結果の一部を含む可能性のある各テーブル行に対してデータベースが複雑なテストを実行する必要があるためです。タイプに利用できる最適化の方法はありません。目のガイドラインです。以下で詳しく検討します)。このように他のフィルタを使用すると、テキスト一致フィルタが適用されるテーブル行が減るため、リソースの消費も少なくなります。次に、基本的に低速なテキスト一致フィルタを示します。次を含む(contains)が次を含まない(not_contains)が次で始まる(starts_with)が次で終わる(ends_with)の名前に次が含まれる(name_contains)の名前に次が含まれない(name_not_contains)次の場合、テキスト一致クエリーは特に低速になります。タイプを使用する複雑なフィルタよりも、何百倍または何千倍も遅くなる可能性があります。スクリプトでテキスト一致フィルタを使用していてパフォーマンスが不足している場合は、「統合アプローチを変更してテキスト一致を回避する」のセクションを参照することをお勧めします。エンティティの独自フィールドで機能するシンプルで効率的なフィルタを使用して返されるエンティティ数を削減するこれは、複雑なフィルタのパフォーマンスを向上する上で最も重要な原則です。エンティティの独自フィールドで効率的にフィルタを実行すると、データベースは検討対象からエンティティの大部分のテーブル行をすばやく除外できます。したがって、それ以降の手順でデータベースが処理するデータが少なくなります。その結果、他のフィルタ、ソート、またはグループ化など、複雑なフィルタの残りすべての処理が高速化するというメリットが生まれます。フォーマットとネットワークのリソース消費が少なくなり、さらにパフォーマンスが向上します。効率的に「絞り込む」フィルタを使用すると、検討対象のエンティティ数を大幅に削減できる。個のバージョンしか含まれないプロジェクトをフィルタするほうが効率的です。万個のバージョンが含まれる場合、パフォーマンスが向上する可能性はありません。グループに含まれる必要がある。次の例では、「entity」に対するフィルタで行が適切に削減されています。グループ内に含まれないようにしてください。次の例では、「entity」に対するフィルタにより、パフォーマンスが向上しない可能性があります。グループに含まれるフィルタは、必ずしもすべてのテーブル行に適用されないため、検討対象の行数が確実に削減されるわけではありません。(例外については、以下の「高度なパフォーマンス」セクションを参照してください。フィールドにフィルタを適用すると、データベースが別のエンティティのテーブルの行を検索および評価する必要があるため、行をすばやく除外できません。フィールドに対するフィルタが必要な場合は、行を効率的に除外するために、エンティティ自身に属するフィールドに対する追加のフィルタも使用してください。(例外については、以下の「高度なパフォーマンス」セクションを参照してください。フィールドと似ているため高速ではありません。テーブルから行を効率的に除外できません。フィールドにフィルタを適用することに何も問題はありませんが、パフォーマンスを向上するため、エンティティ数を効率的に削減できるフィルタを追加する必要があります。フィールドは高速で、効率的な「絞り込み」フィルタになります。テーブルに属しているためです。テキスト一致フィルタは低速で、データベースで適切に最適化できません。タイプは、フィルタが膨大な数の行を除外する限り、比較的効率的に動作します。次に、多くのバージョンを含むサイトではパフォーマンスが不足する可能性のあるフィルタを示します。}]行を除外できる可能性がある明確な方法は、プロジェクトまたは日付の範囲を制限することです。次に、両方の場合を試した例を示します。(「いずれか」)フィルタです。グループ外になるようにしてください。インデックスのメリット一部のフィールドはデータベースにインデックス化されているため、特に効率的なフィルタリングを提供できます。インデックスを参照して、検討対象の行を特定できます。ガイドラインに従わない限り、効果はまったくありません。目的は処理する行の数を効率的に削減することで、インデックス化されたフィールドを使用すると便利です。データベースのインデックス化により、データベースからの読み込みのパフォーマンスは向上しますが、書き込みごとにインデックスを更新する必要があるため、データベースへの書き込み速度は低下します。すべてのテーブルのすべてのフィールドをインデックス化するわけではありません。次の共通フィールドをインデックス化します。than)など、上記のフィールドのいずれかを使用する肯定的なフィルタは、インデックス化されていないフィールドのフィルタよりもかなり迅速に検討対象から行を除外することで、パフォーマンスが大幅に向上する場合があります。not)などの否定的なフィルタは、データベースによるインデックスの使用を通常は許可していません。否定的なフィルタが処理の必要な行数を大幅に削減する限り、パフォーマンスの向上に役立ちます。データベースで非常に高速に動作します。データベースは複雑なヒューリスティックと統計情報を使用し、インデックスを適用するタイミングと使用するインデックスを決定するためにインデックスごとに保持されます。その結果、インデックス化されたこのフィールドのいずれかでフィルタを使用すると、パフォーマンス向上のタイミングを予想するのが難しくなります。そのため、必ずしもインデックス化されたフィールドに対するフィルタでなくても、検討対象の行数を大幅に削減する効率的なフィルタを提供することが重要です。インデックス化されたフィールドの使用に余分な手間をかけないでください。実際は手元の状況に適していない可能性があります。フィールドは、他のテーブルの行を評価するためにオーバーヘッドが少し追加されますが、特に低速なわけではありません。フィールドに他のフィルタを適用できる可能性があります。フィールドでフィルタ、ソート、またはグループ化を実行するたびに、複雑なフィルタに大幅なコストが追加されます。フィールドは多くのテーブルの行を評価する必要があるため、さらに大きな影響があります。フィールドのフィルタに大きく依存している場合、制作活動の増加に合わせてその統合を拡大できない可能性があります。エンティティ自身に属するフィールドの完全一致に依存する手法を探す必要があります。いくらかの作業が必要になったとしても、効果が得られます。フィールドの追加や設定が必要になる場合があります。フィルタの例を示します。制限するなど、このフィルタを制限できる可能性は数多くあります。スクリプトまたは他の方法で常に設定される)を追加すると、パフォーマンスが向上します。Subtype」と呼ばれるフィールドを使用すると、フィルタは次のようになります。非常に多く存在する場合はフィルタが低速になる可能性がありますが、以前のテキスト一致バージョンよりもはるかに高速になります。(「~のいずれか」)フィルタによってパフォーマンスが向上する理由が分からない場合は、以下の「高度なパフォーマンス」セクションを参照してください。グループでいくつかのフィルタを組み合わせると、テーブル行が効率的に除外されるため、複雑なフィルタのパフォーマンスが十分に向上します。これは、特定のフィルタとそのフィルタによりテーブル行がどれだけ除外されるかに応じて異なります。上記の「統合アプローチを変更してテキスト一致を回避する」セクションの例を参照してください。フィールドでフィルタを使用すると、適切な結果が得られることがあります。タイプを指定するためです。テーブルのほとんどの行を除外できます。フィールドには適用されません。次に、タスクのフィルタ例を示します。]]たとえば、「エンティティ」フィールドにシーケンスが格納されたタスクが非常に少ない場合、上記のタスク用のフィルタが実際は適切に動作することがあります。これは、エンティティ列にシーケンスが格納された、少数のタスク行しか処理されないためです。一方で、何百万ものタスクがシーケンスにリンクされている場合は、この数百万ものタスク行を処理する必要があるため、これらのフィルタのパフォーマンスは低下します。プラクティスのチェックリスト」を参照してください。チームとつながりましょう。オートデスクのソフトウェアを今までにないクリエイティブな方法で活用しているお客様は、ぜひ体験談をお寄せください。reserved.使用条件プライバシー/クッキ。