2016-10-01 21 views
0

私はこのようなステージングテーブル持っている:私は、挿入したい最も効率的な方法

CREATE TABLE `final_tbl` (
    `row_id` BIGINT NOT NULL AUTO_INCREMENT, 
    `created_here_at` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    `desc_text` TEXT NOT NULL); 

CREATE TABLE `staging` (
    `created_here_at` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    `desc_text` TEXT NOT NULL); 

そして、先のテーブルをとdesc_textが存在しない場合にのみ、final_tblに書き込む。

  1. チェック、その後desc_text列のSHA224値を格納する「final_tbl」内の列を維持final_tbl
  2. に挿入されていない場合staging.desc_textは、final_tbl.desc_textに存在する場合:私は2つの選択肢を考えています。 staging.desc_textのSHA224の値と最終テーブルのSHA224の列を比較し、挿入するか無視するかを決定します。

どのオプションが高速になるか知りたいですか?

答えて

1

Hmmm。 。 。

create index unq_final_tbl_sha224 on final_tbl(sha224); 

は次に、このようにアップデートを行います:

は、インデックスと、SHA224列を作成します

insert into final_tbl(desc_text, sha224) 
    select * 
    from (select desc_text, sha224 
      from staging s 
      where not exists (select 1 from final_tbl f where f.ssh224 = s.ssh224) 
     ) s 
    where not exists (select 1 from final_tbl f where f.desc_text = s.desc_text); 

サブクエリの背後にある考え方は、MySQLが取得していないことが確実になることですハッシュ値を比較する前にフィールドの長い形式を比較するためのアイデア。サブクエリなしでandを使用するのはおそらく安全ですが、上記はより控えめです。

+0

ありがとうございましたGordonさん、あなたの提案の代わりに、私が "final_tbl(desc_text、sha224)にignoreを挿入すると、desc_text、sha224をステージングから選択"を使用します。 final_tblにレコードを挿入している間、mysqlは最初に一意のキー列をチェックし、 'desc_text'列を比較するのではなく、直後に決定しますか? – abb

+0

@ abb。 。 。同様のことを考えていましたが、同じsha224値を持つ2つの異なる「desc_text」値があると、2番目の文字は挿入されません。そのようなハッシュの衝突は、かなり稀ですが、不可能ではありません。 –

+0

比較的短いMD5であっても、9兆のチャンスが1つしかないので、9兆の文書でそのような誤ったヒットが起こります。 –

1

MySQL 5.7では、生成されたカラムがサポートされています。

desc_textにSHA-512ハッシュフィールドを作成します。

ALTER TABLE final_tbl ADD sha512 AS SHA2(desc_text, 512); 

をし、その上に一意のインデックスを追加:あなたがエラーを取得します重複ハッシュに続いて

ALTER TABLE final_tbl ADD UNIQUE (sha512); 

を:

mysql> insert into final_tbl(desc_text) values('aaa'); 
ERROR 1062 (23000): Duplicate entry 'd6f644b19812e97b5d871658d6d3400ecd4787faeb9b8990c1e7608288664be7' for key 'sha512' 
関連する問題