8

私は、一般的な共有ホスティング サービスで一連の自己開発アプリケーションを実行しています。許可されたテーブルの静的に構成されたテーブル リストから、D/B メタデータのプレフィックスに基づくテーブルのリストに基づくリストに移動しました。このバージョンをパブリック サービスにプロモートしたところ、リクエストごとのレイテンシが平均2.3 ～ 2.4 秒増加しました。一部のインストルメンテーションは、これが完全に 1 つの SQL クエリにかかっていることを明らかにしました。

SELECT TABLE_NAME AS name
FROM information_schema.tables
WHERE TABLE_SCHEMA = '<DBname>'
AND TABLE_NAME LIKE '<TablePrefix>%';

結果セットの列に明示的に名前を付けたかったので、これを使用しました。ただし、代替クエリを使用してこれをコーディングすると、 2 ミリ秒未満で実行されるコード行が追加されます。

SHOW TABLES LIKE '<TablePrefix>%';

私のサービス プロバイダーは Enterprise MySql 5.0.92-50 を使用しているため、プロファイリングを行うことができません。これは、私の開発環境とプロファイリングできるテスト VM では発生しないため、スケーリングの問題です。何千ものユーザーをサポートするため、ライブ スキーマは非常に大きくなりますが、それでも接続とほとんどのクエリは数ミリ秒しかかかりません。

大規模なマルチユーザー システムでメモリ ベースの information_schema のクエリに時間がかかる理由を知っている人はいますか?

4

2 に答える 2

4

情報スキーマは最適化されておらず、インデックスはなく、メタデータを含むテーブルのみがあり、通常、スキーマからSELECTを実行すると、ファイルが開いて読み取られます。

この記事をご覧ください-INFORMATION_SCHEMAクエリの最適化; 場合によっては、それが役に立ちます。

于 2012-07-02T12:26:37.723 に答える