㈜유미테크
MariaDB
목차
1. MariaDB
2. 개요
3. 옵티마이저
4. 쿼리 작성 주의사항 및 최적화
5. 파티션/스토어드 프로시저
MariaDB2
MariaDB
MariaDB3
MariaDB
• 개 발 자 : Monty Program Ab
• 발 표 일 : 2009-01-22
• 종 류 : 관계형 데이터베이스 관리시스템(RDBMS)
• 운영체제 : 크로스 플랫폼(윈도, 리눅스, 솔라리스 등)
• 라이선스 : GPL V2 라이선스
• MySQL과 동일한 소스코드 기반
• Oracle의 MySQL 라이선스 반발에 의해 개발됨
MariaDB4
MySQL MariaDB
5.1
5.1
5.2
5.3
5.5 5.5
5.6 10.0
1. 개요
MariaDB5
1.1. 인덱스
1.2. 함수
1.3. 데이터타입
1.1. 인덱스
MariaDB6
• Index 생성시 Create Index 구문 또는 Alter table 구문을 사용
• Index 생성시 metadata lock이 걸리며 이는 인덱스를 생성시 해당
테이블은 R/W lock 발생
• MariaDB의 Index Type은 BTREE, RTREE, HASH 타입 지원
• 인덱스 생성 예시1
• 인덱스 생성 예시2
1.2. 함수
MariaDB7
• 함수 특징
– 스토어드 함수 생성시 함수는 읽기 전용이므로, IN 또는 OUT 파라미터 보유하지 않음
– 정의부에 반드시 Returns 키워드를 이용해 반환되는 값의 타입을 명시
• 함수 생성시 주의 사항
– 생성시 delimiter 명령어를 통해서 종료문자를 변경시킨 후 생성
– 민감한 정보를 저장하는 DB보안을 위해 SQL SECURITY = INVOKER로 사용 권장
1.2. 함수
MariaDB8
• 함수 생성 및 실행 예시
• 함수 생성 확인 예시
1.3. 데이터 타입
MariaDB9
• 숫자 타입
타입 MariaDB Size
Integer Type
BIGINT 8 bytes
DECIMAL(M,D)
DOUBLE 8 bytes
FLOAT 4 bytes
INT 4 bytes
INTEGER 4 bytes
MEDIUMINT 3 bytes
NUMERIC
REAL 8 bytes
SMALLINT 2 bytes
1.3. 데이터 타입
MariaDB10
• 문자 타입
• 주의 사항
– TEXT, Blob 타입을 제외한 전체 칼럼의 크기는 65KB를 초과할 수 없음
(다른 컬럼에서 40KB를 사용하고 있다면 그 레코드의 VARCHAR타입은 24KB만 사용가능)
– CHAR또는 VARCHAR뒤의 지정 숫자는 칼럼의 바이트가 아니라 문자의 수를 의미
타입 설명 예시
CHAR
• 고정길이 칼럼 타입
• 0~255 byte 지원 CHAR(10) : 10개의 문자 저장
VARCHAR
• 가변길이 칼럼 타입
• 0~65536 byte 지원 VARCHAR(10) : 10개의 문자 저장
1.3. 데이터 타입
MariaDB11
• 문자 집합(Character_set)
Character_set 설명
Character_set_system MaraiDB 서버가 식별자를 저장할때 사용하는 문자집함
Character_set_server MariaDB 서버의 기본 문자집합
Character_set_database
DB 생성시 기본 문자집함
Character_set_client Client가 보낸 SQL문장은 이 변수에 설정된 문자집합으로 인코
딩해서 MariaDB서버로 전송
Character_set_connection Client로부터 전달받은 SQL문장을 처리하기 위해 이 변수값으
로 문자집합을 변환
Character_set_results
쿼리 처리 결과를 Client로 전송시 사용하는 문자집함
2. 옵티마이저
MariaDB12
2.1 실행 계획(explain)
2.1. 실행 계획
• MariaDB의 옵티마이저는 CBO(Cost-Based Optimizer) 방법으로 산출
• MariaDB의 실행계획은 explain 명령어를 수행하면 확인 가능
– MariaDB의 옵티마이저는 시스템 테이블에 저장된 통계정보로 최적의 실행계획 산출
MariaDB13
2.1. 실행 계획
• 쿼리 실행이 좋은 경우
– Distinct
– Using Index
– Using Index for group-by
• 쿼리 실행이 나쁜 경우
– Using filesort
– Using join buffer
– Using temporary
– Using Where
MariaDB14
3. 쿼리 작성 시 주의사항 및 최적화
MariaDB15
3.1 Sub Query 사용 시 주의사항
3.2 SQL Hint
3.3 쿼리 프로파일링
3.1. Sub Query 사용시 주의사항
• 상관 서브 쿼리
– 외부에서 정의된 테이블의 칼럼을 조회해서 검색을 수행하는 쿼리
– 상관 서브쿼리는 독립적으로 실행되지 못하고 항상 외부쿼리가 실행된 후 그
결과값이 전달되어야 사용 가능
MariaDB16
3.1. Sub Query 사용시 주의사항
• Sub Query 제약 사항
– Sub Query는 대부분 쿼리 문장에서 사용 가능
– LIMIT 절과 LOAD DATE INFILE의 파일명에는 사용 불가
– IN 연산자 안에서 ORDER BY와 LIMIT을 동시 사용 불가
– FROM 절에서는 상관 서브쿼리 형태로 사용 불가
– 서브 쿼리를 이용해 하나의 테이블에 대해 읽고 쓰기를 동시 사용 불가
MariaDB17
3.1. Sub Query 사용시 주의사항
• MariaDB Sub Query 최적화
– WHERE 절에 IN 연산자를 상수와 함께 사용할 때 동등 비교로 처리되므로 최
적화 된 성능 보장
– WHERE 절에 IN 연산자를 서브쿼리를 사용하면 EXISTS형태로 변환되어 상관
서브 쿼리 형태로 실행
– MariaDB에서는 IN + Subquery 형태의 구문에 대해 최적화 실행중
MariaDB18
3.2. HINT
• SQL문에 정보를 주어 SQL문 실행에 빠른 결과를 가져오려는 것
• STRAIGHT JOIN HINT
– 옵티마이저 실행 계획을 무시하고 테이블 순서 대로 JOIN
• USE INDEX
– 가장 자주 사용되는 힌트로 옵티마이저에게 특정 테이블의 인덱스를 사
용하도록 권장
• FORCE INDEX
– USE INDEX보다 옵티마이저에게 더 강한 영향을 주는 힌트
• IGNORE INDEX
– 특정 인덱스를 사용하지 못하도록 옵티마이저를 유도
MariaDB19
3.2. HINT
• 쿼리 캐시 HINT
– MariaDB는 쿼리 캐시를 사용할지 여부를 선택할수 있도록 힌트 제공
– SQL_CACHE
• Query_cache_type이 1 또는 2로 설정되어 있는 경우 쿼리 캐시를 사용
– SQL_NOCACHE
• 어떠한 경우에도 쿼리 캐시 사용 불가
MariaDB20
3.3. 쿼리 프로파일링
• MariaDB는 쿼리가 처리되는 동안 각 단계별 작업 시간에 대한 통계정보 제공
• 쿼리 프로파일링 기능을 통해 쿼리의 성능을 예측
• 프로파일링 활성화
– SET PROFILING=1 or 0 명령어를 이용하여 프로파일링 on/off 가능(default : 0)
• 쿼리 실행 후 각 쿼리에 대한 프로파일 확인
– SHOW PROFILES / SHOW PROFILE
– SHOW PROFILE FOR QUERY <쿼리번호>
– SHOW PROFILE CPU FOR QUERY <쿼리번호>
– SHOW PROFILE SOURCE FOR QUERY <쿼리번호>
MariaDB21
3.3. 쿼리 프로파일링
• MariaDB는 쿼리가 처리되는 동안 각 단계별 작업 시간에 대한 통계정보 제공
• 쿼리 프로파일링 기능을 통해 쿼리의 성능을 예측
• 프로파일링 활성화
– SET PROFILING=1 or 0 명령어를 이용하여 프로파일링 on/off 가능(default : 0)
• 쿼리 실행 후 각 쿼리에 대한 프로파일 확인
– SHOW PROFILES / SHOW PROFILE
– SHOW PROFILE FOR QUERY <쿼리번호>
– SHOW PROFILE CPU FOR QUERY <쿼리번호>
– SHOW PROFILE SOURCE FOR QUERY <쿼리번호>
MariaDB22
• 쿼리 프로파일링 활성화
• SHOW PROFILES 결과
3.3. 쿼리 프로파일링
MariaDB23
3.3. 쿼리 프로파일링
• SHOW PROFILE FOR QUERY 6
MariaDB24
• SHOW PROFILE CPU FOR QUERY 6
4. 파티션 / 스토어드 프로시저
MariaDB25
4.1 파티션
4.2 스토어드 프로시저
4.1. 파티션
• 파티션 특징
– MariaDB에서 Partition은 저장할 데이터를 분할하여 관리함으로써
보다 빠른 데이터처리 가능
– Partitioning 하지 않고 하나의 큰 테이블로 사용할 경우
그만큼 인덱스도 커지고 물리적인 공간도 많이 필요
– Partition을 하게 되면 데이터와 인덱스를 조각화하여
물리적 공간을 효율적으로 사용 가능
• 파티션 장점
– 특정 데이터 집합의 추가/삭제가 간편
– 데이터 검색 시 특정 파티션만 읽어서 속도를 향상 가능
– 병렬처리가 가능
– 한 테이블에 너무 많은 데이터가 입력되었을 시 발생하는 속도 저하를 방지
MariaDB26
4.1. 파티션
• 파티션 사용시 주의사항
– 모든 파티션은 동일한 스토리지 엔진 사용
– 테이블과 인덱스를 별도로 파티션 불가(테이블과 인덱스 같이 해야함)
– 파티션 된 테이블은 foregin key를 지원불가
– 파티션 된 테이블은 FullText Index를 지원 불가
– 파티션 된 테이블은 Geometry 칼럼 타입 지원 불가
– 한 테이블당 파티션의 개수는 최대 1024개
– Temp Table 은 파티션 사용 불가
– Partition 값은 반드시 정수형 타입
MariaDB27
4.1. 파티션
• MariaDB 파티션 종류
– Range Partitioning
• 파티션 키의 연속된 범위로 파티션을 정의
• 날짜 기반 데이터가 누적되고 년도,월,일 단위로 분석, 삭제 할 경우
• 범위 기반으로 데이터를 여러 파티션에 균등하게 나눌 수 있을 경우
• 파티션 키 위주로 검색이 자주 실행 될 경우
• 예) 회원 가입 일자별로 분할, 상품 판매 월별로 분할 등…
– List Partitioning
• 파티션 키 값이 코드 값이나 카테고리와 같이 고정 값일 경우
• 키 값이 연속적이지 않고 정렬순서와 관계없이 파티션을 해야 할 경우
• 파티션 키 값을 기준으로 레코드 건수가 균일하고 검색 조건에 파티션 키가 자주 사용 될 때
• 예) 회원 데이터를 지역별로 분할, 판매 데이터를 매장별로 분할 등…
MariaDB28
4.1. 파티션
• MariaDB 파티션 종류
– Hash Partitioning
• Hash 함수에 의해 레코드가 저장될 파티션을 결정하는 방식
• Range, List 로 데이터를 균등하게 나누는 것이 어려울 때
• 테이블의 모든 레코드가 비슷한 사용 빈도를 보이지만
너무 커서 파티션 적용이 필요한 경우
• 예) 상품 주문 일련번호 등
– Key Partitioning
• Hash 파티션과 동일하지만 Hash 값을 계산하는 방법을 사용자가 지정 가능
• 키 파티션은 선정된 파티션 키 값에 대하여 내부적인 함수를 이용하여 Hash값을 계산하고
그 값에 mod를 적용하여 저장할 파티션을 결정
MariaDB29
4.2. 스토어드 프로시저
• MariaDB의 스토어드 프로시저는 독립적으로 호출
• SELECT 나 UPDATE 등의 SQL 문장에서 스토어드 프로시저 참조 불가
• 스토어드 프로시저를 생성 시 주의 사항
– 생성시 DELIMITER 명령어를 통해서 종료문자를 변경시킨 후 생성
– 민감한 정보를 저장하는 DB보안을 위해서 SQL SECURITY = INVOKER로 사용
– 프로시저 생성시 가능하면 DETERMINISTIC 옵션을 정의
– 생성한 프로시저는 CALL 함수를 통해서 호출
MariaDB30

Maria db

  • 1.
  • 2.
    목차 1. MariaDB 2. 개요 3.옵티마이저 4. 쿼리 작성 주의사항 및 최적화 5. 파티션/스토어드 프로시저 MariaDB2
  • 3.
  • 4.
    MariaDB • 개 발자 : Monty Program Ab • 발 표 일 : 2009-01-22 • 종 류 : 관계형 데이터베이스 관리시스템(RDBMS) • 운영체제 : 크로스 플랫폼(윈도, 리눅스, 솔라리스 등) • 라이선스 : GPL V2 라이선스 • MySQL과 동일한 소스코드 기반 • Oracle의 MySQL 라이선스 반발에 의해 개발됨 MariaDB4 MySQL MariaDB 5.1 5.1 5.2 5.3 5.5 5.5 5.6 10.0
  • 5.
    1. 개요 MariaDB5 1.1. 인덱스 1.2.함수 1.3. 데이터타입
  • 6.
    1.1. 인덱스 MariaDB6 • Index생성시 Create Index 구문 또는 Alter table 구문을 사용 • Index 생성시 metadata lock이 걸리며 이는 인덱스를 생성시 해당 테이블은 R/W lock 발생 • MariaDB의 Index Type은 BTREE, RTREE, HASH 타입 지원 • 인덱스 생성 예시1 • 인덱스 생성 예시2
  • 7.
    1.2. 함수 MariaDB7 • 함수특징 – 스토어드 함수 생성시 함수는 읽기 전용이므로, IN 또는 OUT 파라미터 보유하지 않음 – 정의부에 반드시 Returns 키워드를 이용해 반환되는 값의 타입을 명시 • 함수 생성시 주의 사항 – 생성시 delimiter 명령어를 통해서 종료문자를 변경시킨 후 생성 – 민감한 정보를 저장하는 DB보안을 위해 SQL SECURITY = INVOKER로 사용 권장
  • 8.
    1.2. 함수 MariaDB8 • 함수생성 및 실행 예시 • 함수 생성 확인 예시
  • 9.
    1.3. 데이터 타입 MariaDB9 •숫자 타입 타입 MariaDB Size Integer Type BIGINT 8 bytes DECIMAL(M,D) DOUBLE 8 bytes FLOAT 4 bytes INT 4 bytes INTEGER 4 bytes MEDIUMINT 3 bytes NUMERIC REAL 8 bytes SMALLINT 2 bytes
  • 10.
    1.3. 데이터 타입 MariaDB10 •문자 타입 • 주의 사항 – TEXT, Blob 타입을 제외한 전체 칼럼의 크기는 65KB를 초과할 수 없음 (다른 컬럼에서 40KB를 사용하고 있다면 그 레코드의 VARCHAR타입은 24KB만 사용가능) – CHAR또는 VARCHAR뒤의 지정 숫자는 칼럼의 바이트가 아니라 문자의 수를 의미 타입 설명 예시 CHAR • 고정길이 칼럼 타입 • 0~255 byte 지원 CHAR(10) : 10개의 문자 저장 VARCHAR • 가변길이 칼럼 타입 • 0~65536 byte 지원 VARCHAR(10) : 10개의 문자 저장
  • 11.
    1.3. 데이터 타입 MariaDB11 •문자 집합(Character_set) Character_set 설명 Character_set_system MaraiDB 서버가 식별자를 저장할때 사용하는 문자집함 Character_set_server MariaDB 서버의 기본 문자집합 Character_set_database DB 생성시 기본 문자집함 Character_set_client Client가 보낸 SQL문장은 이 변수에 설정된 문자집합으로 인코 딩해서 MariaDB서버로 전송 Character_set_connection Client로부터 전달받은 SQL문장을 처리하기 위해 이 변수값으 로 문자집합을 변환 Character_set_results 쿼리 처리 결과를 Client로 전송시 사용하는 문자집함
  • 12.
  • 13.
    2.1. 실행 계획 •MariaDB의 옵티마이저는 CBO(Cost-Based Optimizer) 방법으로 산출 • MariaDB의 실행계획은 explain 명령어를 수행하면 확인 가능 – MariaDB의 옵티마이저는 시스템 테이블에 저장된 통계정보로 최적의 실행계획 산출 MariaDB13
  • 14.
    2.1. 실행 계획 •쿼리 실행이 좋은 경우 – Distinct – Using Index – Using Index for group-by • 쿼리 실행이 나쁜 경우 – Using filesort – Using join buffer – Using temporary – Using Where MariaDB14
  • 15.
    3. 쿼리 작성시 주의사항 및 최적화 MariaDB15 3.1 Sub Query 사용 시 주의사항 3.2 SQL Hint 3.3 쿼리 프로파일링
  • 16.
    3.1. Sub Query사용시 주의사항 • 상관 서브 쿼리 – 외부에서 정의된 테이블의 칼럼을 조회해서 검색을 수행하는 쿼리 – 상관 서브쿼리는 독립적으로 실행되지 못하고 항상 외부쿼리가 실행된 후 그 결과값이 전달되어야 사용 가능 MariaDB16
  • 17.
    3.1. Sub Query사용시 주의사항 • Sub Query 제약 사항 – Sub Query는 대부분 쿼리 문장에서 사용 가능 – LIMIT 절과 LOAD DATE INFILE의 파일명에는 사용 불가 – IN 연산자 안에서 ORDER BY와 LIMIT을 동시 사용 불가 – FROM 절에서는 상관 서브쿼리 형태로 사용 불가 – 서브 쿼리를 이용해 하나의 테이블에 대해 읽고 쓰기를 동시 사용 불가 MariaDB17
  • 18.
    3.1. Sub Query사용시 주의사항 • MariaDB Sub Query 최적화 – WHERE 절에 IN 연산자를 상수와 함께 사용할 때 동등 비교로 처리되므로 최 적화 된 성능 보장 – WHERE 절에 IN 연산자를 서브쿼리를 사용하면 EXISTS형태로 변환되어 상관 서브 쿼리 형태로 실행 – MariaDB에서는 IN + Subquery 형태의 구문에 대해 최적화 실행중 MariaDB18
  • 19.
    3.2. HINT • SQL문에정보를 주어 SQL문 실행에 빠른 결과를 가져오려는 것 • STRAIGHT JOIN HINT – 옵티마이저 실행 계획을 무시하고 테이블 순서 대로 JOIN • USE INDEX – 가장 자주 사용되는 힌트로 옵티마이저에게 특정 테이블의 인덱스를 사 용하도록 권장 • FORCE INDEX – USE INDEX보다 옵티마이저에게 더 강한 영향을 주는 힌트 • IGNORE INDEX – 특정 인덱스를 사용하지 못하도록 옵티마이저를 유도 MariaDB19
  • 20.
    3.2. HINT • 쿼리캐시 HINT – MariaDB는 쿼리 캐시를 사용할지 여부를 선택할수 있도록 힌트 제공 – SQL_CACHE • Query_cache_type이 1 또는 2로 설정되어 있는 경우 쿼리 캐시를 사용 – SQL_NOCACHE • 어떠한 경우에도 쿼리 캐시 사용 불가 MariaDB20
  • 21.
    3.3. 쿼리 프로파일링 •MariaDB는 쿼리가 처리되는 동안 각 단계별 작업 시간에 대한 통계정보 제공 • 쿼리 프로파일링 기능을 통해 쿼리의 성능을 예측 • 프로파일링 활성화 – SET PROFILING=1 or 0 명령어를 이용하여 프로파일링 on/off 가능(default : 0) • 쿼리 실행 후 각 쿼리에 대한 프로파일 확인 – SHOW PROFILES / SHOW PROFILE – SHOW PROFILE FOR QUERY <쿼리번호> – SHOW PROFILE CPU FOR QUERY <쿼리번호> – SHOW PROFILE SOURCE FOR QUERY <쿼리번호> MariaDB21
  • 22.
    3.3. 쿼리 프로파일링 •MariaDB는 쿼리가 처리되는 동안 각 단계별 작업 시간에 대한 통계정보 제공 • 쿼리 프로파일링 기능을 통해 쿼리의 성능을 예측 • 프로파일링 활성화 – SET PROFILING=1 or 0 명령어를 이용하여 프로파일링 on/off 가능(default : 0) • 쿼리 실행 후 각 쿼리에 대한 프로파일 확인 – SHOW PROFILES / SHOW PROFILE – SHOW PROFILE FOR QUERY <쿼리번호> – SHOW PROFILE CPU FOR QUERY <쿼리번호> – SHOW PROFILE SOURCE FOR QUERY <쿼리번호> MariaDB22
  • 23.
    • 쿼리 프로파일링활성화 • SHOW PROFILES 결과 3.3. 쿼리 프로파일링 MariaDB23
  • 24.
    3.3. 쿼리 프로파일링 •SHOW PROFILE FOR QUERY 6 MariaDB24 • SHOW PROFILE CPU FOR QUERY 6
  • 25.
    4. 파티션 /스토어드 프로시저 MariaDB25 4.1 파티션 4.2 스토어드 프로시저
  • 26.
    4.1. 파티션 • 파티션특징 – MariaDB에서 Partition은 저장할 데이터를 분할하여 관리함으로써 보다 빠른 데이터처리 가능 – Partitioning 하지 않고 하나의 큰 테이블로 사용할 경우 그만큼 인덱스도 커지고 물리적인 공간도 많이 필요 – Partition을 하게 되면 데이터와 인덱스를 조각화하여 물리적 공간을 효율적으로 사용 가능 • 파티션 장점 – 특정 데이터 집합의 추가/삭제가 간편 – 데이터 검색 시 특정 파티션만 읽어서 속도를 향상 가능 – 병렬처리가 가능 – 한 테이블에 너무 많은 데이터가 입력되었을 시 발생하는 속도 저하를 방지 MariaDB26
  • 27.
    4.1. 파티션 • 파티션사용시 주의사항 – 모든 파티션은 동일한 스토리지 엔진 사용 – 테이블과 인덱스를 별도로 파티션 불가(테이블과 인덱스 같이 해야함) – 파티션 된 테이블은 foregin key를 지원불가 – 파티션 된 테이블은 FullText Index를 지원 불가 – 파티션 된 테이블은 Geometry 칼럼 타입 지원 불가 – 한 테이블당 파티션의 개수는 최대 1024개 – Temp Table 은 파티션 사용 불가 – Partition 값은 반드시 정수형 타입 MariaDB27
  • 28.
    4.1. 파티션 • MariaDB파티션 종류 – Range Partitioning • 파티션 키의 연속된 범위로 파티션을 정의 • 날짜 기반 데이터가 누적되고 년도,월,일 단위로 분석, 삭제 할 경우 • 범위 기반으로 데이터를 여러 파티션에 균등하게 나눌 수 있을 경우 • 파티션 키 위주로 검색이 자주 실행 될 경우 • 예) 회원 가입 일자별로 분할, 상품 판매 월별로 분할 등… – List Partitioning • 파티션 키 값이 코드 값이나 카테고리와 같이 고정 값일 경우 • 키 값이 연속적이지 않고 정렬순서와 관계없이 파티션을 해야 할 경우 • 파티션 키 값을 기준으로 레코드 건수가 균일하고 검색 조건에 파티션 키가 자주 사용 될 때 • 예) 회원 데이터를 지역별로 분할, 판매 데이터를 매장별로 분할 등… MariaDB28
  • 29.
    4.1. 파티션 • MariaDB파티션 종류 – Hash Partitioning • Hash 함수에 의해 레코드가 저장될 파티션을 결정하는 방식 • Range, List 로 데이터를 균등하게 나누는 것이 어려울 때 • 테이블의 모든 레코드가 비슷한 사용 빈도를 보이지만 너무 커서 파티션 적용이 필요한 경우 • 예) 상품 주문 일련번호 등 – Key Partitioning • Hash 파티션과 동일하지만 Hash 값을 계산하는 방법을 사용자가 지정 가능 • 키 파티션은 선정된 파티션 키 값에 대하여 내부적인 함수를 이용하여 Hash값을 계산하고 그 값에 mod를 적용하여 저장할 파티션을 결정 MariaDB29
  • 30.
    4.2. 스토어드 프로시저 •MariaDB의 스토어드 프로시저는 독립적으로 호출 • SELECT 나 UPDATE 등의 SQL 문장에서 스토어드 프로시저 참조 불가 • 스토어드 프로시저를 생성 시 주의 사항 – 생성시 DELIMITER 명령어를 통해서 종료문자를 변경시킨 후 생성 – 민감한 정보를 저장하는 DB보안을 위해서 SQL SECURITY = INVOKER로 사용 – 프로시저 생성시 가능하면 DETERMINISTIC 옵션을 정의 – 생성한 프로시저는 CALL 함수를 통해서 호출 MariaDB30

Editor's Notes

  • #5 마이클 몬티 와이드니어스 대부분의 소프트웨어에 대한 라이선스는 소프트웨어를 공유하거나 수정할 수 있는 자유를 금지하기 위하여 고안되었다. 반면에 GNU 일반 공중 라이선스는 자유 소프트웨어를 공유하고 수정할 수 있는 자유를 보장하기 위해 의도되었다
  • #7 인덱스란 간단한 용어로 목차 라고 할 수 있다. - 목차를 지정하여 검색속도가 향상되지만 INSERT, UPDATE, DELETE가 자주 발생한다면 성능이 하락할 수 있다.
  • #21 쿼리 캐시(Query Cache)는 SELECT 쿼리의 결과(Result Set)을 캐시하고 있다가, 동일한 SELECT 쿼리에 대해서 캐시된 결과를 리턴해 주는 기능이다
  • #31 자주 사용되거나 복잡한 과정을 가지고 있는 쿼리를 저장하여 하나의 개체로 관리하는 것  - 서버에 미리 컴파일 되어 저장 되어 있음 - SQL서버에는 기본적으로 시스템 정보를 사용하고 갱신하기 위해 여러정보를 스토어드 프로시져로 만들어  master 데이터베이스에 가지고 있음  - 사용자가 원하는 작업을 위해 직접 스토어드 프로시저를 생성할 수 있음