따봉 구걸남's 블로그

mysql 의 auto_increment 특징 과 주의점들을 알아보자 

# AUTO_INCREMENT의 특징, 최대 값

1) 자동 증가: 새로운 레코드가 삽입시 자동으로 고유한 숫자를 생성. 주로 기본 키로 사용, 각 행의 고유성을 보장
2) 초기값 및 증가값 설정 가능: 기본적으로 1부터 시작하며, 각 행이 추가될 때마다 1씩 증가. 
3) 데이터 타입 제한: 주로 INT 타입으로 설정, 데이터 타입에 따라 최대값이 제한됩니다. 예를 들어, INT의 최대값은 약 21억입니다
4) 연속성: 삭제된 행의 ID는 재사용되지 않고 건너뛴다.

* mysql 에서 innodb 를 엔진으로 사용할때 auto_increment 컬럼을 pk 사용하는 것이 적절한가?

innodb 사용시 pk 의 선정

# 타입 별 최대 값

# 현재 값 확인하기

방법 1) SHOW TABLE STATUS

SHOW TABLE STATUS WHERE Name = '테이블명';

테이블의 상태 정보를 반환하며, 다음 AUTO_INCREMENT 값을 포함하여 테이블의 엔진, 행 수, 평균 행 길이 다양한 메타데이터를 제공

방법 2) INFORMATION_SCHEMA.TABLES

SELECT AUTO_INCREMENT 
   FROM INFORMATION_SCHEMA.TABLES 
 WHERE TABLE_SCHEMA = '데이터베이스명' 
   AND TABLE_NAME = '테이블명'
;

INFORMATION_SCHEMA.TABLES 뷰를 통해 특정 데이터베이스와 테이블에 대한 정보를 쿼리

방법 3) SELECT MAX() 

SELECT MAX(컬럼명) + 1 AS next_auto_increment FROM 테이블명;

현재 존재하는 최대 값을 기반으로 다음 AUTO_INCREMENT 값을 추정
데이터가 삭제되거나 수동으로 삽입된 경우 정확하지 않을 수 있다.

* 이전 버전에서는 auto_increment 값을 메모리에서 관리했지만(서버 재시작시 초기화), 8.0부터는 디스크에 저장하여 영속성을 보장한다.

mysql 파티션 테이블 

# 일반테이블의 파티션 전환시 유의점 
1. 인덱스 제약:
   - MySQL의 파티션 테이블에서는 모든 인덱스가 로컬 인덱스로 처리된다.
   - 글로벌 인덱스를 지원하지 않으므로, 기존 인덱스 구조를 재검토해야 함.

2. 유니크 키와 프라이머리 키 제약:
   - 파티션 키는 모든 유니크 인덱스(프라이머리 키 포함)의 일부 또는 모든 칼럼을 포함해야 함. 아닐경우 에러남
   - 기존 테이블의 키 구조가 이 요구사항을 충족하는지 확인 필수 

3. 외래 키 제약:
   - 파티션 테이블에는 외래 키를 설정 불가 (성능, 관리적 측면의 설계결정)
   - 기존 테이블에 외래 키가 있다면 이를 제거하거나 대체 방안을 마련 필요.

4. 파일 제한:
   - 파티션 테이블은 각 파티션마다 별도의 파일을 사용하므로, 서버의 open-files-limit 설정을 적절히 조정필요.

5. 성능 고려:
   - 파티션 개수가 많아질수록 오히려 성능이 저하될 수 있다.
   - 특히 INSERT 작업의 경우, 파티션 테이블이 일반 테이블보다 느려질 수 있다.

6. 잠금 처리:
   - 파티션 테이블에 쿼리 실행 시 모든 파티션에 대해 잠금이 걸린다.
   - 이는 동시성 처리에 영향을 줄 수 있으므로 주의 필요.

7. 파티션 키 선택:
   - 효과적인 파티션 프루닝을 위해 적절한 파티션 키를 선택해야 함.
   - 주로 조회 조건에 자주 사용되는 칼럼을 파티션 키로 선택하는 것이 유리 

8. 데이터 마이그레이션:
   - 기존 데이터를 새로운 파티션 구조로 마이그레이션하는 과정에서 서비스 중단이 필요한지 확인 필요
   - 대량의 데이터 이동이 필요하므로 충분한 시간과 리소스를 확보해야 함.

9. 쿼리 최적화:
   - 기존 쿼리들이 파티션 구조에서도 효율적으로 동작하는지 검토, 필요시 최적화 필요.

이러한 점들을 고려하여 신중하게 파티션 전환을 계획하고 실행해야 한다. 또한 전환 전후로 충분한 테스트를 수행하여 성능과 기능에 문제가 없는지 확인해야 합니다.
 
# 파티션 테이블 샘플 스크립트 
-- 1. 날짜 기반 레인지 파티션 테이블 생성
CREATE TABLE sales (
    id INT AUTO_INCREMENT,
    sale_date DATE NOT NULL,
    customer_id INT,
    amount DECIMAL(10,2),
    PRIMARY KEY (id, sale_date)
)
PARTITION BY RANGE (YEAR(sale_date)) (
    PARTITION p2021 VALUES LESS THAN (2022),
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION future VALUES LESS THAN MAXVALUE
);

-- 2. 파티션 관리: 새 파티션 추가
ALTER TABLE sales ADD PARTITION (PARTITION p2025 VALUES LESS THAN (2026));

-- 3. 파티션 최적화
ALTER TABLE sales OPTIMIZE PARTITION p2021, p2022, p2023;

-- 4. 특정 파티션 데이터 삭제
ALTER TABLE sales TRUNCATE PARTITION p2021;

-- 5. 파티션 삭제
ALTER TABLE sales DROP PARTITION p2021;

-- 6. 파티션 분할
ALTER TABLE sales REORGANIZE PARTITION p2023 INTO (
    PARTITION p2023_h1 VALUES LESS THAN ('2023-07-01'),
    PARTITION p2023_h2 VALUES LESS THAN (2024)
);
-- maxvalue 파티션 분할 
ALTER TABLE sales
REORGANIZE PARTITION future INTO (
    PARTITION p2025 VALUES LESS THAN (2026),
    PARTITION future VALUES LESS THAN MAXVALUE
);

-- 7. 파티션 정보 확인
SELECT PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH, DATA_LENGTH
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'sales';

-- 8. 파티션을 고려한 쿼리 예시
SELECT * FROM sales PARTITION (p2023)
WHERE sale_date BETWEEN '2023-01-01' AND '2023-12-31';

 

MySQL의 innodb_read_only와 read_only 파라미터는 비슷한 목적으로 사용되지만 몇 가지 중요한 차이점이 있다

1. 적용 범위:
   - innodb_read_only: InnoDB 스토리지 엔진을 사용하는 테이블에만 적용됩니다.
   - read_only: 모든 스토리지 엔진에 적용됩니다.

2. 권한 처리:
   - innodb_read_only: 모든 사용자(SUPER 권한 포함)의 쓰기 작업을 금지합니다.
   - read_only: SUPER 권한(또는 CONNECTION_ADMIN)을 가진 사용자는 여전히 쓰기 작업이 가능합니다.

3. 설정 변경:
   - innodb_read_only: 서버 시작 시에만 설정 가능한 정적 변수입니다.
   - read_only: 동적 변수로, 서버 운영 중에도 변경 가능합니다.

4. 작업 제한:
   - innodb_read_only: InnoDB 관련 모든 쓰기 작업을 금지합니다.
   - read_only: 일반적인 데이터 변경 작업을 금지하지만, TEMPORARY 테이블 작업이나 복제 관련 작업 등은 허용합니다.

5. 사용 목적:
   - innodb_read_only: 주로 읽기 전용 미디어에서 MySQL을 실행하거나, 데이터 무결성을 위해 사용됩니다.
   - read_only: 주로 복제 설정에서 슬레이브 서버를 읽기 전용으로 만들기 위해 사용됩니다.

6. 시스템 테이블 영향:
   - innodb_read_only: mysql 시스템 데이터베이스의 InnoDB 테이블에도 영향을 미칩니다.
   - read_only: 일부 시스템 작업(예: FLUSH TABLES WITH READ LOCK)은 여전히 허용됩니다.

따라서 innodb_read_only는 더 엄격한 읽기 전용 모드를 제공하며, read_only는 일반적인 운영 상황에서 더 유연한 읽기 전용 모드를 제공합니다.

mysql 에서 table 을 복사하는 몇가지 방법 및 특징을 알아보자

1. CTAS 

 CREATE TABLE NEW_TAB  AS  SELECT * FROM OLD_TAB ;

테이블 구조와 모든 데이터를 복사하지만, 인덱스, 기본 키, 외래 키 등은 복사되지 않음

2. LIKE 

 CREATE TABLE NEW_TAB LIKE OLD_TAB ;

원본 테이블의 구조(컬럼, 인덱스, 제약 조건 등)를 그대로 복사

3. SHOW CREATE TABLE 

 SHOW CREATE TABLE OLD_TAB; => DDL 추출해서 생성

MySQL에서 테이블 이름의 대소문자 구분은 lower_case_table_names 시스템 변수로 제어된다.

이 설정은 운영 체제에 따라 기본값이 다르며, 주의해야 할 점들이 있다. 

1. lower_case_table_names 옵션
 - 0: 테이블 이름을 대소문자 구분 (기본값: Unix/Linux)
 - 1: 테이블 이름을 소문자로 저장하고 비교 시 대소문자 구분 안 함 (기본값: Windows, macOS)
 - 2: 테이블 이름을 지정한 대로 저장하지만 비교 시 소문자로 변환 (macOS에서 권장)

2. 운영 체제별 기본 설정
 Unix/Linux: 0 (대소문자 구분)
 Windows: 1 (대소문자 구분 안 함)
 macOS: 2 (저장은 지정한 대로, 비교는 소문자로)

3. 설정 방법
my.cnf 또는 my.ini 파일의 [mysqld] 섹션에 추가:

[mysqld]
lower_case_table_names=1

4. 주의점
 MySQL 8.0부터는 데이터 디렉토리 초기화 후 이 값을 변경할 수 없다
일관성 유지: 모든 환경에서 동일한 설정을 사용하는 것이 좋습니다
복제 고려: 복제 환경에서는 모든 서버가 동일한 설정을 사용해야 합니다
이식성: 대소문자를 구분하지 않는 설정(1)이 가장 이식성이 좋다
기존 데이터: 설정 변경 시 기존 테이블 이름과 충돌할 수 있으므로 주의가 필요
성능: 대소문자를 구분하지 않는 설정은 약간의 성능 저하를 일으킬 수 있다
파일 시스템 고려: 대소문자를 구분하는 파일 시스템(unix/linux)에서는 0 또는 2 설정을 권장

안전하고 일관된 운영을 위해서는 모든 환경에서 lower_case_table_names=1을 사용하는 것이 좋다.
이미 운영 중인 시스템이라면 변경 시 주의가 필요하며, 새로운 시스템 구축 시 이 설정을 고려해야 한다.

mysql 터미널에서 데이터를 dump & load 하는 방법 알아보자 

아래의 환경에서 테이블을 1개 dump & load 한다고 가정하자 
source db : dumpdb
source table : dumpt
source user : mydba

1. mysqldump

 # dump 
 
    mysqldump -u유저명 -p  -h 소스디비IP -P포트번호 디비명 테이블명 > 타겟파일명.sql
ex) mysqldump -umydba -p  -h 소스디비IP -P포트번호 --no-create-db --no-create-info --set-gtid-purged-OFF --single-transaction dumpdb dumpt > dumpt_bak.sql
덤프 범위 지정 옵션
--databases: 덤프할 데이터베이스들을 지정
--all-databases: 모든 데이터베이스를 덤프
--ignore-table: 특정 테이블을 덤프에서 제외

덤프 내용 제어 옵션
--no-create-info: CREATE TABLE 문을 포함하지 않음 (데이터만 덤프)
--no-data: 테이블 구조만 덤프하고 데이터는 포함하지 않음
--add-drop-database: 덤프 파일에 DROP DATABASE 문 포함
--add-drop-table: 덤프 파일에 DROP TABLE 문 포함

성능 및 일관성 관련 옵션
--single-transaction: InnoDB 테이블에 대해 일관된 덤프를 생성 (락 없이)
--quick (-q): 대용량 테이블 덤프 시 메모리 사용을 줄임
--opt: 여러 유용한 옵션들을 한 번에 활성화 (기본값)

출력 형식 관련 옵션
--extended-insert (-e): 다중 행 INSERT 문 사용 (로드 속도 향상)
--complete-insert: INSERT 문에 컬럼명 포함

특수 목적 옵션
--master-data: 복제 설정을 위한 CHANGE MASTER TO 문 포함
--where: 특정 조건에 맞는 데이터만 덤프
--set-gtid-purged=OFF 옵션의 의미와 용도
GTID 정보 제외: 이 옵션을 사용하면 덤프 파일에 GTID 정보를 포함시키지 않습니다
데이터 이동 시 유용: 서로 다른 GTID 환경 간에 데이터를 이동할 때 유용합니다
복제 토폴로지 유지: 기존의 복제 토폴로지를 유지하면서 테이블을 복사하거나 복구할 때 사용합니다
바이너리 로깅 영향: 이 옵션을 사용하면 덤프 파일을 다시 로드할 때 바이너리 로깅을 비활성화하는 명령문(SET @@SESSION.SQL_LOG_BIN = 0;)이 추가되지 않습니다

 # load 
 
1-1) 타겟디비에 접속 후 load

mysql -u유저명 -p  -h 타겟디비IP -P포트번호 타겟디비명 테이블명
source 타겟파일명.sql

1-2) 디비접속과 load 를 한줄로 실행 

mysql -u유저명 -p  -h 타겟디비IP -P포트번호 타겟디비명 테이블명 < 타겟파일명.sql

2. UTIL (mysqlsh) 사용

2-1) mysqlsh 에 붙어서 작업

 # dump

mysqlsh mysql://유저명@소스디비IP:포트
JS > util.dumpTables(schema, tables, outputUrl[, options])
 ex) util.dumpTables (" dumpdb", ["dumpt"], "/data01/work/dumpdir", {dataOnly: true, threads: 4})

* 한줄로 실행하기
mysqlsh -h 디비ip -P포트 -u 유저명 -p --log-file=/경로/파일명.log -e "util.dumpTable(...상동)"

 - 두번째 테이블 항목에 여러개를 추가하는 것이 가능
 - 멀티스레드로 dump 가능. default 는 1이다.

 # load

mysqlsh mysql://유저명@타겟디비IP:포트
JS > util.loadDump(url[, options]) 
 ex) util.loadDump('/data01/work/dumpdir', {schema:"dumpdb", threads: 4, ignoreExistingObjects: true})

 - load 시 thread 는 디폴트가 4로 생략해도 무방하다. 
 - 타겟에 이미 테이블이 존재한다면 ignoreExistingObjects 를 사용한다. dump시 dataOnly 를 사용하면 안써도됨

3. 정리..

mysqldump 는 결과파일을 사람이 편집도 가능한 sql문을 생성하는 로지컬 백업이다. 
mysqlsh 과는 호환이 되지 않는다. 

mysql쉘의 장점 : 

 - 멀티스레드로 병렬실행이 가능 
 - 파일압축
 - 진행률 확인가능 
 
백업을 지원하는 또 다른 유틸인 util.exportTable 의 경우는 CSV, TSV 등 다양한 텍스트 형식으로 백업이 가능하지만 
단일 테이블 작업만 가능하고, util.importTable 로 로드할수 있다. 


 출처 : https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html 

mysql 복제 상태 show replication status\G 를 주기적으로 반복 실행하는 쉘 만들어보자 

원격서버의 상태를 체크한다고 하면 

mysql -h [호스트명] -P[포트번호] -u [사용자명] -p[패스워드] -e "SHOW SLAVE STATUS\G"

============================================================== 

#!/bin/bash

MYSQL_HOST="localhost"
MYSQL_PORT="3306"
MYSQL_USER="your_username"
MYSQL_PASS="your_password"

# 중요한 상태 항목들
ITEMS_TO_SHOW="Source_Log_File|Read_Source_Log_Pos|Exec_Source_Log_Pos|Replica_IO_Running|Replica_SQL_Running|Seconds_Behind_Source|Last_IO_Error|Last_SQL_Error"

while true
do
  echo "==== $(date) ===="
  mysql -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u "$MYSQL_USER" -p"$MYSQL_PASS" -e "SHOW REPLICA STATUS\G" | grep -E "$ITEMS_TO_SHOW"
  
  # 복제 지연 확인
  SECONDS_BEHIND=$(mysql -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u "$MYSQL_USER" -p"$MYSQL_PASS" -e "SHOW REPLICA STATUS\G" | grep "Seconds_Behind_Source" | awk '{print $2}')
  if [ "$SECONDS_BEHIND" != "NULL" ] && [ "$SECONDS_BEHIND" -gt 0 ]; then
    echo "경고: 복제 지연이 $SECONDS_BEHIND 초 발생했습니다."
  fi
  
  echo ""
  sleep 10
done

==============================================================

===== window 버전 =============================

set HOST=[호스트명]
set PORT=[포트번호]
set USER=[사용자명]
set PASS=[비밀번호]

:loop
cls
echo Checking replication status...
mysql -h %HOST% -P %PORT% -u %USER% -p%PASS% -e "SHOW SLAVE STATUS\G" | findstr /C:"Slave_IO_Running" /C:"Slave_SQL_Running" /C:"Seconds_Behind_Master"
timeout /t 5
goto loop

mysql innodb 사용시 pk 선정에 대한 고려사항

1. innodb 의 특성 

 - pk컬럼의 값으로 데이터가 정렬되어 저장된다. 
 - 세컨더리 인덱스에서 rowid 같은 물리적 주소를 사용하지 않고 pk 값을 참조함.  
   이런한 특성으로 pk를 사용한 range 검색에 유리하지만, pk변경이 발생하게 되면 레코드의 재배치, 
   인덱스 재구성 과정이 발생하여 성능에 매우 불리함. 세컨더리 인덱스가 많을경우 pk 가 길면 저장공간이 커짐. 
 - PK가 크면 전체적인 인덱스 크기도 커진다. 작은 PK는 메모리 사용을 줄이고 인덱스 성능을 향상시킴.

2. innodb 에서 pk 선정

 우선순위 :   본질 식별자 >  auto increment > no pk 
  
  1) 본질식별자로 pk 설정하는 경우
 - 업무적으로 의미 있는 칼럼을 PK로 설정하면 쿼리 조건에 자주 사용되어 성능에 유리
 - 순차적이고 업데이트가 거의 발생하지 않는 값인지 확인이 필요. 
 - 단일키 구성이 어려울 경우, 복합키로 구성도 고려할수 있다.  
 
  2) auto increment 로 pk 를 설정하는 경우 (인조식별자, surrogate key)
   장점)
  - 삽입 성능이 우수함. 정수형 데이터로 인덱스 크기가 작고 효율적.
  - 자동으로 증가하는 값으로 중복을 피할 수 있어 고유성이 보장됨.

 단점)
  - 업무적 의미가 없어 쿼리 조건으로 사용되기 어려운 경우가 많음.
  - 보안 측면에서 취약할 수 있다. 키 값이 예측 가능해 SQL injection 공격에 노출 가능성 
  - 분산 환경에서 사용이 어렵다. 여러 데이터베이스에서 키 값 중복 문제가 발생할 수 있다

   로그성 테이블 같은 조회보다 insert 가 주 목적인 경우면 나쁘지 않다.
   
 3) pk 없이 테이블을 생성하는 경우
   innodb 는 내부적으로 인조식별자를 만든다. 이것은 시스템 내부적으로만 쓰이게 되어 성능상 이점이 없다.
   => 최소 auto increment 를 사용하는 것이 낫다.
   
 
 

mysql 은 replication 을 통해 복제서버를 사용할수 있게 해준다. 

복제서버는 백업이나 조회 용도로 쓸수 있어서 매우 유용하다. 

오라클은 ogg 를 사용하거나 data guard 를 사용해야하는데 라이센스를 추가로 구매해야 한다. 

그런면에서 mysql 은 참으로 혜자다. (오라클은 파티션도 EE 에서만 사용가능한데 mysql 은 무료다.)

MySQL Replication

mysql 이 제공하는 replication 은 데이터 변경을 기록하는 binlog 를 target db 에 전달하면 target 에서 relay log 라는 이름으로 기록하고 그것을 다시 target DB 에 반영하는 방식이다. 

이 구조에서의 특징은 아래와 같다. 

1. 소스와 타켓의 지연이 발생한다. 반영해야 할 변경량이 많을수록 지연은 커질수 있다. 완전 실시간 동기화를 요구하는 업무에는 맞지 않는다. 

2. 복제가 깨지기 쉽다.  오라클 RAC 처럼 shared storage 를 쓰는 경우 어느 인스턴스에서 접근해도 동일한 data 를 보장하지만, mysql 복제 방식은 각자 자기의 DB 를 가지고 사용하기에 동일한 DB임이 보장되지 않는다. 

실제로 mysql replication 구조를 운영환경에서 사용하는 중에 복제가 깨지는 일은 종종 일어난다. 

그렇지만 의도적으로 복제DB를 다른 형상으로 유지하고 싶은 경우도 있다. 인덱스를 다르게 유지하거나 스키마를 다르게 유지하는 등의 유연한 운영이 가능하다. 

AWS aurora mysql 

AWS 에서는 aurora 라고 부르는 DB cluster 를 통해 복제DB 를 제공한다. 

AWS 는 레거시 환경의 서버구조를 computing unit 과 storage 로 분리해서 제공하는데,

Aurora cluster 도 아래 그림처럼 sql, trasaction, caching 을 담당하는 instance 와  logging 과 storage 를 담당하는 shared storage volume 구조로 구성되어 있다. 

DB instance 는 writer (primary) instance 와 reader instance 의 두가지 타입으로 이루어져 있다. 

replication 과 다른 특이한 점은 writer 가 6개의 storage 에 write 를 하고 reader 에서는 자기의 storage 를 read만 할 뿐이다. 

여기서 몇가지 의문점이 생길수 있다. 

Q1) 하나의 인스턴스에서 6개의 볼륨에 write 를 하는 것이 성능상 문제가 없는가? 

Q2) 클러스터를 유지하기 위해 6개의 스토리지 비용을 감당하는 것인가? 

그에대한 답은 아래와 같다. 

A1) write 명령에 대해서는 실제 data를 update 하는 것이 아닌 log record 만 우선 update 하는 방식으로 시간을 절약(궁극적으로는 당연히 모든 노드(6개)에서 page update를 한다)

A2) 모든 스토리지가 동일한 구성이 아니고 3개는 data 와 로그레코드를 가진 full segment, 3개는 로그레코드만 가진 tail segemnt 로 구성된다. 그래서 실제로 비용은 6배가 아닌 3.x 배 정도 소요된다. 

형상이 동일하게 유지되기 때문에 replication 방식처럼 의도적으로 다르게 형상을 관리하는 것이 불가능하다. 

RAC 와 replication  의 중간 정도 느낌이다.  

aurora cluster 가 6개의 storage 를 사용하는 이유는 어느하나가 일시적 장애를 만나도 서비스가 가능하게 만드려는데 목적이 있고 내부적으로는 quorum model 을 통해서 그것이 가능해진다. 이 내용은 별도의 포스팅에서 정리해보겠다.

mysql 에서 사용하는 로그들 정리해보자 

1. General log 

general log 를 활용하면 client 에서 어떤 쿼리들을 mysql server 에 보내는지 확인 할수 있다. 

 1) Binary log 와의 차이

general log 는 서버에 쿼리 요청이 들어오는 순서대로 로그에 기록된다. 
반면 binary log 는 실행시간에 따라 기록이 된다. 
또한 binary log 는 select 는 포함하지 않는다. 
general log 는 조회 쿼리도 포함되기에 log 의 양이 많다.  

 2) output 종류 (slow 동일)

아래 log_output 을 아래 세가지 중 하나를 선택할 수 있다. 
none 으로 설정을 하면 우선순위가 앞서며 general_log=on 으로 설정해도 로그가 남지 않는다. 

 - file      =>  *.log 를 생성
 - table   =>  *.csv 를 생성 
 - none 

table 을 선택하면 general_log 이름으로 DB에서 조회가 가능해진다. 
테이블을 사용하는데 size 가 걱정되어 테이블 사이즈를 조회하는 쿼리를 날리면 0 으로 나온다. 
이것은 general_log 테이블이 테이블이라는 object 에 쌓는 것이 아니고
실제로는 CSV 엔진으로 general_log.CSV 라는 파일에 덤프를 쌓고 있기 때문이다. 

 3) Table output 의 장점 

 - query 에 조건문을 넣어서 질의 하는 것이 가능해진다.
 - 원격에서도 확인이 가능 
 - csv 파일 접근 가능한 스프레드시트에서 활용이 가능해진다. 


 4) general log 사용하기 

show variables like 'general%';
set global general_log=on;
set global log_output='TABLE';
set global general_log=off

2. Slow log

실행된 쿼리 중 오래 돌았던 쿼리를 기록. 

남기는 기준은 long_query_time 파라미터 (min 0, default 10)

사용여부 : slow_query_log = 0 disable, 1 enable
파일이름 : slow_query_log_file=file_name

general log 와 마찬가지로 log_output 이 table 일 경우 CSV 엔진을 사용하여 *.CSV 파일을 만든다. 

size 가 커질 경우 조회

3. Bin/relay log 

data 를 변경하는 statement 를 기록. select 는 포함되지 않는다.

복제서버 구조에서 source 쪽의 binlog 를 target 에 전달하면 target 의 relay log 에 동일한 포맷으로 기록된다.

로그포맷 형식에는 아래 3가지가 있다. 

  - Statement-Based Logging (SBL)

  - Row-Based Logging  (RBL) 

  - Mixed

binmysqlbinlog

4. Error log 

mysqld 를 운영, 중지, 시작시 만나게 되는 에러를 기록 

 - 기동관련 정보성 및 에러메시지
 - 비정상종료 복구 메세지
 - 쿼리처리 도중 발생 에러메시지 
 - aborted connection
    max_connect_errors
    
 - innodb모니터링, show engine innodb status 결과 
 - mysql 종료메시지

이렇게 정리해놓고 봐도 알수있는게 mysql 은 네이밍에 일관성이 없는 것이 특징이다.