問題タブ [indexing]

Ganymede CDT を使用して、大規模なコードベースのインデックスを作成しようとしています。これは非常に遅く、C++ ファイルのインデックス作成に一晩かかることもあります。同じプロジェクトは、豊富な ctags 5.7 でインデックス作成に 5 秒しかかかりません。

問題の根本原因を見つけてスピードアップする方法はありますか? たぶん、CDT でのログ記録をオンにするか、または私が見逃したいくつかのあいまいなオプションをオンにしますか?

私はこれをやっていた：

これにより、レイヤーIDの配列が得られ、ループしてそれぞれに対してこれを実行します。

そして、それはすべてうまくいきました。だから今、私はそれを1つのステップでやろうとしているので、これを試します:

しかし、何らかの理由で、メイン クエリのインデックスを使用しませんSELECT DATA etc。したがって、この 1 つの結合されたクエリは、以前に行っていた個別のクエリと比較して、完了するまでにはるかに長い時間がかかります。(ちなみに、サブクエリはSELECT layerID etc引き続きインデックスを使用します)。

「EXPLAIN」ステートメントを使用して、クエリを使用しているかどうかを判断しました。

ownerIDテーブルの列とcollectionID列layers、およびテーブルの列に個別のインデックスがlayerIDありdrawingsます。

クエリのどこが間違っていますか?

行の 90% でインデックス付きのINT列が 0 になる MySQL テーブルがあります。これらの行をNULL0 の代わりに使用するように変更すると、インデックスから除外され、インデックスが約 90% 小さくなりますか?

次のテーブル構造があります

お気づきのとおり、 user_id: date_expired&に重複したインデックスがありますuser_id。もちろん、データが一意であることを確認したいので、一意のインデックスが必要です。

インデックスが重複する理由は、インデックスがないuser_idと、メインの検索クエリに 4 秒かかるためです。追加のインデックスを使用すると、1 秒かかります。クエリは でテーブルを結合しuser_id、チェックしていdate_expiredます。

テーブルには 275 レコードしかありません。

• 同じフィールドに一意のインデックスと通常のインデックスを持つことはどれほど悪いことですか?
• テーブルが純粋に ID である場合、データよりも大きなインデックスを持つことはどれほど悪いことでしょうか?

誰かが私に次の動作が見られる理由を説明できますか:

True と False でインデックスの使用率が異なるのはなぜですか? 具体的には、false の場合、ref 列は NULL であり、余分な列は Using where; インデックスの使用。ただし、実際の場合、ref 列は const であり、余分な列は Using index です。

Sphinx を使用して Web 検索を実行していますが、インデックスの作成中に次のエラー メッセージが表示されます。

警告: sort_hits: merge_block_size=76 kb が低すぎます。mem_limit を増やすとパフォーマンスが向上する可能性があります

問題は、この設定が構成されている場所に関するドキュメントが見つからないことです。私はSphinxのセットアップにある程度精通しているので、設定がどこで構成されているかを知る必要があります。

インデックス用に選択された列は、行を適切に区別する必要があることを読みました。つまり、インデックス列には、同じ値を持つ多数の行が含まれてはなりません。これは、ブール値または性別などの列挙型がインデックスに適していないことを示唆しています。

しかし、性別でユーザーを見つけたいとします。私の特定のデータベースでは、ユーザーの 2% しか女性ではありません。その場合、女性ユーザーを取得するときは性別の列が有用なインデックスになるように思われますが、すべてを取得するときはそうではありません。男性ユーザー。

では、そのような列にインデックスを付けるのは一般的に良い考えでしょうか?

MySQL は外部キー列に自動的にインデックスを付けますか?

他の誰かがロードしたテーブルが存在します。テーブルに対してクエリを実行する必要がありますが、インデックスがないためクエリ プランがうまくいきません。私がしたいのは、特定の列のインデックスがあるかどうかを検出して、存在しない場合は作成し、既に存在する場合は作成しないようにすることです。

ありがとう。

悪の

(これはSQL Server の Floor a date に関連しています。)

DATETIME を無効にする決定論的式は存在しますか? これを計算列の数式として使用すると、次のようになります。

その列にインデックスを配置するとエラーが発生します。

キー列 'EffectiveDate' が非決定論的または不正確であるため、インデックスを作成できません。

ただし、DATEDIFF と DATEADD はどちらも、定義上は決定論的関数です。キャッチはどこですか？出来ますか？