Q&A
ご回答有り難うございます！
> むしろ、他と重複する例が少ない列にこそ、インデックスは効力を発揮します
こちら私の理解間違いでした。
似たようなデータで索引を作っているイメージだったので、1件ずつ違ったデータが入っている場合はあまり効かないイメージだったのですが、違うのですね…
環境
MySQL5.7
知りたいこと概要
- MySQLで、varchar型（テキストを入れるカラム）にindexを貼るのはOKか？
- 対象のカラムがメールアドレスである場合、indexは意味を成すのか？
- どのような点に注意してindexを貼るべきなのか？
知りたいこと詳細
今回新しくテーブルを設計するにあたり、where句で使うのが主にメールアドレス（文字列）のカラムになってしましました。
uniqueにすればいいとは思うのですが、
退会→再登録
などのときに、unique制約だとエラーになってしまいます。
なので、できればindexを使いたいと考えているのですが、
メールアドレスは他と重複するものがありません。
なので、indexを貼ってもあまり意味がないように思えます。
なにか案がございましたら、ご教示いただけますと幸いです。
よろしくお願いいたします
回答3件
0
メールアドレスは他と重複するものがありません。
なので、indexを貼ってもあまり意味がないように思えます。
「他と重複するもの」とは他の項目と組み合わせた複合インデックスにはならないという意味ですか？
仮にそうであっても、メールアドレスはカーディナリティが高いものですから、効果はあるでしょう。
投稿2019/05/13 07:30
総合スコア25173
0
メールアドレスは他と重複するものがありません。
なので、indexを貼ってもあまり意味がないように思えます。
なぜそう思われたのでしょうか。
むしろ、他と重複する例が少ない列にこそ、インデックスは効力を発揮します（メールアドレスを完全一致で検索する場合など、まさにぴったりです）。逆に「男/女」のような「入る値が少なく、しかも均等に分かれている」ような場合、インデックスを使ってもあまり絞り込めない（カーディナリティが低い）ので、こちらのほうが役に立ちません。
投稿2019/05/13 07:27
総合スコア145183
0
ベストアンサー
重複するものがありません。
なので、indexを貼ってもあまり意味がないように思えます。
そんなことはないでしょう。
constにヒットしたときの効率はずば抜けたパフォーマンスになります
退会→再登録
などのときに、unique制約だとエラーになってしまいます。
退会フラグカラムをつくっておいて
メールアドレスと退会フラグの複数列に渡るuniqueインデックスにすると
ご希望にそうかもしれません。
投稿2019/05/13 07:27
総合スコア114769
ご回答有り難うございます。
> そんなことはないでしょう。
> constにヒットしたときの効率はずば抜けたパフォーマンスになります
こちら私の完全なる理解の間違いでした。
> 退会フラグカラムをつくっておいて
> メールアドレスと退会フラグの複数列に渡るuniqueインデックスにする
なるほど、確かにunique indexを複数まとめたカラムで設定するとできそうですね！
ただ、2回目の退会ができなくなりそうですので、その辺考えないといけなさそう…
> 2回目の退会ができなくなりそう
これは運用の問題なので微妙です
複数回退会でき、それを保持したいのであれば、フラグをカウントアップすることでなんとかなるかも
前々回の退会情報を保持する必要がなければ0/1で処理すれば良いと思います（退会情報は上書き）
ご返信有難うございます。
> これは運用の問題なので微妙です
なるほど……
> 複数回退会でき、それを保持したいのであれば、フラグをカウントアップすることでなんとかなるかも
ふむ……頂いたご回答から、「メールアドレス」と「退会日時」でunique indexを貼ろうかと思っていたのですが…
カウントアップのほうが良いのでしょうか？
退会日時があるならフラグの代わりにつかえるでしょう
（そもそも退会情報が拾えるならフラグ自体が不要になってくる）
当初はnullなのでしょうけど、nullは検索効率が悪いので
1970-01-01など過去日にしておくほうがよいかもしれません
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/05/13 07:35
2019/05/13 07:39 編集