primary key に文字列を使う場合のパフォーマンスについて

Question

Athena(S3)上に

{
user_id: varchar(24)
column1: ...
column2: ...
:
}

のようなデータが有ってこれを MySQL で使うためにインポートしたいのですが

 CREATE TABLE test1 (
    id int AUTO_INCREMENT NOT NULL PRIMARY KEY,
    user_id nchar(24),
      :
    UNIQUE (user_id)
  )

というような Rails で使いやすいように PK を int にしたテーブルを作ったところ
上長にパフォーマンスに問題がなければテーブルの型は同じにしてくれといわれて
(id が複数あるとまぎらわしいらしい）

 CREATE TABLE test2 (
    user_id nchar(24) PRIMARY KEY,
    :
  )

という形式で作り直したところインポート時間が著しく悪化します
(数十万件のレコードのバルクインサートが数秒だったのが数十秒かかるようになります…)

PK を int から 24 文字の文字列にしただけでここまでパフォーマンスがおちるものなのでしょうか
前者はカラムを追加してかつもとの user_id にも UNIQUE index を作成しているのに
後者のほうが遅い理由がよくわかりません

それとも create 文の書き方が悪いのでしょうか

Answer 1

8.2.1.7 インデックス拡張の使用

InnoDB は、自動的に各セカンダリインデックスに主キーカラムを追加して、それを拡張します。

---

PK を int から 24 文字の文字列にしただけでここまでパフォーマンスがおちるものなのでしょうか
前者はカラムを追加してかつもとの user_id にも UNIQUE index を作成しているのに
後者のほうが遅い理由がよくわかりません

UNIQUE indexはセカンダリインデックスとして作成されるので、利用されるのはプライマリーインデックスです。
なので、UNIQUE indexの有無よりは、プライマリーインデックスを作成する場合の、項目属性の違いが大きく影響しています。

Comments

[退会済みユーザー]

そうなのですね
ありがとうございました！

Answer 2

PK を int から 24 文字の文字列にしただけでここまでパフォーマンスがおちるものなのでしょうか

目の前にパフォーマンスが落ちている事実があるのに、何を疑問に思われているのかよくわかりませんが…データサイズがぜんぜん違うので、そりゃ落ちますよね。

MySQLのプライマリーキーの型指定

１件あたりの処理に数ミリ秒パフォーマンス低下であっても、それを数十万回積み重ねるわけで、感覚的には数秒が数十秒ならマシな方、ぐらいに感じます。

Comments

[退会済みユーザー]

回答ありがとうございました！

MySQL に詳しい上長がPKを文字列にするかINTにするかなんてパフォーマンスに影響なんてあたえない
書き方が間違ってるだけだから実行計画をみて調べてみろっていわれるだけで
実際遅くなってるんですがどこが悪いのかわからなかったので質問させていただきました