MySQL (r1)

MySQL은 스웨덴의 회사 MySQL AB에 의해 개발되었다. 공동 설립자 데이비드 악스마크와 마이클 "몬티" 비데니우스는 1995년에 TcX라는 작은 컨설팅 회사에서 ISAM 기반의 데이터베이스 도구를 사용하고 있었다. 그들은 기존 도구의 한계를 극복하고 더 빠르고 유연한 시스템을 필요로 했으며, 이로 인해 새로운 데이터베이스의 개발이 시작되었다.

초기 버전의 MySQL은 1995년 5월 23일에 내부적으로 출시되었다. 첫 공개 릴리스는 1996년 초에 이루어졌으며, 이는 주로 마이크로소프트 윈도우와 리눅스를 지원했다. MySQL이라는 이름은 공동 창립자 몬티의 딸 'My'와 구조화된 질의어를 의미하는 SQL의 조합에서 유래했다[2]. MySQL AB는 1995년 설립되었으나, 본격적인 상업적 활동은 2001년부터 시작되었다.

MySQL은 초기부터 오픈 소스 라이선스 정책으로 주목을 받았다. 이중 라이선스 모델을 채택하여, GNU 일반 공중 사용 허가서(GPL) 하에 무료로 사용할 수 있도록 하면서도, 상용 소프트웨어에 임베드하려는 기업을 위해 상용 라이선스도 판매했다. 이 전략은 빠른 사용자 기반 확보와 상업적 성공의 토대가 되었다. 2000년대 초반, MySQL은 램프(LAMP) 스택의 핵심 구성 요소로 자리 잡으며 웹 애플리케이션 개발의 표준 데이터베이스가 되었다.

MySQL AB는 2008년 1월, 썬 마이크로시스템즈에 약 10억 달러에 인수되었다. 이 인수는 MySQL의 역사에서 중요한 전환점이 되었다.

2008년에 썬 마이크로시스템즈가 MySQL AB를 인수한 지 1년도 채 되지 않은 2009년, 오라클은 썬 마이크로시스템즈를 인수하면서 MySQL의 지적 재산권과 개발을 이어받게 되었다. 이 인수는 당시 MySQL의 미래에 대한 커뮤니티와 경쟁사들의 우려를 불러일으켰다. 특히, MySQL이 오라클의 주력 제품인 오라클 데이터베이스와의 경쟁 관계에 놓이면서 개발이 소홀해지거나 폐쇄적인 방향으로 전환될 것이라는 의견이 제기되었다.

그러나 오라클 인수 이후 MySQL은 지속적인 개발 투자와 엔터프라이즈급 기능 강화를 경험했다. 주요 개선 사항은 다음과 같다.

이러한 발전에도 불구하고, 오라클의 소유권에 대한 우려는 마리아DB와 같은 포크(fork) 프로젝트를 탄생시키는 계기가 되었다. 마리아DB는 MySQL의 원 개발자들이 주도하여 호환성을 유지하면서도 완전한 오픈 소스로 개발을 지속하는 대안으로 자리 잡았다. 결과적으로 오라클 인수는 MySQL이 더욱 안정적이고 기능이 풍부한 엔터프라이즈 데이터베이스로 성장하는 동시에, 오픈 소스 데이터베이스 생태계의 다양성을 촉진하는 이중적인 결과를 가져왔다. 현재 MySQL은 여전히 가장 인기 있는 오픈 소스 관계형 데이터베이스 관리 시스템 중 하나로 자리매김하고 있다.

MySQL의 핵심 특징 중 하나는 플러그인 가능한 스토리지 엔진 아키텍처이다. 이는 데이터베이스 시스템이 테이블 단위로 서로 다른 스토리지 엔진을 사용할 수 있게 하여, 데이터 저장, 색인 생성, 트랜잭션 처리 방식 등을 애플리케이션 요구사항에 맞게 선택할 수 있게 한다. 상위 레이어의 SQL 파서와 옵티마이저는 엔진과 독립적으로 동작하며, 엔진은 실제 데이터의 물리적 저장과 접근을 담당한다.

가장 널리 사용되는 엔진은 InnoDB이다. InnoDB는 완전한 ACID 트랜잭션을 지원하고, 외래 키 제약 조건을 강제하며, 행 단위 잠금을 제공한다. 기본 데이터 저장 방식은 클러스터형 인덱스로, 기본 키를 기준으로 데이터 행이 물리적으로 정렬되어 있어 기본 키 조회 성능이 뛰어나다. 또한 MVCC를 구현하여 동시 읽기와 쓰기의 성능을 높이고, 크래시 복구 기능을 갖추고 있다. MySQL 5.5 버전 이후부터는 기본 스토리지 엔진으로 채택되었다.

반면, MyISAM은 역사적으로 MySQL의 기본 엔진이었다. MyISAM은 트랜잭션을 지원하지 않으며, 테이블 단위 잠금을 사용한다. 이는 쓰기 작업이 많은 환경에서 동시성 문제를 일으킬 수 있다. 그러나 전문 검색 인덱스를 지원하고, 상대적으로 낮은 오버헤드로 인해 주로 읽기 위주의 작업이나 데이터 웨어하우스 환경에서 사용되었다. MyISAM 테이블은 데이터 파일(.MYD)과 인덱스 파일(.MYI)로 구성되며, 테이블 수준의 잠금 메커니즘은 구조가 단순하다는 장점이 있다.

다양한 용도에 맞는 다른 엔진들도 존재한다. 예를 들어, MEMORY 엔진은 데이터를 RAM에 저장하여 매우 빠른 접근 속도를 제공하지만 서버 재시작 시 데이터가 사라진다. ARCHIVE 엔진은 압축률이 높아 로그 데이터 등의 대량 저장에 적합하다. 사용자는 `CREATE TABLE` 문에서 `ENGINE = 엔진_이름` 절을 지정하여 테이블의 스토리지 엔진을 선택할 수 있다.

MySQL은 사용자가 제출한 SQL 쿼리를 효율적으로 실행하기 위해 여러 단계를 거쳐 처리합니다. 이 과정은 주로 쿼리 파싱, 최적화, 실행 계획 수립 및 실행으로 구성됩니다. 쿼리 파서는 SQL 문법을 검사하고 구문 트리로 변환합니다. 그 후, 쿼리 옵티마이저가 가장 효율적인 실행 방법을 결정하는 핵심 단계인 최적화를 수행합니다. 옵티마이저는 테이블 조인 순서, 사용할 인덱스 선택, 접근 방법(전체 테이블 스캔 vs 인덱스 스캔) 등을 비용 기반 모델을 통해 평가합니다.

쿼리 최적화의 성능은 옵티마이저가 수립하는 실행 계획에 크게 의존합니다. `EXPLAIN` 명령어를 쿼리 앞에 붙여 실행하면, MySQL이 해당 쿼리를 어떻게 처리할지에 대한 계획을 확인할 수 있습니다. `EXPLAIN` 출력은 다음과 같은 주요 정보를 제공합니다.

실행 계획을 분석하여 비효율적인 부분을 찾고 튜닝할 수 있습니다. 예를 들어, `type` 컬럼이 `ALL`로 표시되면 풀 테이블 스캔이 발생한다는 의미이며, 적절한 인덱스 생성이 필요할 수 있습니다. `Using filesort`나 `Using temporary`는 정렬이나 중간 결과 저장을 위해 디스크 I/O를 유발할 수 있어 성능 저하의 원인이 됩니다.

성능 향상을 위해 개발자는 쿼리 작성을 최적화하고, 옵티마이저가 효율적인 계획을 선택하도록 유도해야 합니다. 자주 사용되는 검색 조건이나 조인 조건의 컬럼에 인덱스를 생성하는 것이 가장 일반적인 방법입니다. 또한, 불필요한 열을 선택하지 않고(`SELECT *` 대신 필요한 열만 명시), 서브쿼리 대신 적절한 JOIN을 사용하며, 쿼리 로직을 단순화하는 것이 중요합니다. 옵티마이저 힌트(예: `USE INDEX`, `FORCE INDEX`)를 사용하여 특정 인덱스 사용을 강제할 수도 있지만, 데이터 분포가 변경되면 역효과가 날 수 있으므로 신중하게 적용해야 합니다.

트랜잭션은 데이터베이스에서 논리적인 작업의 단위를 의미한다. 여러 개의 SQL 문(예: INSERT, UPDATE, DELETE)을 하나의 그룹으로 묶어, 그룹 내 모든 작업이 완전히 성공하거나 완전히 실패하도록 보장하는 메커니즘이다. MySQL의 InnoDB 스토리지 엔진은 이러한 트랜잭션을 지원한다.

트랜잭션의 신뢰성을 보장하기 위한 네 가지 핵심 속성을 ACID라 부른다. MySQL의 InnoDB는 이 속성들을 준수한다.

• 원자성 (Atomicity): 트랜잭션은 모두 수행되거나 모두 수행되지 않아야 한다. 중간에 오류가 발생하면 트랜잭션 시작 전 상태로 롤백된다. InnoDB는 이를 위해 언두 로그를 사용한다.

• 일관성 (Consistency): 트랜잭션이 완료되면 데이터베이스는 미리 정의된 규칙(제약 조건, 트리거 등)을 만족하는 일관된 상태로 유지되어야 한다.

• 격리성 (Isolation): 동시에 실행되는 여러 트랜잭션이 서로에게 영향을 미치지 않도록 격리한다. InnoDB는 트랜잭션 격리 수준을 설정할 수 있다[7].

• 지속성 (Durability): 한 번 커밋된 트랜잭션의 결과는 시스템 장애가 발생하더라도 영구적으로 보존되어야 한다. InnoDB는 커밋 시 데이터를 리두 로그에 기록하여 이 속성을 보장한다.

트랜잭션은 `START TRANSACTION`, `BEGIN` 또는 암시적으로 시작하며, `COMMIT`으로 변경 사항을 확정하거나 `ROLLBACK`으로 취소한다. 적절한 트랜잭션 사용은 데이터 무결성을 유지하는 데 필수적이다.

MySQL 복제는 하나의 데이터베이스 서버(소스 서버)의 데이터 변경 사항을 하나 이상의 다른 서버(레플리카 서버)로 자동으로 복사하는 기능이다. 이는 주로 데이터 백업, 읽기 작업 부하 분산, 고가용성 확보를 목적으로 사용된다. 복제는 바이너리 로그(Binary Log)를 기반으로 동작하며, 소스 서버에서 발생하는 모든 데이터 변경 이벤트(DDL, DML)를 로그에 기록하고, 레플리카 서버가 이 로그를 읽어 동일한 변경을 자신의 데이터베이스에 재실행하는 방식으로 이루어진다.

복제는 구성 방식에 따라 여러 형태를 가진다. 가장 기본적인 형태는 소스 서버 하나에 레플리카 서버 여러 대가 연결되는 단방향 복제(Source-Replica)이다. 또한, 체인 복제(Chain Replication)를 통해 한 레플리카가 다른 레플리카의 소스 역할을 할 수 있다. 복제 방식은 로그 동기화 시점에 따라 구분되며, 주요 방식은 다음과 같다.

복제를 설정하려면 소스 서버에서 바이너리 로깅을 활성화하고 고유한 서버 ID를 부여해야 한다. 레플리카 서버는 `CHANGE REPLICATION SOURCE TO` 명령어를 사용해 소스 서버의 연결 정보와 로그 위치를 설정한 후 복제를 시작한다. 관리자는 `SHOW REPLICA STATUS` 명령어를 통해 복제 지연 시간(Replication Lag)이나 연결 상태를 모니터링할 수 있다. 복제 토폴로지는 애플리케이션의 읽기/쓰기 비율과 가용성 요구사항에 따라 설계된다.

파티셔닝은 단일 테이블의 데이터를 논리적으로는 하나의 테이블로 유지하면서, 물리적으로는 여러 개의 하위 테이블(파티션)로 분할하여 저장하고 관리하는 기능이다. 이를 통해 대용량 테이블의 관리 효율성과 쿼리 성능을 향상시킬 수 있다. MySQL은 수평 파티셔닝을 지원하며, 주요 파티셔닝 유형으로 범위(RANGE), 목록(LIST), 해시(HASH), 키(KEY) 파티셔닝이 있다.

각 파티셔닝 유형은 데이터 분배 방식에 차이가 있다. RANGE 파티셔닝은 지정한 열의 값 범위를 기준으로 파티션을 나눈다. 예를 들어, 날짜 열을 기준으로 월별 또는 연도별로 데이터를 분할할 수 있다. LIST 파티셔닝은 열의 값이 미리 정의된 목록에 속하는지에 따라 파티션을 결정한다. HASH 파티셔닝은 사용자가 지정한 표현식의 해시 값을 기반으로 데이터가 분배되며, KEY 파티셔닝은 MySQL 서버가 제공하는 내부 해시 함수를 사용한다. HASH와 KEY 파티셔닝은 데이터를 파티션에 균등하게 분산시키는 데 유용하다.

파티셔닝을 적용하면 얻는 주요 이점은 다음과 같다. 첫째, 특정 파티션만 대상으로 하는 쿼리(파티션 프루닝)가 실행될 경우, 전체 테이블을 스캔하지 않고 관련 파티션만 접근하여 성능이 개선된다. 둘째, 오래된 데이터가 저장된 파티션을 빠르게 삭제(DROP)하거나, 백업 및 유지보수를 파티션 단위로 수행할 수 있어 관리가 용이해진다. 그러나 파티션 키 선택이 부적절하거나 과도한 수의 파티션을 생성하면 오히려 성능이 저하될 수 있으며, 모든 스토리지 엔진이 파티셔닝을 완전히 지원하는 것은 아니다.

파티셔닝은 `CREATE TABLE` 또는 `ALTER TABLE` 문을 사용하여 정의한다. 파티션된 테이블에 대한 대부분의 DML 작업은 기존과 동일하게 수행할 수 있지만, 파티션을 의식하지 않고도 자동으로 올바른 파티션에서 데이터를 처리한다.

MySQL을 설치하고 운영하기 위한 시스템 요구사항은 설치하려는 버전, 운영 체제, 그리고 예상되는 워크로드에 따라 달라진다. 일반적으로 최소 요구사항은 매우 낮지만, 프로덕션 환경에서는 성능과 안정성을 위해 더 높은 사양이 권장된다.

운영 체제 측면에서 MySQL은 리눅스, 유닉스, 윈도우, macOS 등 다양한 플랫폼을 공식 지원한다. 리눅스 배포판(예: 우분투, 센트OS, 레드햇 엔터프라이즈 리눅스)이 가장 일반적인 운영 환경이다. 하드웨어 최소 요구사항은 다음과 같다.

실제 필요한 디스크 공간과 메모리는 데이터베이스의 크기, 트랜잭션 볼륨, 복제 설정 여부, 그리고 사용하는 스토리지 엔진에 크게 의존한다. 예를 들어, InnoDB 스토리지 엔진은 자체 버퍼 풀을 위해 상당한 양의 RAM을 할당하는 것이 성능에 유리하다. 또한, 디스크 I/O 성능은 데이터베이스 응답 시간에 직접적인 영향을 미치므로, SSD 사용이 HDD보다 현저히 우수한 성능을 제공한다. 네트워크 대역폭과 지연 시간도 분산 환경이나 고가용성 구성 시 중요한 고려 사항이 된다.

설치 직후에는 기본 계정이 취약한 상태로 남아 있는 경우가 많으므로, 초기 보안 설정이 필수적이다. 가장 먼저 실행해야 하는 작업은 `mysql_secure_installation` 스크립트를 이용하는 것이다. 이 스크립트는 다음과 같은 일련의 보안 강화 단계를 안내한다.

• 루트 패스워드 설정: 설치 시 루트 계정의 패스워드가 비어 있을 수 있으므로 강력한 패스워드를 즉시 설정한다.

• 익명 사용자 제거: 테스트 목적의 익명 계정을 삭제하여 불필요한 접근 경로를 제거한다.

• 원격 루트 로그인 비활성화: 루트 계정이 로컬 호스트('localhost')에서만 접속 가능하도록 제한한다.

• 테스트 데이터베이스 삭제: 기본적으로 생성되는 'test' 데이터베이스 및 관련 접근 권한을 제거한다.

스크립트 실행 후에는 사용자 권한 테이블의 변경 사항을 적용하기 위해 `FLUSH PRIVILEGES` 명령을 실행하거나 서비스를 재시작해야 한다.

보다 세부적인 설정을 위해 my.cnf (또는 `my.ini`) 구성 파일을 수정할 수 있다. 네트워크 보안을 위해 `bind-address` 지시어를 특정 IP 주소로 제한하는 것이 좋다. 기본값인 `0.0.0.0`(모든 인터페이스 청취)은 위험할 수 있다. 또한, 일반적인 SQL 인젝션 공격에 대비해 `secure_file_priv` 변수를 설정하여 파일 시스템 접근을 특정 디렉토리로 제한하고, `local_infile` 기능을 필요하지 않다면 비활성화하는 것이 안전하다. 모든 설정 변경 후에는 MySQL 서버를 재시작하여 변경 사항이 적용되도록 해야 한다.

DDL은 데이터베이스의 구조를 정의하고 변경하는 데 사용되는 SQL 명령어 집합이다. 이 명령어들을 통해 데이터베이스, 테이블, 인덱스, 뷰 등의 스키마 객체를 생성, 수정, 삭제할 수 있다. DDL 명령어는 실행 시 자동으로 커밋되므로, 명시적인 트랜잭션 제어가 필요하지 않다.

주요 DDL 명령어는 다음과 같다.

* `CREATE`: 새로운 데이터베이스나 테이블과 같은 객체를 생성한다.

* `ALTER`: 기존 객체의 구조를 수정한다. 예를 들어, 테이블에 새로운 컬럼을 추가하거나 데이터 타입을 변경한다.

* `DROP`: 객체를 데이터베이스에서 완전히 삭제한다.

* `TRUNCATE`: 테이블의 모든 데이터를 삭제하지만, 테이블 구조는 유지한다. 이 작업은 일반적으로 `DELETE` 문보다 빠르다.

* `RENAME`: 객체의 이름을 변경한다.

아래는 주요 DDL 명령어의 사용 예시를 보여주는 표이다.

`CREATE TABLE` 문을 사용할 때는 각 컬럼의 이름, 데이터 타입(예: `INT`, `VARCHAR`, `DATE`), 그리고 `NOT NULL`, `AUTO_INCREMENT`, `PRIMARY KEY`, `FOREIGN KEY`와 같은 제약 조건을 정의한다. `ALTER TABLE` 명령은 운영 중인 시스템에서 스키마를 진화시킬 때 핵심적인 역할을 한다. 그러나 대용량 테이블의 구조를 변경하는 작업은 시스템 성능에 영향을 미칠 수 있으므로 주의가 필요하다.

DML은 데이터베이스 내의 실제 데이터를 조작하는 데 사용되는 SQL 명령어 집합이다. SELECT, INSERT, UPDATE, DELETE 명령어가 핵심을 이루며, 이들을 통해 테이블에 저장된 레코드를 검색, 추가, 수정, 삭제한다. SELECT 문은 조건에 맞는 데이터를 조회하는 데 사용되며, WHERE 절을 통한 필터링, JOIN을 통한 다중 테이블 연계 검색, GROUP BY와 집계 함수를 이용한 그룹화 및 통계 산출이 가능하다. INSERT 문은 새로운 행을 테이블에 추가하고, UPDATE 문은 기존 행의 특정 컬럼 값을 수정하며, DELETE 문은 조건에 맞는 행을 테이블에서 제거한다.

이들 명령어는 주로 트랜잭션 내에서 실행되어 데이터 무결성을 보장한다. 특히 InnoDB 스토리지 엔진을 사용할 경우, 명시적인 트랜잭션 제어 명령어인 START TRANSACTION, COMMIT, ROLLBACK과 함께 사용된다. 이를 통해 여러 DML 작업을 하나의 논리적 작업 단위로 묶어, 모두 성공하거나 모두 실패하는 원자성을 유지할 수 있다. 예를 들어, 계좌 이체 작업은 한 계좌에서 금액을 차감(UPDATE)하고 다른 계좌에 금액을 추가(UPDATE)하는 두 DML 작업을 하나의 트랜잭션으로 처리해야 한다.

다음은 주요 DML 명령어의 기본 구문 예시이다.

WHERE 절을 생략한 UPDATE나 DELETE 문은 테이블의 모든 행에 영향을 미치므로 주의가 필요하다. 또한 대량의 데이터를 조작할 때는 성능에 미치는 영향을 고려해야 하며, 적절한 인덱스 사용이 쿼리 성능을 결정하는 핵심 요소가 된다. SELECT ... FOR UPDATE와 같은 문법을 사용하면 조회와 동시에 해당 행에 배타적 잠금을 걸어 동시성 제어를 할 수도 있다.

인덱스는 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료 구조이다. MySQL에서 적절한 인덱스를 설계하고 사용하는 것은 시스템 전반의 성능에 결정적인 영향을 미친다. 인덱스는 책의 색인과 유�사하게, 특정 컬럼의 값을 기반으로 데이터 레코드의 물리적 위치를 빠르게 찾을 수 있게 한다. 그러나 모든 컬럼에 인덱스를 생성하면 쓰기 작업(INSERT, UPDATE, DELETE) 속도가 저하되고 디스크 공간을 추가로 사용하므로, 신중한 선택이 필요하다.

인덱스 최적화의 첫 번째 단계는 적절한 인덱스 타입을 선택하는 것이다. MySQL은 주로 B-Tree 인덱스를 사용하며, 이는 범위 검색과 정렬에 효율적이다. 풀텍스트 인덱스는 텍스트 검색에, 공간 데이터 타입에는 R-Tree 인덱스가 사용된다. 가장 일반적인 최적화 방법은 WHERE 절이나 JOIN 조건에 자주 사용되는 컬럼에 인덱스를 생성하는 것이다. 또한, 여러 컬럼을 포함하는 복합 인덱스를 생성할 때는 컬럼의 순서가 매우 중요하다. 가장 선택도가 높은(고유한 값이 많은) 컬럼을 앞에 배치하고, 쿼리가 인덱스의 왼쪽 프리픽스(leftmost prefix)를 사용할 수 있도록 설계해야 한다.

인덱스의 사용 효율을 분석하고 최적화하기 위해 EXPLAIN 명령어를 활용한다. 이 명령어는 MySQL이 쿼리를 실행하는 방식을 보여주어, 인덱스가 제대로 사용되고 있는지, 풀 테이블 스캔이 발생하는지 등을 확인할 수 있다. `EXPLAIN` 출력에서 `type` 컬럼이 'index'나 'range'보다 느린 'ALL'을 나타낸다면 인덱스 최적화가 필요할 가능성이 높다. 또한 사용되지 않는 인덱스는 정기적으로 모니터링하여 제거해야 한다. 불필요한 인덱스는 성능 저하의 원인이 된다.

쿼리 성능 분석은 데이터베이스 튜닝의 핵심 단계로, 실행 속도가 느리거나 시스템 자원을 과도하게 소모하는 쿼리를 식별하고 개선하는 과정이다. MySQL은 쿼리 실행 계획을 확인하고 성능 지표를 수집할 수 있는 다양한 내부 도구를 제공한다.

가장 기본적인 분석 도구는 `EXPLAIN` 문이다. 이 명령어를 SELECT 문 앞에 붙여 실행하면, MySQL 옵티마이저가 선택한 실행 계획을 테이블 형태로 보여준다. 실행 계획에는 접근 방식(풀 테이블 스캔 또는 인덱스 사용), 사용된 인덱스, 조인 방식, 예상 행 수 등의 정보가 포함된다. `EXPLAIN ANALYZE` 문(MySQL 8.0.18 이상)은 쿼리를 실제 실행하며 각 단계의 소요 시간까지 상세히 측정하여 더 정확한 분석을 가능하게 한다. 성능 분석을 위한 주요 지표는 다음과 같다.

지속적인 모니터링을 위해 성능 스키마(Performance Schema)와 정보 스키마(INFORMATION_SCHEMA) 데이터베이스를 활용할 수 있다. 성능 스키마는 서버 내부의 저수준 이벤트를 실시간으로 수집하며, 정보 스키마의 `PROCESSLIST` 테이블을 조회하면 현재 실행 중인 쿼리와 그 상태를 확인할 수 있다. 느린 쿼리는 `slow_query_log`를 활성화하여 지정된 시간보다 오래 실행된 쿼리를 모두 로그 파일에 기록하도록 설정한다. 이 로그를 분석하면 반복적으로 발생하는 성능 병목 지점을 발견하는 데 도움이 된다.

MySQL Cluster는 MySQL 데이터베이스의 고가용성과 수평적 확장성을 제공하는 분산 데이터베이스 클러스터링 기술이다. 이는 공유-무엇(shared-nothing) 아키텍처를 기반으로 하여, 여러 개의 데이터 노드에 데이터를 자동으로 샤딩하고 복제하여 단일 장애 지점(Single Point of Failure)을 제거한다. 클러스터는 NDB (Network Database)라는 특수한 스토리지 엔진을 사용하며, 이는 메모리 내(주로) 또는 디스크 기반 스토리지를 활용하여 매우 빠른 읽기 및 쓰기 성능을 목표로 설계되었다.

클러스터의 핵심 구성 요소는 데이터 노드, 관리 노드, 그리고 SQL 노드(MySQL 서버)로 나뉜다. 데이터 노드는 실제 데이터를 저장하고 복제본을 관리한다. 관리 노드는 클러스터의 구성, 시작, 중단, 백업을 담당한다. SQL 노드는 기존의 MySQL 서버와 동일한 인터페이스를 제공하며, 애플리케이션은 표준 SQL 쿼리와 API (예: JDBC, ODBC)를 사용하여 클러스터에 접근한다. 데이터는 여러 데이터 노드에 걸쳐 자동으로 파티셔닝되며, 각 파티션은 동기적으로 복제되어 장애 발생 시에도 데이터 가용성을 보장한다.

주요 적용 분야는 실시간 트랜잭션 처리와 고가용성이 요구되는 서비스이다. 예를 들어, 통신 산업의 HLR (Home Location Register), 온라인 게임, 금융 거래 플랫폼, 실시간 분석 등에 사용된다. 표준 MySQL과의 주요 차이점은 다음과 같다.

클러스터 구성은 복잡성이 높고, 모든 데이터가 메모리에 상주할 경우 물리적 메모리 용량이 주요 제약 조건이 될 수 있다. 또한, JOIN 연산이나 복잡한 쿼리의 성능은 표준 MySQL의 InnoDB 엔진에 비해 제한적일 수 있어, 애플리케이션 설계 시 이를 고려해야 한다.

샤딩은 단일 데이터베이스의 데이터를 여러 물리적 서버(샤드)에 수평적으로 분할하여 저장하는 데이터베이스 확장성 전략이다. MySQL 자체적으로는 자동화된 샤딩 기능을 공식적으로 제공하지 않는다. 따라서 애플리케이션 레벨에서 논리적 분할을 구현하거나, Vitess, ProxySQL, MaxScale과 같은 미들웨어 또는 프록시 도구를 활용하여 샤딩 아키텍처를 구축한다.

주요 샤딩 전략은 데이터를 분배하는 기준(샤딩 키)에 따라 달라진다. 가장 일반적인 방식은 범위 기반 샤딩과 해시 기반 샤딩이다. 범위 기반 샤딩은 특정 컬럼 값의 범위(예: 사용자 ID 1-1000000은 샤드 A, 1000001-2000000은 샤드 B)에 따라 데이터를 할당한다. 해시 기반 샤딩은 샤딩 키에 일관된 해시 함수를 적용하여 결과값에 따라 데이터가 저장될 샤드를 결정한다. 이는 데이터 분포를 보다 균일하게 만드는 장점이 있다.

샤딩을 설계할 때는 샤드 간 조인 연산의 복잡성, 트랜잭션의 일관성 유지, 그리고 샤드 추가 또는 재분배 시의 운영 복잡도를 고려해야 한다. 또한, 모든 샤드를 아우르는 글로벌 쿼리를 실행하기 어렵다는 점이 주요 제약사항이다. 이러한 복잡성으로 인해, 많은 경우 먼저 읽기 전용 복제본이나 캐싱을 통한 확장을 고려한 후, 꼭 필요한 경우에 샤딩을 도입한다.

MySQL에서 사용자 계정은 호스트 정보와 사용자 이름의 조합으로 식별된다. 예를 들어, 'user1'@'localhost'와 'user1'@'192.168.1.%'는 서로 다른 계정으로 처리된다. 계정 생성은 `CREATE USER` 문을 사용하며, 계정에는 인증 플러그인과 초기 패스워드를 지정할 수 있다. MySQL 8.0부터는 기본 인증 방식이 `caching_sha2_password`로 변경되어 보안이 강화되었다.

권한 관리는 계정에 부여된 데이터베이스 객체에 대한 접근 및 작업 허용 범위를 정의한다. 권한은 글로벌 권한, 데이터베이스 수준 권한, 테이블 수준 권한, 컬럼 수준 권한, 루틴 수준 권한으로 세분화된다. `GRANT` 문을 사용하여 특정 권한을 부여하고, `REVOKE` 문을 사용하여 권한을 회수한다. 예를 들어, `GRANT SELECT, INSERT ON mydb.* TO 'user1'@'localhost';`는 해당 계정에 `mydb` 데이터베이스의 모든 테이블에 대한 조회와 삽입 권한을 부여한다.

부여된 권한 정보는 `mysql` 시스템 데이터베이스의 `user`, `db`, `tables_priv`, `columns_priv`, `procs_priv` 테이블에 저장된다. 권한 변경 후에는 `FLUSH PRIVILEGES` 명령을 실행하여 변경 사항을 메모리에 반영해야 한다. 단, `GRANT`나 `REVOKE` 같은 계정 관리 문장을 직접 사용한 경우에는 자동으로 반영된다.

역할(Role) 기능을 사용하면 권한 집합을 그룹화하여 여러 사용자 계정에 일괄적으로 부여할 수 있어 관리 효율성을 높인다. 역할을 생성하고 권한을 부여한 후, `GRANT` 문으로 사용자에게 역할을 할당한다. 사용자 계정의 현재 권한을 확인하려면 `SHOW GRANTS FOR 'username'@'host';` 명령을 사용한다.

MySQL은 데이터베이스, 테이블, 테이블스페이스 수준에서 데이터 암호화를 지원하여 저장 데이터의 기밀성을 보장한다. 주요 암호화 기능은 InnoDB 스토리지 엔진을 중심으로 제공되며, TLS/SSL 프로토콜을 통한 전송 중 데이터 암호화도 가능하다.

저장 데이터 암호화는 `keyring` 플러그인을 통해 관리되는 마스터 키와 테이블스페이스별로 생성되는 암호화 키를 사용한다. 사용자는 `CREATE TABLE` 또는 `ALTER TABLE` 문에 `ENCRYPTION='Y'` 옵션을 지정하여 특정 테이블이나 테이블스페이스를 암호화할 수 있다. 암호화는 AES(Advanced Encryption Standard) 알고리즘을 기반으로 하며, 데이터 파일과 리두 로그, 언두 로그 등에도 적용되어 디스크에 저장되는 모든 데이터를 보호한다.

전송 계층 보안을 위해 MySQL은 클라이언트와 서버 간 연결에 TLS/SSL을 사용할 수 있다. 이를 설정하려면 서버와 클라이언트에 각각 인증서와 키 파일을 구성해야 한다. 연결이 암호화되었는지는 `SHOW SESSION STATUS LIKE 'Ssl_cipher'` 명령어로 확인할 수 있다. 또한, `sha256_password`나 `caching_sha2_password` 같은 인증 플러그인은 비밀번호 전송을 암호화하여 인증 과정의 보안을 강화한다.