PHP 데이터베이스 기본

트랜잭션

트랜잭션의 4가지 특성(ACID):

  원자성, 일관성, 격리성, 내구성
- (1) 원자성
전체 트랜잭션에서 필요한 모든 작업 성공적으로 제출되거나 모두 실패하여 롤백되어야 합니다.
- (2) 일관성
작업 전후에 데이터베이스 내 데이터의 일관성을 보장합니다. (예를 들어, 한 사용자의 여러 계정 간 이체를 하더라도 해당 사용자의 총 금액은 변경되지 않습니다.)
- (3) 격리
격리는 제출하기 전에 데이터베이스의 데이터를 수정하는 트랜잭션이 필요합니다. 다른 트랜잭션에는 표시되지 않습니다. (즉, 트랜잭션은 순차적으로 실행되어야 함)

SQL 표준에는 4가지 격리 유형이 정의되어 있습니다. (다음 격리는 낮은 수준에서 높은 수준, 동시성 수준은 높은 수준에서 낮은 수준입니다)

1) 커밋되지 않은 읽기는 가장 낮은 격리 수준으로, 다른 트랜잭션이 커밋되지 않은 데이터를 볼 수 있도록 허용하여 더티 읽기로 이어집니다.

2) Read Committed
데이터베이스는 읽기-쓰기가 분리되어 있기 때문에 트랜잭션을 읽을 때 읽기 잠금을 획득하지만 읽기 잠금이 해제된 후 즉시 해제됩니다. 다시 읽어보면 이전과 이후의 데이터 읽기 결과가 달라서 반복해서 읽을 수 없다는 것을 알 수 있습니다. (읽기 잠금은 트랜잭션 제출 후 해제할 필요가 없으며 쓰기 잠금은 트랜잭션 제출 후 해제해야 함)

3) 반복 읽기
select로 얻은 모든 데이터는 수정할 수 없으므로 트랜잭션이 수행됩니다. 피할 수 있습니다. 읽기 전후에 일관성이 없는 상황입니다. 하지만 다른 트랜잭션은 현재 선택된 데이터를 변경할 수 없지만 데이터를 추가할 수 있기 때문에 팬텀 읽기를 제어할 수 있는 방법은 없습니다.

4) 직렬화 가능
모든 트랜잭션은 차례로 실행됩니다. 팬텀 읽기를 피할 수 있습니다. 읽기, 잠금 기반 동시성 제어를 구현하는 데이터베이스의 경우 직렬화에서는 범위 쿼리 실행 시 범위 잠금을 획득해야 합니다. 데이터베이스가 잠금 기반 동시성 제어를 구현하지 않으면 직렬 작업을 위반하는 트랜잭션이 감지됩니다. , 트랜잭션을 롤백해야 합니다.

요약: 4가지 수준이 점차 강화되며 각 수준에서 문제가 해결됩니다. 트랜잭션 수준이 높아질수록 대부분의 환경에서 성능이 저하됩니다(읽기 커밋 사용 가능)

격리 level               더티 읽기는 다시 읽을 수 없습니다. >직렬화 가능    불가능   불가능

요약: 커밋되지 않은 읽기는 더티 읽기의 원인이 됩니다. >커밋된 읽기는 더티 읽기를 해결하지만 반복 불가능한 읽기를 유발합니다.>반복 읽기는 더티 읽기를 해결합니다. 일관되지 않은 읽기 결과 문제가 있지만 팬텀 읽기가 발생함(이전은 아니지만 현재) -> 직렬화 가능은 팬텀 읽기를 해결하지만 많은 범위 잠금을 추가하여 잠금 시간 초과가 발생할 수 있습니다. 트랜잭션이 커밋되면 수정 사항은 데이터베이스에 영구적으로 저장됩니다. 시스템이 충돌하더라도 제출된 수정 데이터는 손실되지 않습니다.

더티 읽기, 반복 불가능 읽기 및 팬텀 읽기

(1) 더티 읽기(롤백 작업용): 트랜잭션 T1이 레코드 행의 내용을 업데이트했지만 결과를 커밋하지 않았습니다. 수정, 트랜잭션 T2는 업데이트된 행을 읽은 다음 T1은 롤백 작업을 수행하여 방금 수정한 내용을 취소합니다. 이제 T2가 읽은 행 수가 유효하지 않습니다(한 트랜잭션이 다른 트랜잭션을 읽음)

(2) 반복 불가능한 읽기(수정된 작업의 경우): 트랜잭션 T1이 레코드 행을 읽은 후 T2가 수정했습니다. T1이 방금 읽은 레코드 행, T1이 다시 레코드 행을 읽어 결과가 방금 읽은 결과와 다르다는 것을 발견했습니다.

(3) 팬텀 읽기(업데이트 작업용): 트랜잭션 T1은 지정된 where 절에서 반환된 결과 집합을 읽은 다음 트랜잭션 T2는 T1의 요구 사항을 정확히 충족할 수 있는 새 레코드 행을 삽입합니다. 쿼리 기준이 사용되었습니다. 그런 다음 T1은 테이블을 다시 검색하지만 T2가 삽입한 데이터를 다시 봅니다. (처음에는 못봤는데 두번째에 봤어요)

인덱스

2.1 데이터베이스 인덱스의 장점과 단점은 무엇이며, 데이터베이스 인덱스는 언제 실패하나요?

인덱스의 특징

(1) 데이터베이스 검색 속도를 높일 수 있습니다.

(2) 뷰가 아닌 테이블에서만 생성할 수 있습니다.

(3)

(4) 최적화 숨기기에 인덱스를 사용할 수 있습니다.

(5) 테이블에서는 한 번에 하나의 인덱스만 사용할 수 있습니다.

인덱스의 장점

(1) 데이터베이스 테이블에 있는 각 데이터 행의 고유성을 보장하기 위해 고유한 인덱스를 만듭니다.
(2) 인덱스를 만드는 주요 이유인 데이터 검색 속도를 크게 높입니다. 3) 데이터베이스 테이블 간의 링크를 가속화하는 것은 데이터베이스의 참조 무결성을 달성하는 데 특히 의미가 있습니다.
(4) 검색을 위해 그룹화 및 정렬 절을 사용하면 쿼리에서 그룹화 및 정렬에 필요한 시간도 크게 줄일 수 있습니다.
(5) 인덱스를 사용하면 쿼리에 최적화 숨기기를 사용하여 시스템 성능을 향상시킬 수 있습니다.

인덱스의 단점

(1) 인덱스 생성 및 유지 관리에 시간이 걸립니다.

(2) 인덱스는 데이터 테이블이 차지하는 데이터 공간 외에도 클러스터형 인덱스의 경우 일정량의 물리적 공간을 차지합니다. 설정하면 필요한 공간이 더 커집니다.
(3) 테이블에 데이터를 추가, 삭제, 수정할 때 인덱스도 유지해야 하므로 데이터 유지 관리 속도가 줄어듭니다. 분류

(1) 일반 인덱스(제한이 없습니다.)

(2) 고유 인덱스(인덱스 열의 값은 고유해야 하나, null 값은 허용됩니다.)

(3) 기본키 인덱스(Null 값을 허용하지 않는 특별한 고유 인덱스. 일반적으로 테이블 생성과 동시에 기본키 인덱스가 생성된다.)

(4) 복합 인덱스
(5) Clustered Index는 각 테이블 A B+ 트리의 기본 키에 따라 구성되며 전체 테이블의 행 레코드 데이터는 리프 노드에 저장되므로 Clustered 인덱스의 리프 노드도 데이터 페이지가 됩니다.
(6) 비클러스터형 인덱스(보조 인덱스)(페이지 노드는 전체 레코드 행을 저장하지 않습니다).

인덱스 실패

(1) 조건이 있거나 있는 경우에는 인덱스가 있는 조건이 있어도 사용하지 않습니다(사용하거나 최대한 적게). 🎜> (2) 쿼리는 %로 시작합니다. 예를 들어 SELECT * FROM mytable WHEREt Name like'%admin'

(3) 열 유형이 문자열인 경우 조건에서 따옴표로 묶어야 합니다. 그렇지 않으면 인덱스가 사용되지 않습니다.

각 엔진은 인덱스를 지원합니다: (코어는 B-Tree 인덱스를 이해합니다)

일반적으로 사용되는 세 가지 MySQL 엔진 유형 비교: MyISAM, InnoDB 및 Memory

인덱스  MyISAM 인덱스  InnoDB 인덱스  메모리 인덱스

B-TREE 인덱스는 지원

해시 인덱스는 지원하지 않음

R-Tree 인덱스는 지원하지 않음
전체 텍스트 인덱스는 지원하지 않음 데이터베이스 인덱스 구조에서 데이터베이스의

을 지원하지 않습니까? 어떤 상황에서 인덱스를 구축하는 것이 적절한가요?

데이터베이스의 인덱스 구조?

 바이너리 트리를 사용할 경우 바이너리 트리의 깊이가 너무 커서 I/O 읽기 및 쓰기가 너무 자주 발생하여 쿼리 효율성이 떨어지기 때문입니다. 따라서 다중 방향 트리 구조를 사용하면 B-트리에 대한 다양한 작업을 통해 B-트리의 높이를 낮게 유지할 수 있습니다.

B-트리는 균형 다중 경로 검색 트리라고도 합니다. m-차 B-트리의 특징은 다음과 같습니다.

- 1. 트리의 각 노드는 최대 m개의 하위 항목을 포함합니다(m> = 2)

- 2. 루트 노드와 리프 노드를 제외하고 각 노드에는 최소 (ceil(m/2))개의 하위 노드가 있습니다(여기서 ceil(x)는 상한이 있는 함수입니다). >- 3. 루트 노드에는 최소 2개의 하위 노드가 있습니다(B-트리에 하나의 노드(루트 노드)만 포함되어 있지 않은 경우)
- 4. 모든 리프 노드는 동일한 레벨에 나타나며 리프 노드에는 다음이 포함되지 않습니다. 모든 키워드 정보(외부 노드이거나 쿼리가 실패한 노드인 경우 이러한 노드를 가리키는 포인터는 null입니다. 참고: 리프 노드에는 하위 노드와 하위 노드에 대한 포인터가 없습니다. 이러한 노드도 존재하며 트리에서 각각의 널 포인터는 리프 노드로 간주되지만 그려지지는 않습니다.)




B+Tree

어떤 상황에서 인덱스를 생성하는 것이 적합합니까?

(1) order by, group by, discover 키워드 뒤에 자주 나타나는 필드에 대해 인덱스를 생성합니다. >(2) 유니온 및 기타 집합 연산의 결과 집합 필드에 대한 인덱스를 생성하며 인덱스의 목적은 위와 동일합니다.

(3) 쿼리 선택에 자주 사용되는 필드에 대한 인덱스를 생성합니다. >(4) 테이블 링크로 자주 사용되는 속성에 대한 인덱스를 생성합니다. (5) 데이터가 거의 업데이트되지 않는 테이블의 경우 사용자가 종종 몇 개의 필드만 쿼리하는 경우 해당 테이블에 대한 인덱스 생성을 고려하십시오. 필드를 테이블 스캔으로 인덱스 스캔으로 변경합니다.

Mysql 구문 순서

즉, SQL에 다음 키워드가 존재할 때 이 순서를 유지해야 합니다.
select[distinct], from, Join(예: Left Join), on, where , group by, 가지고, Union, order by, 제한

Mysql 실행 순서

즉, 실행 시 sql은
from, on, Join 순서로 실행된다. , where , 그룹화 기준, 갖는, 선택, 구별, 조합, 주문 기준
그룹화 기준은 집계 함수와 함께 사용해야 합니다. 예:
select a.Customer,sum(a.OrderPrice) from 주문 a where a.Customer= 'Bush' 또는 a.Customer = a.Customer의 'Adams' 그룹
다중 테이블 쿼리 구현(내부 조인)
lm_user에서 u.uname,a.addr 선택 u 내부 조인 lm_addr a on u.uid = a.uid;
select from where를 사용하여 수행할 수도 있습니다.
lm_user u, lm_addr a에서 u.uname,a.addr 선택(여기서 u.uid = a.uid;

저장 프로시저

구분자

createprocedureprocedurebill()comment'Query all sales'beginselectbillid,txtime,amtfromlmbill;end

구분자
호출 저장 프로시저;
procedure_bill() 호출;
저장 프로시저 보기
'procedure_bill'과 같은 프로시저 상태 표시;

다대다 데이터 테이블 관계 설정 MySQL 데이터베이스에서

 데이터베이스에서 두 테이블 간의 관계가 "학생 테이블 및 수업 일정"과 같이 다대다 관계인 경우 한 학생은 여러 과목을 선택할 수 있고 하나의 과목을 선택할 수 있습니다. 여러 학생이 선택할 수도 있습니다. 데이터베이스의 설계 원칙에 따라 세 번째 연관 테이블이 구성되어야 합니다.
1단계: Student, Course, Stu_Cour 세 개의 데이터 테이블 생성

/**学生表*/CREATE TABLE Student (
stu_id INT AUTO_INCREMENT,
NAME VARCHAR(30),
age INT ,
class VARCHAR(50),
address VARCHAR(100),PRIMARY KEY(stu_id)
)
/*学生课程表*/CREATE TABLE Course(
cour_id INT AUTO_INCREMENT,
NAME VARCHAR(50),
CODE VARCHAR(30),PRIMARY KEY(cour_id)
)
/**学生课程关联表*/CREATE TABLE Stu_Cour(
sc_id INT AUTO_INCREMENT,
stu_id INT ,
cour_id INT,PRIMARY KEY(sc_id)
)

2단계: Stu_Cour 관련 테이블에 외래 키 추가

/*添加外键约束*/
ALTER TABLE Stu_Cour ADD CONSTRAINT stu_FK1 FOREIGN KEY(stu_id) REFERENCES Student(stu_id);
ALTER TABLE Stu_Cour ADD CONSTRAINT cour_FK2 FOREIGN KEY(cour_id) REFERENCES Course(cour_id);

생성 완료!

참고: 추가된 데이터 테이블에 외래 키를 추가합니다.
-구문: alter table table name add Constraint FK_ID 외래 키(외래 키 필드 이름) REFERENCES 외래 테이블 이름(해당 테이블 기본 키 필드 이름) ); 예: alter table tb_active add Constraint FK_ID 외래 키(user_id) REFERENCES tb_user(id);

SQL 최적화

NO SQL 데이터베이스

일반적으로 사용되는 데이터베이스는 무엇입니까? ? Redis를 사용해 본 적이 있나요?

일반적으로 사용되는 관계형 데이터베이스:
Mysql, SQLServer, Oracle
일반적으로 사용되는 스키마 없는 데이터베이스:
MongoDB, Merncached, Redis...
Redis
(1) Redis는 키와 다섯 가지 유형의 값 사이의 매핑을 저장할 수 있고 메모리에 저장된 키-값 쌍 데이터를 하드 디스크에 유지할 수 있는 매우 빠른 비관계형 데이터베이스입니다.
(2) Merncached와 비교
1) 둘 다 키-값 매핑을 저장하는 데 사용할 수 있으며 성능은 거의 동일합니다.
2) redis는 두 가지 다른 방식으로 자동으로 데이터를 쓸 수 있습니다.
3) Redis는 일반 문자열 키 외에도 4개의 다른 데이터 구조를 저장할 수 있습니다. Merncached는 문자열 키만 저장할 수 있습니다.
4) Redis는 기본 데이터베이스와 기타 데이터베이스의 보조 데이터베이스로 사용할 수 있습니다.

데이터베이스 엔진(스토리지 엔진)

엔진이란?
 데이터베이스에 접근할 때, 수동 접근이든 프로그램 접근이든 데이터베이스 파일을 직접 읽고 쓰는 것이 아니라, 데이터베이스 엔진을 통해 데이터베이스 파일에 접근합니다.
관계형 데이터베이스를 예로 들면, 데이터베이스 엔진에 SQL 문을 보내면 데이터베이스 엔진이 SQL 문을 해석하여 필요한 데이터를 추출하여 사용자에게 반환합니다. 따라서 방문자에게 데이터베이스 엔진은 SQL 문의 해석기입니다.

MYISAM과 InnoDB 엔진의 차이점

주요 차이점:
- (1) MYISAM은 트랜잭션에 안전하지 않지만 InnoDB는 트랜잭션에 안전합니다.
- (2) NYISAM 잠금의 세분성은 테이블 수준 잠금이지만 InnoDB는 행을 지원합니다. -level locks;
- (3) MYISAM은 전체 텍스트 인덱싱을 지원하지만 InnoDB는 전체 텍스트 인덱싱을 지원하지 않습니다.
- (4) MYISAM은 상대적으로 간단하므로 소규모 애플리케이션보다 효율성이 좋습니다. MYISAM 사용을 고려할 수 있습니다.
- (5) MYISAM 테이블은 크로스 플랫폼 데이터 전송에 MYISAM 스토리지를 사용하면 많은 문제를 줄일 수 있습니다.
- (6) InnoDB 테이블은 더 안전합니다. MYISAM 테이블보다 데이터가 손실되지 않도록 보장할 수 있습니다.
응용 시나리오:
- (1) MYISAM은 비트랜잭션 테이블을 관리합니다. - 빠른 저장 및 검색 기능과 전체 텍스트 검색 기능을 제공합니다. 애플리케이션이 많은 수의 선택 쿼리를 수행해야 하는 경우 MYISAM이 더 나은 선택입니다.
- (2) InnoDB는 트랜잭션 처리 애플리케이션에 사용되며 ACID 트랜잭션 지원을 포함한 많은 기능을 가지고 있습니다. 애플리케이션이 많은 수의 삽입 또는 업데이트 작업을 수행해야 하는 경우 다중 사용자 동시 작업의 성능을 향상시킬 수 있는 innodb를 사용해야 합니다.

기타

데이터베이스의 패러다임은 무엇입니까

  현재 관계형 데이터베이스에는 6가지 패러다임이 있습니다: 첫 번째 정규형 {1NF}, 두 번째 정규형 {2NF}, 세 번째 정규형 형식 {3NF}, Bass-Codd 정규형 {BCNF}, 네 번째 정규형 {4NF}, 다섯 번째 정규형 {5NF, 완전 정규형이라고도 함}. 최소 요구사항을 충족하는 패러다임이 첫 번째 정규형입니다. 첫 번째 정규형을 기반으로 더 많은 표준 요구 사항을 충족하는 것을 두 번째 정규형 {2NF}라고 하며 다른 패러다임은 이를 따릅니다. 일반적으로 데이터베이스는 세 번째 정규형(3NF)만 충족하면 됩니다. .
표준:

(1) 1NF: 각 열이 원자성을 유지하는지 확인합니다.

(2) 2NF: 테이블의 각 열이 기본 키와 관련되어 있는지 확인합니다(공동 기본 키). key);

(3) 3NF: 테이블의 각 열이 기본 키(외부 키)와 직접 관련되어 있는지 확인하세요.

(4) BCNF: 1NF를 기준으로, -기본 속성은 기본 키 세트 종속성에서 뺄 수 없습니다(3NF를 기준으로 기본 코드 하위 집합에 대한 종속성을 제거).

(5) 4NF: 동일한 테이블에서 다대다 관계를 삭제해야 합니다. ;

(6) 5NF : 최종 구조에서 원래 구조를 재구성합니다.