主キーへのインデックスのプロモート

Question

主キーが定義されていないMariaDBデータベースにテーブルがあります。しかし、それはインデックスを持っています。そのインデックスと同じ定義のプライマリキーを追加したいと思います。純粋な方法は：

alter table `foo` add primary key (`bar`, `baz`), 
        drop index `qux`; 

...ですが、それは非常に時間がかかり、無駄に見えます。 （テーブルのサイズは数十ギガバイトで、テーブルの合計サイズよりも空き容量が少ないマシンで実行されています。）インデックスとプライマリキーは同じものではありません。主キーには作成プロセス中にチェックする必要がある一意性制約が含まれています）、主キーを「ブートストラップ」するためにインデックスを使用する方法はありますか？テーブルを想定し

Answer 1

がENGINE=InnoDB ?? ...

テーブルの別のコピー用ディスクに十分な空き領域がない場合で、タスクは、第二のサーバの助けを借りずに行うことはできません。いくつかのテーブルを落とせますか？そうでなければスペースを解放しますか？

PRIMARY KEYはUNIQUEであり、インデックスである。 barとbazの組み合わせが一意でない場合は、PKに変換しないでください。

PKを使用して1行を検索する方が、2次インデックスを使用するよりも高速です。これは、最初にセカンダリインデックスのBTreeの行を検索するためです。そこで、PRIMARY KEYが見つかり、データのBTreeの行を見つけるために使用されます。

テーブルがinnodb_buffer_pool_sizeより大きい場合、変更によっても（多くの場合）ディスクヒットがなくなります。 （ディスクヒットはデータベース操作の中で最も遅い部分です）

はい、現在、あなたのテーブルにはPRIMARY KEYがあります。それは6バイトの隠れた「列」です。あなたのALTERはそれを捨てて、テーブルを少し小さくします（別の小さなメリット）。

innodb_file_per_table=ON（または= 1）をお持ちですか？テーブルが独自の.ibdファイルにある場合は、操作後にディスクスペースをリカバリします（まったく実行できると仮定して）。 OFFを指定すると、ibdata1ファイルのサイズは大きくなりますが、ファイルサイズは縮小されません。 最終的に 'ビッグ'になるテーブルを作成するときにはONになります。

OK、そこには、が希望です。 OFF、およびで実行している場合は、十分な空き領域がibdata1にある場合は、タスクが完了することがあります。 （しかし、それはあなたがすでにibdata1を膨らませていることを意味しています。）