# SQL Server

3개의 글

v1.0.0 이후, 다섯 기종을 더 깊이 판 심화 아크들과 내가 만든 걸 감사한 기록

이기종 DBMS 운영 관리 플랫폼 DBTower 심화 편. v1.0.0을 찍은 뒤 문서에 정직한 잔여로 남겨둔 것들을 다시 붙잡았습니다. 그중 셋을 닫았습니다. 쿼리도 데이터도 그대로인데 갑자기 느려지는 플랜 플립을 PostgreSQL 16의 GENERIC_PLAN으로 감지하고, 로컬 백업을 S3 호환 오프사이트로 올려 3-2-1을 채웠으며, TLS 강제 관리형 서비스에 붙되 인증서 검증 우회 옵션은 일부러 만들지 않았습니다. 여기서 심화 아크 넷으로 들어갑니다. 플랜 플립은 기종마다 다른 획득 경로를 shape 정규화 한 겹으로 통일해 다섯 기종으로 넓혔고, p95의 정직 등급은 누적에서 최근 구간으로, 미지원에서 추정으로 끌어올리되 못 올리는 Oracle은 라벨로 대비시켰습니다. 설정 변경 없이 세 기종에서 데드락을 읽었고, 관제가 부하가 되지 않도록 스케일을 다섯 축으로 제어했습니다. 끝으로 만든 것을 스스로 감사해, 동시성·정확성·보안·수명주기 네 축을 훑고 OWASP·CWE·벤더 문서와 대조해 FIX와 SKIP을 갈랐습니다.

2026년 7월 6일

데이터베이스 인덱스 ⑤: 클러스터형 인덱스와 DBMS별 차이

PostgreSQL의 heap-organized 모델과 MySQL InnoDB의 clustered index 모델은 근본적으로 다른 세계관입니다. 같은 SQL이라도 저장 구조에 따라 plan과 비용이 전혀 달라지고, secondary index 동작·PK 선택 전략·DBMS 이전 시 함정이 모두 달라집니다. PG/MySQL/SQL Server/Oracle 비교를 1차 자료 기준으로 정리.

2026년 4월 26일

이기종 DBMS를 하나의 컨트롤 플레인으로: DBTower 설계와 쿼리 회귀 감지

MySQL·PostgreSQL·SQL Server처럼 서로 다른 DBMS를 등록부터 모니터링, 백업까지 한 곳에서 관리하는 컨트롤 플레인 DBTower의 설계편입니다. 기종마다 다른 통계 소스(performance_schema·pg_stat_statements·DMV)를 DbmsOperator 인터페이스 하나로 묶었고, 같은 '백업'이 mysqldump·pg_dump·BACKUP DATABASE로 갈리는 차이도 그 인터페이스 뒤로 감췄습니다. '부하 상위 쿼리가 곧 범인은 아니다'라는 문제의식에서 시점 비교가 나왔고, 플랫폼이 자기 자신을 등록해 병목을 잡은 도그푸딩에서는 Seq Scan을 21ms에서 0.06ms로 줄였습니다. 이 시점 비교를 사람이 아니라 플랫폼이 스스로 돌려 쿼리 회귀를 자동으로 감지하고 Discord로 알립니다. 이런 설계 결정과 실측 수치를 함께 기록했습니다.

2026년 3월 17일