Skip to content

refactor: 이메일 유니크키 제거 #525

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Gyuhyeok99 merged 1 commit into from
Oct 8, 2025
Merged

refactor: 이메일 유니크키 제거 #525

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/main/resources/db/migration/V33__drop_site_user_email_unique.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
ALTER TABLE site_user DROP KEY site_user_email_unique;
Copy link

@coderabbitai coderabbitai bot Oct 4, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

중복 키 제거 후 일반 인덱스를 추가해 주세요. 이메일로 사용자 조회가 빈번한 서비스 특성상, 유니크 키를 삭제하면 해당 컬럼의 인덱스 자체가 사라져 쿼리 성능이 급격히 떨어질 수 있어요. DROP 뒤에 동일 컬럼으로 일반 인덱스를 생성해 주시면 성능 저하를 예방할 수 있겠습니다.

 ALTER TABLE site_user DROP KEY site_user_email_unique;
+CREATE INDEX idx_site_user_email ON site_user (email);
🤖 Prompt for AI Agents 
In src/main/resources/db/migration/V33__drop_site_user_email_unique.sql around
lines 1 to 1, after dropping the unique key you must create a non-unique index
on the same email column to avoid query performance degradation; modify the
migration so that immediately after ALTER TABLE site_user DROP KEY
site_user_email_unique; you add a CREATE INDEX (e.g., CREATE INDEX
idx_site_user_email ON site_user(email);) ensuring the index is non-unique and
uses the same column name.

Copy link
Contributor Author

@Gyuhyeok99 Gyuhyeok99 Oct 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

유니크 특정이 email + authType으로 되고 있고 그거에 대한 유니크 키(+ 인덱스)가 있는데 상관 없지 않아?
@coderabbitai

Copy link

@coderabbitai coderabbitai bot Oct 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check for composite unique key on (email, authType) in migration files
echo "=== Searching for composite unique key on email and authType ==="
rg -n -A2 -B2 "UNIQUE.*email.*authType|UNIQUE.*authType.*email|email.*authType.*UNIQUE|authType.*email.*UNIQUE" src/main/resources/db/migration/

echo -e "\n=== Checking for unique constraints in site_user table creation ==="
rg -n -A10 -B5 "CREATE TABLE.*site_user" src/main/resources/db/migration/

echo -e "\n=== Looking for any unique key definitions with email ==="
rg -n "UNIQUE KEY.*email" src/main/resources/db/migration/

Length of output: 1657

🏁 Script executed:

#!/bin/bash
# Get the full site_user table definition
echo "=== Full site_user table definition ==="
sed -n '/CREATE TABLE.*site_user/,/^);/p' src/main/resources/db/migration/V1__init.sql

echo -e "\n=== Searching for ALTER TABLE site_user with UNIQUE ==="
rg -n "ALTER TABLE.*site_user.*UNIQUE|ALTER TABLE.*site_user.*ADD.*KEY" src/main/resources/db/migration/

echo -e "\n=== Looking for authType column ==="
rg -n "authType|auth_type" src/main/resources/db/migration/V1__init.sql

echo -e "\n=== All unique key additions in migration files ==="
rg -n "ADD.*UNIQUE|CREATE.*UNIQUE" src/main/resources/db/migration/

Length of output: 1090

🏁 Script executed:

#!/bin/bash
# Search for authType across all migration files
echo "=== Searching for authType in all migration files ==="
rg -n "authType|auth_type" src/main/resources/db/migration/

echo -e "\n=== List all migration files to see the sequence ==="
ls -1 src/main/resources/db/migration/ | sort -V

echo -e "\n=== Check if there are any recent migrations that add composite unique key ==="
rg -n -C3 "email.*auth|auth.*email" src/main/resources/db/migration/

echo -e "\n=== Look for all CONSTRAINT or KEY definitions in site_user ==="
rg -n "site_user" src/main/resources/db/migration/ | grep -i "constraint\|key\|index"

Length of output: 8701

@Gyuhyeok99, 맞습니다! 제가 잘못 판단했네요. 😅

V3 마이그레이션에서 이미 uk_site_user_email_auth_type UNIQUE (email, auth_type) 복합 유니크 키가 생성되어 있고, MySQL의 최좌측 프리픽스(leftmost prefix) 규칙에 따라 (email, auth_type) 인덱스는 email 단독 조회에도 효율적으로 사용될 수 있습니다.

따라서 email 단독 유니크 키를 제거하더라도 복합 인덱스가 email 필터링 쿼리의 성능을 충분히 보장하므로, 별도의 일반 인덱스를 추가할 필요가 없습니다.

이전 제안을 철회합니다. 현재 마이그레이션 스크립트는 그대로 사용하셔도 문제없습니다! 👍

Loading