2026-10-14 · 2026-10-14 전체

"MySQL 2천만 행 넘기면 느려진다" vs "램 256GB면 상관없다" — 중국 개발자 댓글은 "그 서버 누가 사 줘?"

"MySQL 테이블이 2천만 행을 넘으면 느려진다"는 아키텍트에게 개발자가 "램 256GB면 상관없다"고 반박했다. 중국 개발자들의 첫 반응은 "그 서버, 네가 돈 내냐"였다.

알리윈 MySQL 128GB가 월 12만 8천 위안(약 2,550만원)이라는 계산, "최근 2년은 그룹웨어 하나 올리는 것도 반려된다"는 하소연, "경기 상승기의 순진함"이라는 댓글이 이어졌다. 한편에선 "우리는 단일 테이블 20억 행"이라는 자랑이 쏟아졌다.

출처: V2EX 10/13

'2천만 행 룰'

중국 개발자 사이에는 오래된 경험칙이 있다. MySQL 단일 테이블이 2천만 행을 넘으면 성능이 떨어지니 그 전에 샤딩(분할 테이블)하라는 것이다. 중국 백엔드 면접 단골 질문이기도 하다.

근거는 InnoDB 인덱스 구조다. InnoDB는 데이터를 B+트리로 저장하는데, 행 수가 대략 2천만을 넘으면 트리 높이가 3에서 4로 늘어난다. 조회할 때 거치는 노드가 하나 늘고, 노드마다 디스크 I/O가 한 번씩 생기니 느려진다는 계산이다.

글쓴이: "비리프 노드는 전부 메모리에 있다"

글쓴이가 아키텍트에게 이유를 묻자 이런 답이 돌아왔다. "2천만 넘으면 B+트리가 3층에서 4층이 된다. 한 층 늘면 디스크 I/O가 한 번 는다. 더 말하기 싫으니 AI한테 물어봐."

글쓴이의 반박은 이렇다. 요즘 운영 DB 서버는 램이 256GB이고 그중 200GB를 버퍼 풀에 할당한다. 그러면 B+트리의 비리프 노드는 전부 메모리에 상주한다. 늘어난 한 단계는 디스크 I/O가 아니라 수십 나노초짜리 메모리 내 이진 탐색일 뿐이다.

글쓴이는 백업·복구가 SLA를 못 맞추거나 온라인 DDL 위험이 크거나 핫 데이터 워킹셋이 메모리를 넘어 랜덤 I/O가 폭증하는 경우라면 샤딩하고 아카이브하는 게 맞고, 그건 정당한 아키텍처 판단이라고 썼다. 하지만 하드웨어 사양도 쿼리 패턴도 보지 않고 "B+트리가 4단이 되면 성능이 무너진다"를 경전처럼 외우면 안 된다고 했다. "자세한 건 AI한테 물어보라"던 아키텍트에게는 이렇게 받아쳤다. "AI한테 물어보면 이 글이 그대로 답으로 나올 거다."

"256GB, 네가 사 줄 거야?"

댓글은 66개였다. 첫 반응은 기술이 아니라 돈이었다.

• "256GB 램은 비현실적이다. 대부분 알리윈 같은 클라우드에 올리는데, 256GB가 얼마인지 봐라."
• "서버 램 256GB, 네가 돈 내냐? 하하하하하하하."
• "알리윈 방금 조회했다. ECS 최대 104GB, RDS MySQL 고가용성 최대 128GB에 월 12만 8천 위안(약 2,550만원)이다. 나머지는 64GB도 안 된다. 256GB는 어디서 났나."
• "작년에 메모리 값 오르기 전엔 256GB 서버 램도 얼마 안 했다."

회사 규모에 따라 이야기가 갈렸다.

• "대기업에겐 256GB는 아무것도 아니다. 작은 회사는 2GB에서 8GB로 올리는 것도 고민한다."
• "그건 너무 작다. 월 몇백 위안 차이 아닌가." → "한 대가 아니라 마스터 1대에 슬레이브 N대일 수도 있다. 다음 분기 부서 예산이 이미 바닥났을 수도 있다. 문제는 몇백이냐 몇만이냐가 아니라 지금 분위기가 '허리띠 졸라매기'라는 거다."
• "그룹 실적 좋을 땐 뭘 증설하자 해도 다 통과됐다. 최근 2년은 그룹웨어 하나 올리자 해도 부서장이 예산 부족이라며 반려한다."
• "몇십만 위안짜리 SI 프로젝트에 256GB 달자고 하면 발주처가 한참 투덜댄다. 32GB, 64GB만 줘도 감지덕지다."
• "돈 더 쓰면 비즈니스 문제 99%는 풀린다. 가장 큰 문제는 돈을 더 쓸 수 없다는 거다."

그리고 이 두 줄이 달렸다.

• "글쓴이에게선 경기 상승기의 아름다움이 느껴진다."
• "경기 상승기의 순진함이 있다."

"우리는 단일 테이블 20억 행"

한편에서는 실사례가 쏟아졌다. 2천만 행 룰은 여러 회사에서 이미 깨져 있었다.

• "우리 고사양 DB는 단일 테이블 200GB, 5~6억 행인데 아무 문제 없다." → 같은 사용자가 다른 댓글에 "이제 10억 행 가까이 된다"고 썼는데, 조회는 항상 기간 조건을 걸고 페이지네이션도 기간 범위 안에서 하며 파티셔닝을 해 뒀다고 했다.
• "주문 테이블이 2억 행에 가깝다. 손을 못 대서 계속 늘고 있는데 시스템은 안정적이다."
• "봤더니 1억 행 조금 넘는다. 램은 8GB."
• "8GB 서버에 MySQL 직접 설치해서 3.4GB쯤 쓰는데, 단일 테이블 1천만 행 넘어도 잘 돈다. 나는 모바일 출신이라 백엔드는 대충 짰다."
• "20억 행 테이블에 512GB 램은 흔하다. 얼마 전엔 AWS r7i.48xlarge(192코어, 1.5TB)로 잠깐 스케일업한 적도 있다. 대부분 하드웨어를 붓는 게 가장 빠른 해법이다."
• "알리윈 PolarDB 같은 제품은 단일 테이블 20억 행도 문제없다."
• "SQL 튜닝을 아무리 해도 디스크를 SSD로 바꾸는 것만 못하다." "NVMe로 바꿨더니 4K 랜덤 읽기가 1만 배, 랜덤 쓰기가 1천 배 빨라졌다."

2천만 행 룰을 편든 댓글

• "하드웨어가 제한적이면 2천만은 실제로 고비다. 그리고 그게 면접 모범답안이다. 면접에서 '돈 더 써서 서버 늘리면 된다'고 하면 떨어진다."
• "반박할 근거는 많지만 256GB 램은 아니다. 운영 MySQL이 한 대뿐인가? DR 안 하나? 단일 테이블 2천만 넘기겠다고 서버 십여 대를 다 256GB로 올리나?"
• "어차피 샤딩할 거면 더 잘게 나누는 게 효과가 좋으니 기준선을 하나 정해 두는 것뿐이다. 부정할 일은 아니다."
• "테이블 구조와 비즈니스에 달렸다. 내가 본 최고는 컬럼 하나에 거대한 JSON을 넣어 두고, 쿼리할 때마다 테이블 전체 JSON을 메모리에 올려 검색하는 방식이었다. 디스크에서 불꽃이 튀었다."

"기술이 아니라 정치 문제"

• "이건 기술 문제가 아니라 정치 문제다. 2천만은 상황 따라 바뀌는 경험치일 뿐인데, 결정권이 고인물과 바보 손에 있다."
• "이런 사람은 잘려도 하나도 억울하지 않다."
• "2026년에 아직 MySQL 고집하는 사람도 있네."
• "나라면 2천만 행 넘는데 아무 문제 없는 테이블을 하나 만들어서 던져 주겠다. 다른 말은 하지 말고."