2017-07-31 7 views
0

私は多能なソースからの結果である断片化されたデータベースを持っていますが、いくつかは共通の列すべてのデータを持っていません。私はソースを基にして、結果のテーブル全体が列char(1)を取得し、すべての値が ''に設定されます。データがインポートされると、まれな例外を除いて読み込まれます。パフォーマンスを念頭に置いてmysql列にnull値または空値を返すのはどうですか?

mysqlに与えられた列に対して常にnullまたは 'result'を返すようにするのがパフォーマンス上の賢明な方法ですか?私はchar(0)をテストしましたが、テーブルスキャンを強制します。列を選択する静的にテーブルのレイアウトを検索する必要はありません(SELECT ''としてip)。結果(IP)で

CREATE TABLE `shard1` (
`id` int(11) NOT NULL, 
`type` varchar(128) NOT NULL DEFAULT '', 
`message` TEXT NOT NULL DEFAULT '', 
`ip` varchar(39) NOT NULL 
PRIMARY KEY (`id`), 
KEY `type` (`type`), 
KEY `ip` (`ip`,`type`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 

結果(IP)なし

CREATE TABLE `shard2` (
    `id` int(11) NOT NULL, 
    `type` varchar(128) NOT NULL DEFAULT '', 
    `message` TEXT NOT NULL DEFAULT '', 
    `ip` char(1) NOT NULL 
    PRIMARY KEY (`id`), 
    KEY `type` (`type`), 
    KEY `ip` (`ip`,`type`) 
    ) ENGINE=MyISAM DEFAULT CHARSET=utf8 

選択は、これは、システムの過度に単純化した表現であり、この

SELECT type,message,ip FROM shard1 WHERE id = 123; 
SELECT message,ip FROM shard1 WHERE ip = '127.0.0.1'; 
SELECT message,ip FROM shard1 WHERE type = 'error' and ip = '127.0.0.1'; 

のような典型的です。最小のシャードテーブルはわずか27行で、最大のものは500m以上の行です。パフォーマンスは現在約0.05秒で受け入れられますが、私は常に物事をより効率的にするのが大好きです。

+0

レコードの内容がそのレコードを参照するロジックと関係しているかどうかわかりません。 '常にnullまたは' 'result'を返す...あなたはこれによって何を意味するかを詳しく説明できますか? –

+0

テーブルの中にはIPアドレスがないものもありますが、ipカラムで検索することができます。ヌルまたは ""の結果がソフトウェアで動作します。 char(0)テストは、mysqlクエリオプティマイザがスマートになり、1つの値しか得られなかったことを知り、テーブルスキャンをスキップすることを期待していました。 –

+0

メッセージを選択するにはNULL ip FROM shard1' –

答えて

0

私は静的な空の文字列を持つビューをipとして使用して、考えられる解決策を見つけました。以前はビューを使用したことはありませんでしたが、オプティマイザはビュー内では十分スマートですが、メインテーブルにはありません。

ビューtestが%何%の「インスタント(0.001秒)でのIP LIKEなくても結果になるだろう」はこの文

SELECT id,type,message,'' as ip FROM shard2 

オプティマイザは、任意の検索を知るのに十分スマートですが、「上に作成されたとしても10mの行テーブルにipのインデックスを付けずにテストしています。

また
SELECT message,ip FROM test WHERE ip LIKE '%1'; 

オプティマイザは、それはそうソフトウェアが効果的に表からは結果を取得していない「WHERE不可能」だ見ている文を説明します。

id select_type  table type possible_keys key  key_len  ref  rows Extra 
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE 

私は毎日何か新しいことを学びます。

+0

偽のニュース。 "不可能なWHERE"は、_EXPLAIN_が 'ip'が' 1'で終わっていないことを発見したことを意味します。 _That_は 'EXPLAIN'中に時間がかかり(テーブルスキャン)、' SELECT'を実行すると時間がかかります(テーブルスキャン)。 –

+0

テーブルで同じクエリを実行すると、ビューを実行すると約6秒かかります。ビューを実行すると、0.00秒です。私は専門家ではないかもしれませんが、私は索引を調べる説明はないと思っています。ここでは、フル・テーブル・スキャンの説明の例を示します(表の944行のみ)。これらのコメントに改行を追加する方法がわからないので、フォーマットが悪い可能性があります。 2回連続で –

+0

を実行し、それを使用してID \t SELECT_TYPE \tテーブル\tタイプ\t possible_keys \tキー\t key_lenに\t REF \t行\tエクストラ\t SIMPLE \t \t db_info ALL \t NULL \t NULL \t NULL \t NULL - 初めて6秒かかるのですか? 2回目はミリ秒だけですか?そうであれば、それは「クエリキャッシュ」の効果です。再び偽のニュース。 –

関連する問題