자수성가한 부자

DML중에 가장 많은 빈도로 사용되는 SELECT 문의 구조는 아래와 같다.

SELECT문의 구조

SELECT ~

FROM ~ 

WHERE ~ 

GROUP BY ~ 

HAVING ~ 

ORDER BY ~ 

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

각 절의 설명

※ 필수 기술해야하는 절

SELECT : 어떤 컬럼을 조회할 것인가를 기술(반드시 기술해야하는 절) 

FROM : 어느 테이블로부터 데이터를 조회할 것인가를 기술(반드시 기술해야하는 절)

※ 필요에 따라 기술하는 절

WHERE : 자료에 조건을 부여하여 제한을 주는 절. 이 조건에 맞는 열만 조회할 수 있게된다.

GROUP BY : GROUP 함수를 사용하여 자료를 GROUP 지을 때 필요한 절

HAVING : GROUP 지은 결과에 조건을 부여하여 제한을 주는 HAVING 절

ORDER BY : 도출된 결과를 정렬할 수 있는 절

참고 : 전문가로 가는 지름길 오라클 실습 p.17 ~ P.18

DML : Data Manipulation Language

데이터를 다루는 언어로 아래의 4가지 종류로 나눌 수 있다.

1) INSERT 
   : 자료의 입력을 목적으로 한 문장

2) SELECT
   : 자료의 조회를 목적으로 한 문장

3) UPDATE
   : 자료의 수정을 목적으로 한 문장

4) DELETE
   : 자료의 삭제를 목적으로 한 문장

_add_col_optim_enabled (true) => false
 
 - column add 시 dictionary만 update 하고 이후 insert시 해당 컬럼이 생성되게 하는 기능


optimizer_adaptive_plans = false

 파라메타로 제어해야 함. (12cR2에서 optimizer_adaptive_features 는 없어졌음) - Plan 이 매번 바뀔 수 있기 때문에 false 로 권고.. 하지만, 이 기능이 원래 매우 괜찮은 기능이라.. 이 좋은 New Feature를 꺼버리는게 맞을지는 좀 논란의 여지가 있음. optimizer_adaptive_plans (true) => false (12cR2 ~)

프로젝트를 진행하고,

최종 마무리는 진행된 프로젝트의 서비스를 오픈하는 것이다.

오픈시에 그동안 잘 운영되던 것을 새로운 환경에서 실행을 하는 것이므로,

잠재되어있는 문제들이 갑자기 도드라질 수도 있고,

기존에 문제가 없었던 것들이 문제가 되는 상황도 나올 수 있다

그러기에 많은 사람들의 생각을 담아

철저한 계획을 세우고,

그 계획에도 놓치는 것이 없는지 실제 테스트, 리허설 등을 실행해봐야 한다.

하지만 언제나 시간이 모자라는게 문제다.

오픈하고 롤백하고 문제고치고 또 오픈하고,

이렇게 문제를 잡아나아가다 보면

프로젝트 원들끼리도 신뢰가 깨질 뿐만 아니라,

서비스를 이용하는 고객들에게도 신뢰를 잃을 수 있다.

소 잃고 외양간 고치는 일은 하지 않았으면 하는 바램이다.

EXISTS 연산은 서브쿼리가 적어도 하나의 행을 돌려주는지를 체크하고자 할 때 사용한다.

​

예제)

SELECT EMP_ID, EMP_NAME, SALARY

FROM TEMP A

WHERE EXISTS (SELECT B.SALARY

FROM TEMP B

WHERE B.LEV = '과장'

AND A.SALARY > B.SALARY);

innoDB란?

1) 트랜잭션 - 세이프 스토리지 엔진입니다.

2) MyISAM과 비슷하지만 Oracle 처럼 많은 기능을 지원합니다.

3) 다수의 사용자 동시접포먼스를 속과 퍼포먼스가 증가하여 대용량 데이터를 처리할 때 최대의 퍼포먼스를 내도록 설계되었습니다. CPU 효율은 어느 디스크 기반의 데이터베이스와 비교해도 손색이 없고, 자체적으로 메인 메모리 안에 데이터 캐싱과 인덱싱을 위한 버퍼풀(pool)을 관리합니다.

4) 테이블과 인덱스를 테이블스페이스에 저장을 하고 테이블스페이스는 몇개의 서버 파일이나 디스크 파티션으로 구성되어 있습니다. 이것은 MyISAM과 다른 점인데, MyISAM은 테이블과 인덱스를 각각 분리된 파일로 관리합니다. 

5) innoDB 테이블은 OS의 파일 사이즈 한계가 2GB이더라도 상관없이 어느 크기가 가질 수 있습니다.

6) innoDB은 높은 퍼포먼스가 필요한 대용량 사이트에 적합합니다.

참조 : 

joridari.tistory.com/15

select version();

#MariaDB버전

MariaDB의 통계정보

MariaDB도 비용기반의 옵티마이저(Cost-based Optimizer, CBO)를 채택하고 있기 때문에 통계정보가 존재한다.

하지만 다른 RDBMS와 같이 다양한 통계정보가 존재하는 것은 아니고, 대략의 레코드 건수와 인덱스의 유니크한 값의 갯수 정도가 전부이다.

mysql database의 

innodb_index_stats, innodb_table_stats에 이 통계정보가 존재한다.

통계정보의 생성은 테이블생성시에 stats_persistent의 값에 따라 생성여부가 정해지는데,

default : 테이블을 생성할 때 별도로 stats_persistent 옵션을 설정하지 않은 것과 동일하며, 테이블의 통계를 영구적으로 관리할지 말지를 innodb_stats_persistent 시스템 설정 변수의 값으로 결정한다.

0 : 테이블의 통계 정보를 mysql 데이터베이스의 innodb_index_stats와 innodb_table_stats에 저장하지 않음

1 : 테이블의 통계 정보를 mysql 데이터베이스의 innodb_index_stats와 innodb_table_stats에 저장함.

의 값을 가질 수 있다.

예) 테이블 생성시에 통계정보 생성 지정 방법

통계정보가 새로 수집되는 경우

- 테이블이 새로 오픈되는 경우

- 테이블의 레코드가 대량으로 변경되는 경우(테이블의 전체 레코드 중에서 1/16 정도의 update 또는 insert나 delete가 실행되는 경우)

- analyze table 명령이 실행되는 경우

- show tables status 명령이나 show index from 명령이 실행되는 경우

- innoDB 모니터가 활성화되는 경우

- innodb_stats_on_metadata 시스템 설정이 on된 상태에서 show tables status 명령이 실행되는 경우

통계정보가 변경되는 것을 조정하기 위한 시스템 설정변수

stats_auto_recalc

1 : 테이블의 통계 정보를 MySQL 5.5 이전의 방식대로 자동 수집하게 된다.

0 : 테이블의 통계 정보는 analyze table 명령을 실행할 때에만 수집된다.

default : 테이블을 생성할 때 별도로 stats_auto_recalc 옵션을 설정하지 않은 것과 동일하며, 테이블의 통계 정보 수집을 innodb_stats_auto_recalc 시스템 설정 변수의 값으로 결정한다.

참고 : 

Real MariaDB(이성욱 저) P.119

MariaDB / MySQL 쿼리 실행 구조

[쿼리의 실행 과정]

1. SQL 파싱(SQL Parsing)

  : 사용자로부터 요청된 SQL 문장을 잘게 쪼개서 MariaDB 서버가 이해할 수 있는 수준으로 분리(파스 트리)한다.

    MariaDB 엔진에서 처리

2. SQL의 파싱 정보(파스 트리)를 확인하면서 어떤 테이블부터 읽고 어떤 인덱스를 이용해 테이블을 읽을지 선택한다.

  - 불필요한 조건의 제거 및 복잡한 연산의 단순화

  - 여러 테이블의 조인이 있는 경우 어떤 순서로 테이블을 읽을지 결정

  - 각 테이블에 사용된 조건과 인덱스 통계 정보를 이용해 사용할 인덱스 결정

  - 가져온 레코드들을 임시 테이블에 넣고 다시 한번 가공해야 하는지 결정

  MariaDB 엔진에서 처리

3. 두 번째 단계에서 결정된 테이블의 읽기 순서나 선택된 인덱스를 이용해 스토리지 엔진으로부터 데이터를 가져온다.

  - 수립된 실행 계획대로 스토리지 엔진에 레코드를 읽어오도록 요청하고, MariaDB 엔진에서는 스토리지 엔진으로부터 받은 레코드를 조인하거나 정렬하는 작업을 수행한다.

 MariaDB 엔진 + 스토리지 엔진이 동시에 참여해서 처리

[쿼리 실행 순서]

1. 클라이언트는 서버로 SQL문을 전송한다.

2. 서버는 쿼리 캐시를 확인하여 캐시에 저장된 데이터가 있다면 저장된 결과를 반환한다. 그헣지 않으면 다음 단계로 통과시킨다.

3. 서버는 구문 분석 및 전처리기에서 쿼리에 구조적인 문제가 없는지 확인 후 옵티마이저는 SQL을 최적화한다.

4. 쿼리 실행 엔진은 스토리지 엔진 API를 호출하여 계획을 실행한다.

5. 서버는 클라이언트에게 결과를 반환한다.

[Parser]

Parser는 사용자 요청으로 들어온 쿼리 문장을 토큰(SQL엔진이 인식할 수 있는 형태)으로 분리해 트리 형태의 구조로 만드는 작업을 의미한다. 쿼리 문장의 기본 문법 오류는 이 과정에서 발견되어 사용자에게 오류 메시지를 전달하게 된다.

[Preprocessor]

파서 과정에서 만들어진 파서 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인한다. 각 토큰을 테이블 이름이나 컬럼 이름 또는 내장 함수와 같은 개체를 매핑하여 해당 객체의 존재 여부와 객체의 접근 권한 등을 확인하는 과정을 수행한다. 실제 존재하지 않거나 권한이 없는 객체의 토큰은 이 단계에서 걸러진다.

[Optimizer]

옵티마이저는 요청된 쿼리 문장을 어떻게 처리할지를 결정하는 두뇌 역할을 한다. 옵티마이저는 가장 적은 비용으로 가장 빠르게 처리할 수 있는 방법을 결정하기 위해 다양한 통계 자료를 활용한다. 옵티마이저의 선택에 따라서 쿼리 성능에 영향을 미치므로 특성을 잘 이해할 필요가 있다.

[Query execution engine]

옵티마이저가 최적의 실행 계획을 결정하면 이를 직접 실행하는 부분을 담당한다. 스토리지 엔진의 API를 호출한다.

참고 : 

sungwookkang.com/m/155?category=618835

RealMariaDB (이성욱 저) P.117 ~ P.122)

my.ini

 => 설정 파일. 오라클 DBMS에서 파라미터 파일과 유사한 파일이다.

      아래의 파라미터의 base_dir/bin 밑에 *.ini 파일이 존재한다.

파라미터 조회 방법