PHP에 대한 mysql 인터뷰 질문 전체 모음(지속적으로 업데이트됨)

1. MySQL 인덱스 지식 포인트

1. 인덱스란 무엇인가요?

2. 지수 유형

3. 기본키와 일반 인덱스의 차이점

4. 기본키, 외래키, 인덱스의 차이점은 무엇인가요?

5. 지수의 장점과 단점

6. 인덱스 실패 상황

7. 데이터 테이블을 인덱싱하는 원칙은 무엇입니까?

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

9. msyql 인덱스를 다시 테이블로

10. 인덱스 가장 왼쪽 매칭 원리

11. 클러스터형 인덱스와 비클러스터형 인덱스의 차이점

12. mysql 인덱스 최적화

13. MyISAM과 InnoDB의 기본 차이점은 무엇입니까? 인덱스 구조는 어떻게 구현되나요?

14. MySQL은 B+ 트리 인덱스 구조를 사용합니다.

2. 잠금 장치

1. 자물쇠란 무엇인가요?

2. MySQL에는 어떤 유형의 잠금이 있습니까?

3. 행 수준 잠금이란 무엇입니까? MySQL에서 행 수준 잠금을 구현하는 방법은 무엇입니까?

4. 테이블 수준 잠금이란 무엇입니까? MySQL에서 테이블 수준 잠금을 구현하는 방법은 무엇입니까?

5. 페이지 수준 잠금이란 무엇입니까? MySQL에서 페이지 수준 잠금을 구현하는 방법은 무엇입니까?

6. 공유 잠금과 배타적 잠금이란 무엇입니까?

7. 교착상태란 무엇입니까? 교착상태를 피하는 방법은 무엇입니까?

8. 낙관적 잠금과 비관적 잠금이란 무엇입니까?

9. 교착상태 감지와 교착상태 복구란 무엇입니까?

10. 트랜잭션 격리 수준이란 무엇입니까? MySQL에는 어떤 트랜잭션 격리 수준이 있습니까?

11. 갭락이란? MySQL에서 갭 잠금을 사용하는 방법은 무엇입니까?

12. 교착상태 타임아웃이란 무엇입니까?

13. 스핀락이란 무엇입니까? 스핀락은 언제 사용하나요?

14. 잠금 세분성이란 무엇입니까? 적절한 잠금 세분성을 선택하는 방법은 무엇입니까?

15. 잠금 업그레이드와 잠금 다운그레이드란 무엇인가요?

16. 교착상태 그래프란 무엇입니까?

17. msyql 비관적 잠금과 낙관적 잠금은 공유 잠금 또는 배타적 잠금으로 분류됩니까?

3. MySQL 기초

1. PHP에서 PDO가 무엇인지 설명해 주세요.

2. mongodb와 mysql의 차이점

3. SQL 실행 과정

4. 데이터베이스의 트랜잭션이란 무엇입니까?

5. char와 varchar의 차이점

6. 관계형 데이터베이스와 비관계형 데이터베이스의 차이점은 무엇입니까?

7. MySQL 왼쪽 조인, 오른쪽 조인 및 내부 조인의 차이점을 간략하게 설명하십시오.

8. PHP에서 PDO와 mysqli 확장의 차이점은 무엇입니까? 데이터베이스를 운영하려면 어떤 확장을 사용해야 합니까?

9. count(1), count(*), count(열명)의 실행 차이점을 간략하게 설명해주세요.

10. 어디에서, 지온, 제한, 그룹화, 보유 등의 실행 명령

4. MySQL 최적화

1. MySQL은 하나의 테이블에 1억 개가 넘는 데이터를 가지고 있는데, 쿼리 속도를 최적화하는 방법은 무엇입니까?

2. 느린 SQL 찾는 방법

3. 테이블과 데이터베이스를 msyql로 나누는 방법

4. MySQL 마스터-슬레이브 복제

5. MySQL 데이터베이스 CPU가 100%로 급증하면 어떻게 해야 합니까?

6. 수백억 개의 데이터를 테이블로 나눈 후 페이지 단위로 쿼리하는 방법은 무엇입니까?

7. MySQL 쿼리 성능을 최적화하는 방법은 무엇입니까?

8. MySQL의 테이블 구조를 최적화하는 방법은 무엇입니까?

9. MySQL 구성 매개변수를 최적화하는 방법은 무엇입니까?

5. MySQL 보안

1. SQL 인젝션이란 무엇이며, SQL 인젝션을 방지하는 방법은 무엇인가요?

2. MySQL 데이터베이스의 보안을 어떻게 보호하나요?

3. MySQL 데이터베이스에 대한 액세스를 어떻게 제한하나요?

4. MySQL 데이터베이스의 민감한 데이터를 어떻게 보호하나요?

1. MySQL 인덱스 지식 포인트

1. 인덱스란 무엇인가요?

빠른 검색을 위해 정렬된 데이터 구조

2. 지수 유형

Normal Index : Non-Unique Index라고도 하며 가장 기본적인 인덱스 유형이다. 인덱스 열에 일반 B-Tree 인덱스 구조를 생성하여 쿼리 속도를 높일 수 있지만 인덱스 열에 중복 값을 허용합니다.

고유 인덱스: 고유 인덱스는 인덱스 열의 값이 고유하도록 인덱스 열에 고유 제약 조건을 생성합니다. 일반 인덱스와 달리 고유 인덱스는 인덱스 열의 값이 반복될 수 없도록 요구하며, 데이터 삽입이나 업데이트 시 고유성 제약 조건을 위반하면 고유성 충돌 오류가 발생한다.

기본 키 인덱스: 기본 키 인덱스는 테이블의 각 데이터 행을 고유하게 식별하는 데 사용되는 특수한 고유 인덱스입니다. 기본 키 인덱스에서는 인덱스 열의 값이 NULL이 될 수 없어야 하며 고유 제약 조건이 자동으로 생성됩니다. 테이블에는 기본 키 인덱스가 하나만 있을 수 있습니다.

복합 인덱스: 복합 인덱스는 다중 열 인덱스라고도 하는 여러 열에 생성된 인덱스를 나타냅니다. 여러 열에 인덱스를 생성하면 다중 열 조건부 쿼리의 성능을 향상시킬 수 있습니다. 복합 인덱스의 순서가 중요하며 쿼리 시 인덱스 컬럼의 순서대로 사용해야 합니다.

전체 텍스트 색인: 전체 텍스트 색인은 텍스트 콘텐츠의 전체 텍스트 검색에 사용됩니다. 효율적인 키워드 검색 및 일치를 위해 텍스트 필드에 색인을 생성할 수 있습니다. 전체 텍스트 인덱스는 유사 항목 일치 및 키워드 정렬을 지원합니다.

3. 기본키와 일반 인덱스의 차이점

기본 키 인덱스는 고유하며 비워둘 수 없으며, 
기본 키 인덱스는 테이블의 행을 고유하게 식별하는 데 사용되며 쿼리 효율성이 높고, 일반 인덱스는 쿼리 속도를 높이는 데 사용되며 자주 쿼리되는 열에 적합합니다.

4. 기본키, 외래키, 인덱스의 차이점은 무엇인가요?

	기본 키	외래 키	색인
정의	레코드를 고유하게 식별하며 중복될 수 없으며 비워 둘 수 없습니다.	테이블의 외래 키는 다른 테이블의 기본 키가 되며, 외래 키는 반복되거나 null 값을 가질 수 있습니다.	이 필드에는 중복된 값이 없지만 null 값이 있을 수 있습니다.
효과	데이터 무결성을 보장하는 데 사용됩니다.	다른 테이블과의 관계를 설정하는 데 사용됩니다.	쿼리 정렬 속도를 향상시키는 것입니다.
숫자	기본 키는 하나만 있을 수 있습니다.	테이블에는 여러 개의 외래 키가 있을 수 있습니다.	테이블에는 여러 개의 고유 인덱스가 있을 수 있습니다.

5. 지수의 장점과 단점

데이터 검색 효율성을 높이고 데이터베이스 IO 비용을 줄이기 위해 디렉터리를 설정합니다. 인덱스 대기열 데이터를 정렬하면 데이터 정렬 비용과 CPU 소비가 줄어듭니다. 인덱스가 너무 많고 임시 공간이 많아지면 업데이트 및 삭제 속도에도 영향을 줍니다 
.

6. 인덱스 실패 상황

%,!⁼ 및 기타 퍼지 쿼리 조건과 같은 각 인덱스를 사용하거나 사용하지 않으면 유효하지 않습니다. 
문자열인 경우 int를 사용하여 쿼리할 수 없습니다. 따옴표가 필요합니다. 
데이터가 너무 적습니다 
. 함수나 계산을 사용하십시오.

7. 데이터 테이블을 인덱싱하는 원칙은 무엇입니까?

인덱싱은 데이터베이스 쿼리 성능을 향상시키는 중요한 수단 중 하나이며, 인덱싱의 몇 가지 원칙은 다음과 같습니다.

고유성 원칙: 고유해야 하는 기본 키, 고유 제약 조건 또는 열의 경우 고유 인덱스를 설정해야 합니다. 이렇게 하면 데이터의 고유성이 보장되고 열에 대한 조회 작업 속도가 빨라집니다.

빈번한 쿼리 원칙: 자주 쿼리되는 열에 대해서는 인덱스를 생성해야 합니다. 이를 통해 관련 쿼리의 실행 속도를 높이고 데이터베이스의 쿼리 성능을 향상시킬 수 있습니다.

조건부 쿼리 원칙: 쿼리 조건에서 자주 사용되는 컬럼에 대해서는 인덱스를 생성해야 합니다. 이를 통해 조건을 충족하는 쿼리 작업의 속도를 높이고 쿼리 효율성을 향상시킬 수 있습니다.

결합 쿼리 원칙: 동시에 여러 열을 쿼리 조건으로 자주 사용하는 쿼리문의 경우 결합 인덱스를 설정해야 합니다. 이를 통해 여러 열을 인덱스로 사용하여 쿼리 효율성을 높일 수 있습니다.

데이터 볼륨 원칙: 더 큰 데이터 테이블의 경우 인덱스를 생성해야 합니다. 대규모 데이터 테이블의 전체 테이블 스캔은 비용이 많이 들기 때문에 인덱싱을 통해 쿼리 속도를 높일 수 있습니다.

너무 많은 인덱스를 피하는 원칙: 인덱스가 너무 많으면 데이터베이스 유지 관리 비용이 증가하고 데이터 삽입, 업데이트 및 삭제 작업 성능에 영향을 미칩니다. 따라서 과도한 인덱싱을 피하고 필요한 인덱스만 생성해야 합니다.

데이터 유형 원칙: 텍스트 유형이나 긴 열의 경우 인덱스 생성 여부를 신중하게 고려해야 합니다. 이러한 열의 인덱스는 더 많은 저장 공간을 차지하고 인덱스의 효율성에 영향을 미치기 때문입니다. 이를 위해서는 특정 비즈니스 요구 사항과 데이터베이스 쿼리 상황을 기반으로 인덱싱 원칙을 종합적으로 고려해야 합니다.

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

어떤 경우에는 인덱싱이 현명한 선택이 아닐 수 있습니다. 인덱싱이 권장되지 않는 경우 다음과 같은 몇 가지 고려 사항을 고려하십시오.

데이터 테이블이 매우 작음: 데이터 테이블이 수십 행 이하와 같이 매우 작은 경우 인덱싱의 성능 이점이 매우 제한될 수 있으며 성능 저하가 발생할 수도 있습니다. 따라서 작은 테이블에 대한 인덱싱은 필요하지 않을 수 있습니다.

데이터 테이블은 삽입, 업데이트, 삭제 작업을 자주 수행: 인덱스를 생성하면 데이터 테이블의 유지 관리 비용이 증가함 삽입, 업데이트, 삭제 작업을 자주 수행하는 데이터 테이블의 경우 인덱스 유지 관리 비용이 인덱스 비용을 초과할 수 있음 성능 향상 이 경우 인덱싱이 실제로 필요한지 여부를 고려할 수 있습니다.

데이터 테이블에 대한 쿼리가 거의 없거나 인덱스 필드와 관련된 쿼리가 거의 없습니다. 데이터 테이블이 거의 쿼리되지 않거나 인덱스 필드와 관련된 쿼리가 거의 없는 경우 인덱싱의 성능 이점이 매우 제한될 수 있습니다. 이 경우 인덱싱하지 않는 것이 좋습니다.

데이터 테이블의 컬럼 값은 기본적으로 고유함: 데이터 테이블의 컬럼 값이 기본적으로 고유한 경우 인덱스 선택성이 떨어지기 때문에 인덱싱 효과가 감소합니다. 이 경우 인덱싱하지 않는 것이 좋습니다.

쿼리 성능이 충분함: 데이터 테이블의 쿼리 성능이 충분하고 명백한 성능 병목 현상이 없으면 인덱싱이 필요하지 않을 수 있습니다. 이 경우 데이터베이스의 유지 관리 오버헤드를 줄이기 위해 인덱스를 생성하지 않는 것을 고려할 수 있습니다. 구체적인 비즈니스 요구와 데이터베이스 쿼리 조건에 따라 인덱스 구축 여부와 어떤 인덱스를 구축할지 종합적으로 고려해야 합니다. 결정을 내리기 전에 데이터베이스의 쿼리 최적화 도구를 사용하거나 몇 가지 테스트를 수행하여 인덱싱의 영향을 평가할 수 있습니다.

9. msyql 인덱스를 다시 테이블로

테이블로 돌아가는 MySQL 인덱스는 쿼리에 인덱스를 사용할 때 쿼리 결과가 테이블의 다른 열 데이터를 가져와야 하는 경우 인덱스를 통해 테이블로 다시 가져와야 함을 의미합니다. 다음은 MySQL 인덱스 백 테이블에 대한 몇 가지 지침입니다.
인덱스 테이블 지원은 데이터 행에 대한 직접 액세스를 방지하여 쿼리 성능을 향상시키는 쿼리 최적화 기술입니다.

InnoDB 스토리지 엔진에서 클러스터형 인덱스(기본 키 인덱스라고도 함)의 리프 노드는 전체 데이터 행의 데이터를 저장하므로 테이블을 다시 인덱싱할 필요가 없습니다.

비클러스터형 인덱스(보조 인덱스)의 리프 노드에는 인덱스 컬럼과 기본 키의 값만 저장되는데, 다른 컬럼 데이터를 쿼리할 때는 기본 키 값을 통해 테이블 반환 연산을 수행해야 한다.

테이블을 다시 인덱싱하면 기본 키 값을 통해 데이터 행을 무작위로 읽어야 하므로 추가 IO 작업이 추가됩니다.

쿼리 결과에서 더 많은 열 데이터를 얻어야 하는 경우 테이블로 다시 인덱싱하는 비용이 상대적으로 커지므로 쿼리 성능이 저하될 수 있습니다.

인덱스를 덮어쓰면 테이블에 다시 인덱싱하는 오버헤드를 피할 수 있습니다. 커버링 인덱스는 인덱스에 쿼리에 필요한 모든 열이 포함되어 있으며, 테이블 반환 작업 없이 인덱스에서 직접 쿼리 결과를 얻을 수 있음을 의미합니다.

테이블 구조와 인덱스를 설계할 때 테이블에 다시 인덱싱하는 비용을 줄이기 위해 실제 상황에 따라 커버링 인덱스를 사용해야 하는지 고려할 수 있습니다.

MySQL 실행 계획에서는 Extra 열에 Using index 또는 Using index 조건이 포함되어 있는지 확인하여 인덱스 반환 작업이 발생했는지 여부를 확인할 수 있습니다. 테이블에 대한 인덱싱이 성능에 미치는 영향은 쿼리 조건, 테이블 구조 및 데이터 볼륨에 따라 달라집니다. 실제 애플리케이션에서는 더 나은 쿼리 성능을 얻기 위해 특정 상황에 따라 테스트 및 최적화를 수행해야 합니다.

다음은 인덱스를 테이블에 다시 사용하는 방법을 보여주는 예입니다. , 및 이라는 users열로 명명된 테이블이 있다고 가정합니다 . 그 중 기본키가 있습니다. "John"이라는 사용자의 나이를 쿼리하려면 다음 SQL 문을 사용할 수 있습니다.idnameageid
SELECT age
FROM users
WHERE name = 'John';
name인덱스 이름이 인 열에 비클러스터형 인덱스가 생성되었다고 가정합니다 idx_name. 테이블로 다시 인덱싱되는 것을 방지하려면 포함 인덱스를 사용할 수 있습니다.
SELECT name, age
FROM users
WHERE name = 'John';
이 경우, 과 컬럼의 값이 인덱스 idx_name에 직접 포함되기 때문에 테이블 백 연산 없이 인덱스에서 직접 쿼리 결과를 얻을 수 있다. 특정 SQL 문은 다양한 테이블 구조 및 쿼리 요구 사항으로 인해 달라질 수 있다는 점에 유의해야 합니다. 실제 애플리케이션에서는 최상의 쿼리 성능을 얻으려면 특정 조건에 따라 조정 및 최적화가 필요합니다.nameage

10. 인덱스 가장 왼쪽 매칭 원리

인덱스 최좌측 일치 원칙은 데이터베이스 인덱스의 사용 규칙으로, 복합 인덱스(Composite Index)에서 쿼리 조건이 복합 인덱스의 접두사 컬럼만 포함하는 경우 데이터베이스가 해당 인덱스를 쿼리 및 최적화에 사용할 수 있다는 의미이다.

구체적으로 여러 개의 A, B, C 컬럼을 포함하는 복합 인덱스가 있다고 가정하고, 쿼리 조건이 A 컬럼 또는 A 컬럼과 B 컬럼만 포함하고 C 컬럼은 포함하지 않는 경우 데이터베이스는 이 복합 인덱스를 사용할 수 있습니다. 필터링. 그러나 쿼리 조건에 C 열이 포함되지만 A 열이 포함되지 않거나 A 열과 B 열이 포함되지 않는 경우에는 복합 인덱스가 사용되지 않습니다. 이 원리의 기능은 가장 왼쪽 접두사를 통해 쿼리 효율성을 향상시키고 인덱스의 검색 범위를 줄여 쿼리 속도를 높이는 것입니다.

따라서 복합 인덱스를 설계할 때에는 실제 쿼리 시나리오와 요구 사항에 맞춰 인덱스의 컬럼 순서를 합리적으로 선택하고, 쿼리 조건으로 자주 사용되는 컬럼을 전면에 배치하는 것이 필요하다. 가장 왼쪽에 있는 인덱스 일치 원칙이 모든 데이터베이스에 적용되는 것은 아니며, 데이터베이스 시스템마다 인덱스 구현 및 최적화 전략이 다를 수 있다는 점에 유의해야 합니다. 따라서 특정 데이터베이스 환경에서는 데이터베이스의 특성과 성능 특성을 고려하여 인덱스를 설계하고 최적화하는 것이 좋습니다.

11. 클러스터형 인덱스와 비클러스터형 인덱스의 차이점

클러스터형 인덱스와 비클러스터형 인덱스는 데이터베이스의 두 가지 일반적인 인덱스 유형으로, 데이터를 저장하고 쿼리할 때 몇 가지 차이점이 있습니다.

저장 방법:

클러스터형 인덱스: 클러스터형 인덱스의 리프 노드는 테이블의 모든 열 데이터를 저장하고 인덱스의 정렬 순서에 따라 데이터를 물리적으로 구성합니다. 각 테이블에는 클러스터형 인덱스가 하나만 있을 수 있으므로 클러스터형 인덱스에 따라 테이블의 물리적 저장 순서가 결정됩니다.

비클러스터형 인덱스: 비클러스터형 인덱스의 리프 노드에는 인덱스 열의 값과 실제 데이터 행에 대한 포인터가 저장됩니다. 테이블에는 데이터 행이 저장되는 물리적 순서와 무관한 여러 개의 비클러스터형 인덱스가 있을 수 있습니다.

쿼리 효율성:

클러스터형 인덱스: 클러스터형 인덱스는 테이블의 물리적 저장 순서를 결정하므로, 클러스터형 인덱스를 쿼리에 사용할 경우 인덱스 순서대로 데이터에 직접 접근할 수 있어 쿼리 효율성이 향상된다. 그러나 쿼리 조건에 클러스터형 인덱스 열이 포함되지 않은 경우에도 전체 테이블 검색이 필요합니다.

비클러스터형 인덱스: 비클러스터형 인덱스를 사용하여 쿼리할 경우 먼저 인덱스를 통해 해당 행 포인터를 찾은 다음 포인터를 기준으로 실제 데이터 행에 액세스해야 합니다. 따라서 비클러스터형 인덱스의 쿼리 효율성은 클러스터형 인덱스보다 약간 낮을 수 있습니다.

인덱스 업데이트:

클러스터형 인덱스: 클러스터형 인덱스는 테이블의 물리적 저장 순서를 결정하므로 클러스터형 인덱스 열에 대한 업데이트 작업으로 인해 데이터의 물리적 순서가 바뀔 수 있습니다. 이로 인해 페이지 조각화가 발생하고 업데이트 오버헤드가 증가할 수 있습니다.

비클러스터형 인덱스: 비클러스터형 인덱스에서는 실제 데이터 행이 인덱스와 독립적인 순서로 저장되므로 인덱스 열에 대한 업데이트 작업으로 인해 데이터가 물리적으로 다시 정렬되지 않습니다. 따라서 비클러스터형 인덱스는 업데이트 작업에 대한 오버헤드가 상대적으로 적습니다. 특정 데이터베이스 시스템 및 테이블 디자인에 따라 적절한 인덱스 유형을 선택하면 쿼리 효율성과 데이터 업데이트 성능이 향상될 수 있습니다. 일반적으로 범위 쿼리에 자주 사용되는 열에는 클러스터형 인덱스가 적합하고, 같음 쿼리에 자주 사용되는 열에는 비클러스터형 인덱스가 적합합니다.

12. mysql 인덱스 최적화

적절한 인덱스 유형 선택: MySQL은 B-트리 인덱스, 해시 인덱스 및 전체 텍스트 인덱스를 포함한 여러 인덱스 유형을 지원합니다. 쿼리 효율성을 높이려면 실제 상황에 따라 적절한 인덱스 유형을 선택하세요.

적절한 인덱스 열 선택: 인덱스 열은 거의 사용되지 않는 열이 아닌 자주 쿼리되는 열이어야 합니다. 동시에, 인덱스 열의 선택은 데이터의 분포를 고려해야 하며, 반복되는 값이 많은 열을 인덱스로 선택하지 않아야 합니다.

복합 인덱스 만들기: 쿼리 조건에 여러 열이 포함된 경우 복합 인덱스를 만들어 쿼리 효율성을 높일 수 있습니다. 복합 인덱스의 순서는 쿼리 조건의 빈도와 선택도에 따라 결정됩니다.

너무 많은 인덱스 방지: 인덱스를 너무 많이 생성하면 데이터 쓰기 비용이 증가하고 쿼리 성능에도 영향을 미칩니다. 잘못된 중복 인덱스를 방지하려면 필요한 인덱스만 생성하세요.

인덱싱된 열에 대한 함수 작업 방지: 인덱싱된 열에 대한 함수 작업을 수행할 때 MySQL은 최적화를 위해 인덱스를 사용할 수 없으므로 전체 테이블 스캔이 발생합니다. 인덱싱된 열에 대한 기능 작업을 사용하지 않도록 노력해야 합니다.

SELECT * 사용 방지: 필요한 열만 선택하여 불필요한 데이터 읽기 및 전송을 방지하고 쿼리 효율성을 향상시킵니다.

인덱스를 정기적으로 분석하고 최적화합니다. 데이터베이스 사용량을 기반으로 인덱스를 정기적으로 분석하고 최적화하여 인덱스의 최상의 성능을 보장합니다.

커버링 인덱스 사용: 쿼리에 필요한 열을 인덱스에 포함하는 커버링 인덱스를 사용하여 데이터 행에 대한 액세스를 방지하고 쿼리 효율성을 향상시키십시오.

인덱스 열을 자주 업데이트하고 삭제하지 마세요. 인덱스 열을 자주 업데이트하고 삭제하면 인덱스가 불안정해지고 쿼리 성능이 저하됩니다. 간단히 말해서, MySQL 인덱스 최적화는 특정 비즈니스 요구 사항 및 데이터베이스 사용량에 따라 조정 및 최적화가 필요한 포괄적인 작업입니다. 인덱스를 적절하게 생성하고 사용하면 MySQL 데이터베이스의 쿼리 성능을 향상시킬 수 있습니다.

13. MyISAM과 InnoDB의 기본 차이점은 무엇입니까? 인덱스 구조는 어떻게 구현되나요?

A. MyISAM 유형은 트랜잭션 및 테이블 잠금을 지원하지 않으며 조각화되기 쉽습니다. 자주 최적화해야 하며 읽기 및 쓰기 속도가 빠릅니다. 쿼리가 빈번한 애플리케이션에 적합합니다. B. InnoDB 유형은 트랜잭션을 지원하며 
, 행 잠금, 충돌 복구 기능, 읽기 및 쓰기 기능이 있습니다.MyISAM보다 느리고 삽입 및 업데이트 작업이 많은 애플리케이션에 적합합니다.많은 공간을 차지하고 전체 텍스트 인덱싱을 지원하지 않습니다. 
인덱스 생성: 경고 테이블 tablename 인덱스 추가 인덱스 이름(`필드 이름`)

14. MySQL은 B+ 트리 인덱스 구조를 사용합니다.

균형: B+ 트리는 모든 리프 노드의 깊이를 동일하게 유지하여 쿼리 작업의 시간 복잡도를 O(logN) 수준으로 유지합니다.

다중 경로 지정: B+ 트리의 각 노드는 여러 인덱스 키 값과 해당 데이터 포인터를 저장할 수 있으므로 각 노드가 더 많은 데이터를 저장할 수 있어 디스크 I/O 수를 줄이고 쿼리 효율성을 높일 수 있습니다.

순차성: B+ 트리의 리프 노드는 인덱스 키 값의 크기에 따라 정렬되어 범위 쿼리 및 정렬 작업을 보다 효율적으로 만듭니다.

분할 및 병합: 노드에 키-값 쌍이 너무 많으면 B+ 트리는 노드 분할을 수행하고 일부 키-값 쌍을 새 노드에 할당합니다. 트리는 노드 병합을 수행합니다. 작업은 트리의 균형을 유지하기 위해 인접한 노드를 하나의 노드로 병합합니다.

리프 노드 연결 목록: B+ 트리의 리프 노드는 포인터를 통해 정렬된 연결 목록을 형성하므로 범위 쿼리와 순차 순회가 용이합니다. MySQL의 일반 인덱스, 고유 인덱스, 기본 키 인덱스, 복합 인덱스 등은 모두 B+ 트리를 기반으로 구현됩니다. B+ 트리의 장점은 범위 쿼리, 정렬 작업, 효율적인 삽입 및 삭제 작업에 적합하고 다중 열 인덱스와 높은 동시 데이터 액세스를 지원할 수 있다는 것입니다. B+ 트리 인덱스를 적절하게 설계하고 사용함으로써 MySQL 데이터베이스의 쿼리 성능과 데이터 액세스 효율성을 향상시킬 수 있습니다.

2. 잠금 장치

1. 자물쇠란 무엇인가요?

잠금은 공유 리소스에 대한 액세스를 제어하는 데 사용되는 메커니즘입니다. 데이터베이스에서 잠금을 사용하면 동시 트랜잭션의 일관성과 무결성이 보장됩니다.

2. MySQL에는 어떤 유형의 잠금이 있습니까?

MySQL에는 행 수준 잠금, 테이블 수준 잠금, 페이지 수준 잠금을 포함하여 다양한 유형의 잠금이 있습니다.

3. 행 수준 잠금이란 무엇입니까? MySQL에서 행 수준 잠금을 구현하는 방법은 무엇입니까?

행 수준 잠금은 다른 트랜잭션이 데이터 행을 수정하지 못하도록 데이터베이스의 단일 데이터 행을 잠그는 것을 의미합니다. MySQL에서는 SELECT ... FOR UPDATE 문을 사용하여 행 수준 잠금을 달성할 수 있습니다.

4. 테이블 수준 잠금이란 무엇입니까? MySQL에서 테이블 수준 잠금을 구현하는 방법은 무엇입니까?

테이블 수준 잠금은 다른 트랜잭션이 테이블을 수정하지 못하도록 전체 테이블을 잠그는 것을 의미합니다. MySQL에서는 LOCK TABLES 문을 사용하여 테이블 수준 잠금을 구현할 수 있습니다.

5. 페이지 수준 잠금이란 무엇입니까? MySQL에서 페이지 수준 잠금을 구현하는 방법은 무엇입니까?

페이지 수준 잠금은 다른 트랜잭션이 페이지 데이터를 수정하지 못하도록 데이터베이스의 데이터 페이지를 잠그는 것을 의미합니다. MySQL에서는 InnoDB 스토리지 엔진을 사용하여 페이지 수준 잠금을 구현할 수 있습니다.

6. 공유 잠금과 배타적 잠금이란 무엇입니까?

공유 잠금을 사용하면 다른 트랜잭션이 잠긴 데이터를 읽을 수 있지만 다른 트랜잭션이 데이터를 수정하는 것은 허용되지 않습니다. 배타적 잠금은 다른 트랜잭션이 데이터를 읽는 것을 허용하지 않으며 다른 트랜잭션이 데이터를 수정하는 것을 허용하지 않습니다.

7. 교착상태란 무엇입니까? 교착상태를 피하는 방법은 무엇입니까?

두 개 이상의 트랜잭션이 서로 잠금을 해제하여 추가 처리를 방해할 때 교착 상태가 발생합니다. 교착 상태를 방지하려면 트랜잭션 시간 초과 메커니즘을 사용하고, 합리적인 트랜잭션 격리 수준을 설정하고, 트랜잭션 동시성을 줄일 수 있습니다.

8. 낙관적 잠금과 비관적 잠금이란 무엇입니까?

낙관적 잠금(Optimistic Locking)은 낙관적 동시성 제어 메커니즘으로 동시성 충돌이 거의 발생하지 않는다고 가정하여 적극적으로 잠그지는 않지만 제출 시 다른 트랜잭션이 데이터를 수정했는지 확인합니다. 비관적 잠금(Pessimistic Locking)은 비관적 동시성 제어 메커니즘으로, 동시성 충돌이 자주 발생한다고 가정하여 데이터를 읽을 때 적극적으로 잠그어 다른 트랜잭션이 데이터를 수정하지 못하도록 방지합니다.

9. 교착상태 감지와 교착상태 복구란 무엇입니까?

교착 상태 감지는 시스템이 교착 상태의 존재를 감지하고 교착 상태 문제를 해결하기 위해 해당 조치를 취하는 것을 의미합니다.

교착 상태 복구는 시스템이 교착 상태를 해제하는 프로세스를 의미하며 일반적으로 롤백하거나 종료할 트랜잭션을 선택하는 작업이 포함됩니다. 위 내용은 MySQL 잠금과 관련된 몇 가지 일반적인 인터뷰 질문입니다. 이러한 질문에 답할 때에는 자신의 실제 경험과 이해를 바탕으로 답하면 됩니다.

10. 트랜잭션 격리 수준이란 무엇입니까? MySQL에는 어떤 트랜잭션 격리 수준이 있습니까?

트랜잭션 격리 수준은 여러 동시 트랜잭션이 서로 격리되는 정도를 나타냅니다. MySQL에는 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ 및 SERIALIZABLE의 네 가지 트랜잭션 격리 수준이 있습니다.

11. 갭락이란? MySQL에서 갭 잠금을 사용하는 방법은 무엇입니까?

갭 잠금(Gap Lock)은 데이터 범위 사이의 갭을 잠가서 다른 트랜잭션이 그 갭에 새로운 데이터를 삽입하는 것을 방지하는 것을 의미합니다. MySQL에서는 SELECT ... LOCK IN SHARE MODE 또는 SELECT ... FOR UPDATE 문을 사용하여 갭 잠금을 사용할 수 있습니다.

12. 교착상태 타임아웃이란 무엇입니까?

교착상태 타임아웃(Deadlock Timeout)은 교착상태가 발생하면 시스템이 교착상태를 해소하기 위해 일정 시간 동안 기다린 후 트랜잭션 중 하나를 자동으로 종료하는 것을 의미합니다. MySQL의 교착 상태 시간 초과는 innodb_lock_wait_timeout 매개변수를 통해 구성할 수 있습니다.

13. 스핀락이란 무엇입니까? 스핀락은 언제 사용하나요?

스핀 잠금은 잠금을 기다리느라 바쁜 메커니즘으로, 잠금을 획득할 때 스레드는 잠금을 획득할 때까지 루프에서 잠금 상태를 확인합니다. 스핀 잠금은 멀티 코어 CPU에서 더 잘 실행되며 짧은 시간 동안 잠금 충돌이 발생하고 스레드가 오랫동안 차단되지 않는 상황에 적합합니다.

14. 잠금 세분성이란 무엇입니까? 적절한 잠금 세분성을 선택하는 방법은 무엇입니까?

잠금 세분성은 행 수준 잠금, 테이블 수준 잠금, 페이지 수준 잠금을 포함하여 잠긴 데이터의 범위 크기를 나타냅니다. 적절한 잠금 세분성을 선택하는 것은 동시 액세스, 데이터 액세스 모드 및 성능 요구 사항과 같은 요소를 기반으로 종합적으로 고려해야 합니다.

15. 잠금 업그레이드와 잠금 다운그레이드란 무엇인가요?

잠금 업그레이드는 낮은 수준의 잠금을 높은 수준의 잠금으로 업그레이드하는 것을 의미하고, 잠금 다운그레이드는 높은 수준의 잠금을 낮은 수준의 잠금으로 다운그레이드하는 것을 의미합니다. MySQL에서는 잠금 승격이 자동으로 이루어지며 잠금 다운그레이드는 수동으로 수행되어야 합니다.

16. 교착상태 그래프란 무엇입니까?

교착 상태 다이어그램은 교착 상태에 있는 데이터베이스 트랜잭션 간의 관계를 설명하는 그래픽 표현입니다. 교착상태 그래프를 분석하면 교착상태 문제를 해결하기 위해 각 트랜잭션 간의 대기 관계를 이해할 수 있습니다.

17. msyql 비관적 잠금과 낙관적 잠금은 공유 잠금 또는 배타적 잠금으로 분류됩니까?

교착 상태는 두 개 이상의 트랜잭션이 서로의 리소스를 기다리고 있어 모든 트랜잭션이 계속 실행될 수 없는 상황을 말합니다. 간단히 말하면, 두 개 이상의 트랜잭션이 서로 리소스를 해제하기를 기다리고 있어 지속할 수 없는 교착 상태에 빠지게 됩니다.

더티 읽기(Dirty Read)는 한 트랜잭션이 다른 트랜잭션에서 커밋되지 않은 데이터를 읽는 것을 의미합니다. 한 트랜잭션이 데이터를 읽고 있을 때 다른 트랜잭션이 데이터를 수정했지만 아직 커밋하지 않은 경우, 이때 첫 번째 트랜잭션이 읽은 데이터는 일관성이 없거나 유효하지 않습니다.

팬텀 읽기(Phantom Read)는 한 트랜잭션이 데이터를 읽을 때 다른 트랜잭션이 동일한 데이터를 삽입하거나 삭제하여 첫 번째 트랜잭션이 일관되지 않은 데이터 행을 읽게 되는 것을 의미합니다. 팬텀 읽기와 더티 읽기의 차이점은 더티 읽기는 커밋되지 않은 수정된 데이터를 읽는 반면, 팬텀 읽기는 다른 트랜잭션에 의해 제출된 새 데이터 또는 삭제된 데이터를 읽는다는 것입니다.

반복 불가능 읽기는 한 트랜잭션이 데이터를 읽을 때 다른 트랜잭션이 동일한 데이터를 수정하고 커밋하여 첫 번째 트랜잭션이 동일한 데이터를 여러 번 읽을 때 일관되지 않은 결과가 발생한다는 것을 의미합니다. 반복 불가능 읽기와 팬텀 읽기의 차이점은 반복 불가능 읽기는 다른 트랜잭션에 의해 제출된 수정된 데이터를 읽는 반면, 팬텀 읽기는 다른 트랜잭션에 의해 제출된 새 데이터 또는 삭제된 데이터를 읽는다는 것입니다. 이러한 문제는 주로 동시 트랜잭션 처리 환경에서 발생하며 동시에 데이터베이스에 여러 트랜잭션을 읽고 쓰는 경우 발생합니다. 이러한 문제를 해결하기 위해 데이터베이스 시스템은 다양한 격리 수준(예: 커밋되지 않은 읽기, 커밋된 읽기, 반복 가능한 읽기 및 직렬화)을 제공하며 개발자는 특정 상황에 따라 적절한 격리 수준을 선택하여 이러한 문제를 피하거나 줄일 수 있습니다.

3. MySQL 기초

1. PHP에서 PDO가 무엇인지 설명해 주세요.

PDO(PHP Data Objects)는 MySQL, PostgreSQL, Oracle 등 다양한 데이터베이스를 연결하고 운영하는 데 사용되는 PHP 확장입니다. PDO는 데이터베이스 작업을 수행하기 위한 통합 인터페이스와 일련의 메소드를 제공 
하고 준비된 명령문 및 트랜잭션 처리와 같은 고급 기능을 지원합니다.

2. mongodb와 mysql의 차이점

Mongodb는 비관계형 데이터베이스, MySQL은 관계형 데이터베이스 
MySQL은 상대적으로 성숙도가 높고 좀 더 복잡한 관계형 SQL을 지원한다. 단점은 데이터가 클수록 속도가 느려진다는 점이다. 
MongoDB 핫 데이터는 물리적 메모리에 직접 존재한다. 빅데이터는 또한 빠르게 쿼리할 수 있으며 트랜잭션이 지원되지 않습니다.

3. SQL 실행 과정

sql 문-)커넥터-)쿼리 캐시-)인터프리터-)실행자

4. 데이터베이스의 트랜잭션이란 무엇입니까?

데이터베이스에서 트랜잭션은 모두 성공적으로 실행되거나 모두 롤백 및 실행 취소되는 일련의 데이터베이스 작업(예: 삽입, 업데이트, 삭제 등)의 논리적 단위입니다. 트랜잭션에는 ACID 속성이라고도 하는 다음과 같은 네 가지 특성이 있습니다.

원자성: 트랜잭션은 모두 성공적으로 실행되거나 모두 실패하여 롤백되는 분할할 수 없는 작업 단위입니다. 트랜잭션의 작업 중 하나라도 실패하면 부분 변경 없이 전체 트랜잭션이 원래 상태로 롤백됩니다.

일관성: 데이터베이스는 트랜잭션 실행 전후에 일관된 상태를 유지해야 합니다. 이는 트랜잭션 내의 작업이 데이터 무결성과 유효성을 보장하기 위해 미리 정의된 규칙과 제약 조건을 충족해야 함을 의미합니다.

격리(Isolation): 트랜잭션 실행은 서로 격리되어야 하며, 트랜잭션이 서로 간섭해서는 안 됩니다. 동시에 실행되는 여러 트랜잭션은 데이터 불일치 및 충돌을 방지하기 위해 서로 격리된 상태로 유지되어야 합니다.

내구성: 트랜잭션이 커밋되면 데이터베이스에 대한 변경 사항은 영구적이어야 하며 시스템 오류나 충돌 후에도 지속되어야 합니다. 트랜잭션을 사용하면 데이터베이스의 데이터 무결성과 일관성을 보장할 수 있습니다. 애플리케이션에서 거래의 일반적인 애플리케이션에는 은행 송금, 주문 처리, 재고 관리 및 데이터의 정확성과 완전성이 보장되어야 하는 기타 시나리오가 포함됩니다.

5. char와 varchar의 차이점

char 고정 길이 varchar 가변 길이 공간 char은 고정된 저장 공간을 차지합니다. varchar 실제 공간 char은 쿼리 효율성이 높습니다.

6. 관계형 데이터베이스와 비관계형 데이터베이스의 차이점은 무엇입니까?

관계형 데이터베이스와 비관계형 데이터베이스의 차이점은 다음과 같이 간략하게 요약할 수 있습니다.

데이터 저장 방식: 관계형 데이터베이스는 테이블 형태로 데이터를 저장하고, 비관계형 데이터베이스는 키-값 쌍, 문서 등의 형태로 데이터를 저장합니다.

데이터 모델: 관계형 데이터베이스는 구조화된 데이터 모델을 사용하고 작업 및 쿼리에 SQL을 사용하며, 비관계형 데이터베이스는 비구조적 또는 반구조화된 데이터 모델을 사용하고 다양한 쿼리 언어 또는 API를 사용합니다.

확장성: 관계형 데이터베이스는 일반적으로 수직으로 확장됩니다. 즉, 성능 향상을 위해 하드웨어 리소스를 추가합니다. 비관계형 데이터베이스는 수평으로 확장하여 노드를 추가하여 저장 용량과 처리량을 늘릴 수 있습니다.

데이터 일관성: 관계형 데이터베이스는 ACID 특성을 따라 데이터 무결성과 일관성을 보장합니다. 비관계형 데이터베이스는 고가용성과 분산 성능을 추구하며 경우에 따라 특정 데이터 일관성이 희생될 수 있습니다.

적용 가능한 시나리오: 관계형 데이터베이스는 데이터 일관성, 트랜잭션 처리 및 복잡한 쿼리를 보장해야 하는 애플리케이션에 적합하고, 비관계형 데이터베이스는 대규모 데이터와 높은 동시 액세스를 처리하는 애플리케이션에 적합합니다.

7. MySQL 왼쪽 조인, 오른쪽 조인 및 내부 조인의 차이점을 간략하게 설명하십시오.

LEFT JOIN: 왼쪽 조인은 왼쪽 테이블의 모든 레코드뿐만 아니라 왼쪽 테이블과 일치하는 오른쪽 테이블의 레코드도 반환합니다. 오른쪽 테이블에 일치하는 레코드가 없으면 NULL 값이 반환됩니다. 왼쪽 조인 키워드는 LEFT JOINor 입니다 LEFT OUTER JOIN.

RIGHT JOIN: 오른쪽 조인은 오른쪽 테이블의 모든 레코드뿐만 아니라 오른쪽 테이블과 일치하는 왼쪽 테이블의 레코드도 반환합니다. 왼쪽 테이블에 일치하는 레코드가 없으면 NULL 값이 반환됩니다. 올바른 조인 키워드는 RIGHT JOINor 입니다 RIGHT OUTER JOIN.

INNER JOIN: Inner Join은 왼쪽 테이블과 오른쪽 테이블의 일치하는 레코드만 반환합니다. 조인 조건에 따라 두 테이블에서 일치하는 행을 필터링합니다. 내부 조인 키워드는 입니다 INNER JOIN. 요약하다:

LEFT JOIN왼쪽 테이블의 모든 레코드와 일치하는 오른쪽 테이블 레코드를 반환합니다.

RIGHT JOIN오른쪽 테이블의 모든 레코드와 일치하는 왼쪽 테이블 레코드를 반환합니다.

INNER JOIN왼쪽 테이블과 오른쪽 테이블에서 일치하는 레코드만 반환됩니다. 연결 조건의 정확성은 연결 결과에 중요한 영향을 미친다는 점에 유의해야 합니다. 또한 조인 연산에 WHERE 절을 사용하면 조인 연산이 내부 조인으로 변환될 수 있으므로 주의해서 사용해야 한다.

8. PHP에서 PDO와 mysqli 확장의 차이점은 무엇입니까? 데이터베이스를 운영하려면 어떤 확장을 사용해야 합니까?

PDO와 mysqli는 모두 데이터베이스를 작동하는 데 사용되는 PHP의 확장입니다. 차이점은 PDO는 다양한 데이터베이스를 지원하고 더 나은 이식성을 갖는 경량 데이터베이스 액세스 추상화 계층이고, mysqli는 MySQL 데이터베이스에 대한 PHP의 확장이며 MySQL 데이터베이스만 지원한다는 것입니다. 어떤 확장을 사용할지는 특정 요구사항과 프로젝트 조건에 따라 선택해야 하며, 여러 데이터베이스를 지원해야 하거나 이식성 요구 사항이 있는 경우 PDO를 선택하고, MySQL 데이터베이스만 운영해야 하는 경우에는 mysqli를 사용하면 됩니다. 더 많은 MySQL 관련 기능과 최적화를 제공하기 때문입니다.

9. count(1), count(*), count(열명)의 실행 차이점을 간략하게 설명해주세요.

COUNT(1): 사용시 COUNT(1)실제로 조건에 맞는 행의 개수를 센다. 각 행에는 1상수를 나타내므로 추가적인 계산 및 조회가 필요하지 않아 실행 효율이 상대적으로 높습니다. 이 작성 방법은 일반적으로 간단한 행 계산에 사용됩니다.

COUNT(*): 사용시 COUNT(*)실제로 조건에 맞는 행의 개수를 센다. *모든 컬럼이 선택되었음을 나타내므로 행 수를 계산할 때 모든 컬럼의 값을 검색해야 하므로 추가적인 오버헤드가 발생할 수 있습니다. 경우에 따라 COUNT(*)테이블에 열 수가 많거나 행 수가 많은 경우 성능 저하가 발생할 수 있습니다.

COUNT(列名): 사용하면 COUNT(列名)실제로 조건을 충족하는 비어 있지 않은 줄의 수를 계산합니다. 이 쓰기 방식은 지정된 열을 계산하고 해당 열에 있는 null이 아닌 값만 계산합니다. 지정된 열에 NULL 값이 존재하는 경우 해당 NULL 값은 계산되지 않습니다. 요약하다:

COUNT(1)가장 일반적으로 사용되는 작성 방식으로 각 행마다 상수를 반환하고, 추가적인 계산 및 조회가 필요하지 않아 실행 효율성이 상대적으로 높다.

COUNT(*)모든 열 값을 검색하고 조건에 맞는 행의 개수를 계산합니다. 경우에 따라 추가 오버헤드가 발생할 수 있습니다. 특히 테이블에 열 수가 많거나 행 수가 많은 경우에는 더욱 그렇습니다.

COUNT(列名)지정된 열을 계산하고 해당 열에 대해 Null이 아닌 값만 계산합니다. 지정된 열에 NULL 값이 존재하는 경우 해당 NULL 값은 계산되지 않습니다.

10. 어디에서, 지온, 제한, 그룹화, 보유 등의 실행 명령

FROM: 지정된 테이블에서 데이터를 가져옵니다. 테이블이 여러 개인 경우 해당 연결 작업(JOIN)이 수행됩니다.

WHERE: 지정된 조건을 충족하는 행을 필터링합니다.

GROUP BY: 지정된 열을 기준으로 결과를 그룹화합니다.

HAVING: 그룹화된 결과를 필터링합니다.

SELECT: 쿼리할 열을 선택합니다.

ORDER BY: 결과를 정렬합니다.

LIMIT: 반환되는 결과 행 수를 제한합니다.

4. MySQL 최적화

1. MySQL은 하나의 테이블에 1억 개가 넘는 데이터를 가지고 있는데, 쿼리 속도를 최적화하는 방법은 무엇입니까?

인덱스 최적화: 인덱스를 적절하게 생성, 사용 및 유지 관리하면 쿼리 속도가 크게 향상될 수 있습니다. 쿼리 기준으로 자주 사용되는 필드의 경우 인덱스 생성을 고려하세요. 그러나 인덱스가 너무 많으면 데이터 삽입 및 업데이트 속도에도 영향을 미치므로 절충점이 있습니다.

파티션 테이블: 큰 테이블을 특정 조건에 따라 파티션하여 데이터를 서로 다른 물리적 위치에 저장하여 쿼리 효율성을 높일 수 있습니다. 실제 시나리오에 따라 시간, 지역 등에 따라 분할될 수 있습니다.

수직 분할: 테이블을 유사한 열이 포함된 여러 개의 작은 테이블로 분할하면 단일 테이블의 데이터 양을 줄이고 쿼리 속도를 향상시킬 수 있습니다. 그러나 과도한 분할로 인해 쿼리 복잡성이 증가하는 것을 방지하려면 실제 상황에 따라 분할해야 합니다.

수평 분할: 특정 조건에 따라 테이블을 분할하고 데이터를 다른 테이블에 저장하므로 단일 테이블의 데이터 양을 줄이고 쿼리 속도를 향상시킬 수 있습니다. 그러나 쿼리 중에 필요한 데이터를 올바르게 얻을 수 있도록 데이터 연결 문제를 고려해야 합니다.

쿼리 최적화: 쿼리 문을 최적화하여 전체 테이블 스캔과 다수의 임시 테이블 작업을 방지합니다. 적절한 인덱스 사용, 쿼리문 작성 최적화, 반복 쿼리 방지를 통해 쿼리 효율성을 높일 수 있습니다.

데이터 압축: 콜드 데이터를 압축하고 저장하여 디스크 공간 사용량을 줄이고 쿼리 속도를 향상시킬 수 있습니다.

하드웨어 최적화: SSD 하드 드라이브, 대용량 메모리 등과 같은 고성능 하드웨어를 사용하여 데이터베이스의 전반적인 성능을 향상시키는 것을 고려할 수 있습니다. 위의 내용은 일반적으로 사용되는 최적화 전략 중 일부이며 실제 상황에 따라 구체적인 최적화 계획을 선택하고 조정해야 합니다. 또한 MySQL 자체의 EXPLAIN 문, 느린 쿼리 로그 등의 모니터링 및 튜닝 도구를 통해 잠재적인 성능 문제를 발견하고 최적화하는 데 도움을 줄 수 있습니다.

2. 느린 SQL 찾는 방법

느린 쿼리 로그 켜기: MySQL 구성 파일에서 slow_query_log매개변수를 로 설정하고 매개변수를 ON지정하여 slow_query_log_file느린 쿼리 로그 파일의 경로를 지정합니다. 구성을 적용하려면 MySQL을 다시 시작하세요.

느린 쿼리 임계값 설정: long_query_time매개변수를 초 단위로 설정하여 느린 쿼리 시간 임계값을 지정합니다. 기본값은 10초입니다. 실제 상황에 따라 조정될 수 있습니다.
느린 쿼리 로그 분석: 느린 쿼리 로그 파일을 분석하여 느린 SQL을 찾을 수 있습니다. mysqldumpslow느린 쿼리 로그를 구문 분석 및 분석하고 쿼리 문을 실행 시간별로 정렬할 수 있는 도구를 사용할 수 있습니다 .
mysqldumpslow -s t /path/to/slow_query_log
이 명령은 실행 시간의 내림차순으로 느린 쿼리 로그의 쿼리 문을 나열합니다.

EXPLAIN을 사용하여 쿼리 계획 분석: 느린 쿼리의 경우 EXPLAIN키워드를 사용하여 쿼리 계획을 볼 수 있습니다. 실행 EXPLAIN명령은 쿼리 문의 실행 계획과 옵티마이저의 사용법을 표시할 수 있습니다. 쿼리 계획을 분석하면 쿼리에서 인덱스를 사용하는지, 전체 테이블 스캔을 수행하는지 등을 확인할 수 있습니다.
EXPLAIN SELECT * FROM table WHERE column = 'value';
성능 모니터링 도구 사용: 느린 쿼리 로그 및 로그 외에도 EXPLAIN성능 모니터링 도구를 사용하여 느린 SQL을 찾을 수도 있습니다. 예를 들어 MySQL과 함께 제공되는 성능 모니터링 도구를 사용 하거나 등 Performance Schema의 타사 도구를 사용하십시오 . 위의 단계를 통해 느린 SQL을 찾아 상황에 맞게 최적화하여 데이터베이스 성능을 향상시킬 수 있습니다.pt-query-digestPercona Toolkit

3. 테이블과 데이터베이스를 msyql로 나누는 방법

지점 라이브러리:

비즈니스 요구 사항과 데이터 특성에 따라 분할해야 하는 데이터베이스의 논리적 분할을 결정합니다. 다양한 비즈니스 모듈이나 데이터 유형에 따라 나눌 수 있습니다.

여러 데이터베이스 인스턴스를 만듭니다. 각 인스턴스는 하위 데이터베이스에 해당합니다.

각 하위 데이터베이스의 데이터가 파티셔닝 규칙을 충족하는지 확인하기 위해 파티셔닝 규칙에 따라 원본 데이터베이스 테이블을 마이그레이션합니다.

하위 테이블:

비즈니스 요구사항과 데이터 특성에 따라 분할해야 할 테이블의 논리적 분할을 결정합니다. 시간별, 지역별, 사용자별, 기타 정보별로 구분할 수 있습니다.

여러 테이블을 생성합니다. 각 테이블은 하위 테이블에 해당합니다.

파티션 규칙에 따라 원본 테이블 데이터를 마이그레이션하여 각 테이블의 데이터가 파티션 규칙을 충족하는지 확인하세요.

데이터 라우팅:

애플리케이션에서 데이터 라우팅 논리를 구현하고 비즈니스 요구 사항에 따라 데이터 액세스에 적합한 하위 데이터베이스와 테이블을 선택합니다.

데이터 라우팅 기능은 데이터베이스 연결 풀이나 데이터 액세스 프레임워크를 통해 구현될 수 있습니다.

인덱스 최적화:

테이블과 데이터베이스를 분할한 후에는 인덱스 디자인을 재평가하고 최적화해야 합니다. 쿼리 빈도와 실제 요구 사항에 따라 적절한 인덱스를 다시 만들어 쿼리 성능을 향상시킵니다. 하위 테이블과 하위 데이터베이스는 특정 비즈니스 요구 사항과 데이터베이스 사용량을 기반으로 설계하고 구현해야 한다는 점에 유의해야 합니다. 동시에 하위 테이블과 하위 데이터베이스는 데이터 동기화, 데이터베이스 간 쿼리 등과 같은 추가 관리 및 유지 관리 작업도 수행합니다. 따라서 하위 테이블과 하위 데이터베이스를 구현하기 전에 하위 테이블과 하위 데이터베이스가 예상한 목표를 달성할 수 있는지 확인하기 위해 충분한 평가와 계획을 세우고 충분한 테스트와 검증을 수행해야 합니다.

4. MySQL 마스터-슬레이브 복제

MySQL 마스터-슬레이브 복제는 여러 MySQL 서버 간의 데이터 동기화를 달성하는 데 사용되는 일반적으로 사용되는 데이터베이스 복제 기술입니다. 마스터-슬레이브 복제에서는 하나의 MySQL 서버(마스터라고 함)가 데이터 소스 역할을 하고, 하나 이상의 다른 MySQL 서버(슬레이브라고 함)가 마스터에 데이터를 복제합니다. 마스터-슬레이브 복제는 다음과 같이 작동합니다.
메인 서버는 추가, 삭제, 수정 등의 작업을 포함하여 업데이트된 데이터를 바이너리 로그에 기록합니다.

슬레이브 서버는 마스터 서버에 연결하고 바이너리 로그의 로그 이벤트를 요청하여 마스터 서버에서 발생한 데이터 변경 사항을 가져옵니다.

슬레이브 서버는 획득한 로그 이벤트를 자신의 데이터베이스에 적용하여 슬레이브 서버의 데이터가 마스터 서버와 일치하도록 합니다. 마스터-슬레이브 복제를 구성하고 설정하는 단계는 다음과 같습니다.

마스터 서버에서 바이너리 로그가 활성화되어 있는지 확인합니다. log_bin구성 파일에서 매개변수를 설정하고 고유 식별자를 설정하여 바이너리 로그 기능을 활성화할 수 있습니다 server_id.
CREATE USER 'replication_user'@'slave_ip' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'slave_ip';
그 중 는 slave_ip슬레이브 서버의 IP 주소와 password복사된 사용자의 비밀번호입니다. 슬레이브 서버에서 매개변수를 설정 하고 마스터 서버의 server_id매개변수와 다른지 확인하십시오 . server_id슬레이브 서버에서 다음 명령을 실행하여 마스터 서버의 IP 주소를 지정하고 사용자, 비밀번호 및 기타 정보를 복사합니다.
CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_USER='replication_user', MASTER_PASSWORD='password', MASTER_LOG_FILE='log_file', MASTER_LOG_POS=log_position;
여기서 master_ip는 마스터 서버의 IP 주소, replication_user는 password마스터 서버에 생성된 복제 사용자의 사용자 이름과 비밀번호, log_file는 log_position각각 마스터 서버 바이너리 로그의 파일 이름과 위치입니다. SHOW MASTER STATUS;명령을 통해 마스터 서버의 현재 바이너리 로그 파일 이름과 위치를 볼 수 있습니다 .
START SLAVE;
그러면 슬레이브 서버가 마스터 서버에 연결되어 데이터 복제가 시작됩니다.

해당 명령어를 이용하면 SHOW SLAVE STATUS;슬레이브 서버의 복제 상태(복제 정상 여부, 지연 여부 등)를 확인할 수 있습니다. 위의 단계를 통해 MySQL 마스터-슬레이브 복제를 설정하고 데이터 동기화를 달성할 수 있습니다. 마스터-슬레이브 복제는 데이터 백업, 읽기-쓰기 분리, 로드 밸런싱 및 기타 기능을 제공하여 데이터베이스의 가용성과 성능을 향상시킬 수 있습니다.

5. MySQL 데이터베이스 CPU가 100%로 급증하면 어떻게 해야 합니까?

쿼리 문 확인 및 최적화: 특정 쿼리 문을 비효율적으로 실행하면 높은 CPU 사용량이 발생할 수 있습니다. EXPLAIN 문을 이용하여 쿼리문의 실행 계획을 분석함으로써 느린 쿼리나 리소스를 많이 사용하는 쿼리문을 찾아 최적화한다. 쿼리 성능을 향상시키기 위해 적절한 인덱스 추가, 쿼리 문 다시 작성, 전체 테이블 스캔 방지 등을 고려할 수 있습니다.

데이터베이스 연결 풀 설정 조정: 동시 연결 수가 너무 많으면 많은 수의 연결 요청으로 인해 CPU 리소스가 점유됩니다. 과도한 연결 요청으로 인해 CPU 스파이크가 발생하는 것을 방지하기 위해 데이터베이스 연결 풀의 매개변수를 조정하여 동시 연결 수를 제한할 수 있습니다. 예를 들어 최대 연결 수를 줄이고 연결 시간 초과를 조정하는 등의 작업을 수행할 수 있습니다.

데이터베이스 구성 매개변수 확인 및 최적화: MySQL 구성 매개변수는 데이터베이스 성능에 중요한 영향을 미칩니다. innodb_buffer_pool_size, query_cache_size 등과 같은 일부 중요한 구성 매개변수를 확인하고 조정하여 현재 데이터베이스 로드에 적응할 수 있습니다.

데이터베이스 테이블 구조 분석 및 최적화: 데이터베이스 테이블 구조가 제대로 설계되지 않으면 CPU 사용량이 높아질 수 있습니다. 테이블 구조를 분석하고 큰 테이블 분할, 작은 테이블 병합, 필드 유형 및 길이 표준화 등과 같은 필요한 최적화를 수행함으로써 데이터베이스의 부하를 줄일 수 있습니다.

동시 업데이트 작업 수가 많은지 확인: 동시 업데이트 작업 수가 많으면 CPU 스파이크가 발생할 수 있습니다. 업데이트 작업 빈도 조정, 업데이트 작업 병합 등을 통해 동시 업데이트가 CPU에 미치는 영향을 줄일 수 있습니다.

하드웨어 업그레이드 및 서버 리소스 최적화 고려: 데이터베이스의 CPU가 계속해서 급증하고 위의 최적화 방법을 시도한 경우 더 나은 성능을 제공하기 위해 서버 하드웨어를 업그레이드하고 CPU 코어 수와 메모리 용량을 늘리는 것을 고려할 수 있습니다. 요약하자면, MySQL 데이터베이스의 CPU가 100%까지 치솟으면 쿼리문 최적화, 데이터베이스 연결 풀 설정 조정, 구성 매개변수 최적화, 데이터베이스 테이블 구조 최적화 및 동시 업데이트 작업 감소를 통해 문제를 해결할 수 있습니다. 문제가 지속되면 하드웨어 업그레이드 및 서버 리소스 최적화를 고려하십시오.

6. 수백억 개의 데이터를 테이블로 나눈 후 페이지 단위로 쿼리하는 방법은 무엇입니까?

테이블 분할 규칙 결정: 시간, 지역, 사용자 및 기타 조건에 따라 테이블을 분할하는 등 실제 요구 사항과 데이터 특성을 기반으로 적절한 테이블 분할 규칙을 선택합니다.

페이징 오프셋 계산: 각 페이지에 표시되는 데이터의 양과 현재 페이지 번호를 기반으로 건너뛰어야 하는 데이터의 양을 계산하고 페이징 오프셋을 얻습니다.

대상 테이블 찾기: 쿼리 조건의 키 필드를 기반으로 쿼리할 대상 테이블을 결정합니다.

대상 테이블 쿼리: 쿼리 조건 및 페이징 오프셋에 따라 대상 테이블의 데이터를 쿼리합니다. 샤딩 규칙과 인덱스를 사용하여 쿼리 속도를 높일 수 있습니다.

결과 세트 반환: 표시 또는 추가 처리를 위해 쿼리된 데이터를 애플리케이션에 반환합니다. 테이블을 분할한 후 페이징 쿼리를 수행할 때 테이블 간 상황, 즉 페이징 쿼리가 동시에 여러 분할 테이블을 쿼리해야 하는 상황이 발생할 수 있다는 점에 유의해야 합니다. 이때 공동 질의, 분산 질의 등의 기술을 이용하여 처리할 수 있다. 또한, 쿼리 효율성을 높이기 위해 전체 데이터 양, 각 테이블의 경계값 등 일부 통계 정보를 테이블 샤딩 과정에서 미리 계산하여 저장해 페이징 쿼리 시 최적화를 용이하게 할 수 있습니다. 정리하자면, 수백억 개의 데이터를 테이블로 분할한 후의 페이징 쿼리는 테이블 분할 규칙과 쿼리 조건에 따라 대상 테이블을 찾고 쿼리에 대한 페이징 오프셋을 계산해야 합니다. 동시에 인덱싱 및 사전 계산과 같은 기술을 사용하여 쿼리 효율성을 향상시킬 수 있습니다.

7. MySQL 쿼리 성능을 최적화하는 방법은 무엇입니까?

적절한 인덱스 사용: 쿼리 조건 및 테이블 특성에 따라 적절한 인덱스를 생성하여 쿼리 속도를 높입니다.

전체 테이블 스캔 방지: 쿼리되는 데이터의 양을 줄이려면 인덱스 없이 쿼리 조건을 사용하지 마세요.

쿼리문 최적화: 복잡한 쿼리문 사용을 피하고, 적절한 쿼리문을 사용하고, SELECT * 사용을 피하고, 필요한 열만 선택하세요.

페이징 쿼리 최적화: 대량의 데이터 쿼리를 피하기 위해 LIMIT 문을 사용하여 페이징 쿼리를 수행합니다.

서브 쿼리 및 임시 테이블 사용 방지: 서브 쿼리 및 임시 테이블 사용을 피하고 쿼리 문을 다시 작성하거나 JOIN을 사용하여 최적화할 수 있습니다.

과도한 정규화 방지: 데이터를 적절하게 중복하고 테이블의 관련 쿼리 수를 줄입니다.

테이블 구조 최적화: 너무 많은 필드와 불필요한 데이터 유형을 사용하지 않도록 테이블 구조를 적절하게 디자인합니다.

구성 매개변수 최적화: 서버의 하드웨어 구성 및 데이터베이스 로드에 따라 MySQL 구성 매개변수를 조정하여 성능을 향상시킵니다.

8. MySQL의 테이블 구조를 최적화하는 방법은 무엇입니까?

적절한 데이터 유형 사용: 적절한 데이터 유형을 선택하여 데이터를 저장하고 너무 길거나 큰 데이터 유형을 사용하지 마십시오.

정규화 및 중복성: 실제 요구 사항과 쿼리 빈도를 기반으로 정규화 및 중복성을 수행하여 관련 쿼리 수를 줄입니다.

인덱스의 합리적인 사용: 쿼리 조건과 테이블 특성에 따라 적절한 인덱스를 생성하여 쿼리 속도를 향상시킵니다.

파티셔닝된 테이블: 대규모 테이블의 경우 특정 필드의 범위를 기준으로 파티셔닝을 수행하여 쿼리 및 유지 관리 효율성을 향상시킬 수 있습니다.

수직 분할 및 수평 분할: 매우 큰 테이블의 경우 수직 분할과 수평 분할을 통해 테이블을 분할하여 단일 테이블의 데이터 양을 줄일 수 있습니다.

캐시 테이블 및 요약 테이블: 쿼리 빈도는 높지만 업데이트 빈도는 낮은 테이블의 경우 쿼리 결과를 테이블에 캐시하여 쿼리 속도를 향상시킬 수 있습니다.

9. MySQL 구성 매개변수를 최적화하는 방법은 무엇입니까?

서버의 하드웨어 구성 및 데이터베이스 로드에 따라 MySQL 구성 매개변수를 조정하여 성능을 향상시킵니다.

버퍼 크기 조정: 데이터베이스의 워크로드 및 메모리 크기에 따라 innodb_buffer_pool_size, key_buffer_size 등과 같은 매개변수를 조정하여 캐싱 효과를 향상시킵니다.

동시 연결 수 조정: 서버의 부하에 따라 max_connections 매개변수를 조정하여 동시 연결 수를 제어합니다.

쿼리 캐시 크기 조정: 쿼리의 특성 및 빈도에 따라 query_cache_size 매개변수를 조정하여 쿼리 캐시의 효과를 향상시킵니다.

로그 매개변수 조정: 필요에 따라 binlog_format, sync_binlog 및 기타 매개변수를 조정하여 로그 쓰기 및 동기화 속도를 향상시킵니다.

느린 쿼리 로그 활성화: 느린 쿼리 로그를 활성화하고, 쿼리 시간 임계값을 기준으로 느린 쿼리 문을 찾아 최적화합니다.

정기적인 최적화 및 유지 관리: 테이블과 인덱스를 정기적으로 분석 및 최적화하고, 데이터베이스 백업 및 최적화를 수행하여 데이터베이스 성능과 안정성을 유지합니다.

5. MySQL 보안

1. SQL 인젝션이란 무엇이며, SQL 인젝션을 방지하는 방법은 무엇인가요?

SQL 인젝션(SQL 인젝션)은 일반적인 보안 취약점 공격 방법으로, 공격자는 사용자가 입력한 데이터에 악성 SQL 코드를 주입하여 애플리케이션이 SQL 쿼리 실행 시 공격자가 구축한 악성 코드를 실행하게 하여 불법 접근으로 이어진다. 데이터베이스, 데이터 유출 또는 변조.
SQL 주입 공격을 방지하려면 다음 조치를 취할 수 있습니다.

매개변수화된 쿼리 또는 준비된 문을 사용합니다. 이는 사용자가 입력한 데이터를 SQL에 직접 연결하는 대신 SQL 쿼리에 매개변수로 전달하여 SQL 주입을 방지하는 가장 일반적인 방법입니다. 인젝션 공격을 효과적으로 방지할 수 있는 성명입니다.

입력 확인 및 필터링: 사용자가 입력한 데이터를 확인 및 필터링하고, 합법적인 입력만 허용하고, 특수 문자를 이스케이프합니다. 정규식, 화이트리스트 등을 사용하여 입력 유효성 검사를 수행할 수 있습니다.

ORM 프레임워크 사용: ORM 프레임워크를 사용하면 데이터베이스 작업을 추상화하고 SQL 문을 수동으로 연결할 가능성을 줄여 주입 가능성을 줄일 수 있습니다.

최소 권한 원칙: 데이터베이스 사용자는 최소한의 권한을 가져야 하며 공격자가 데이터베이스를 악용하는 것을 방지하기 위해 필요한 작업만 수행할 수 있습니다.

로깅 및 모니터링: 데이터베이스 운영을 적시에 기록 및 모니터링하고, 이상 운영을 적시에 감지하여 적시에 조치를 취할 수 있습니다.

방화벽 및 침입 탐지 시스템: 방화벽, 침입 탐지 시스템과 같은 보안 장치를 사용하여 침입을 모니터링하고 방지합니다.
요약하면, 매개변수화된 쿼리, 입력 유효성 검사 및 필터링, ORM 프레임워크 사용, 최소 권한 원칙, 로깅 및 모니터링, 보안 장치 등 다양한 조치를 취하면 SQL 주입 공격을 효과적으로 방지할 수 있습니다.

2. MySQL 데이터베이스의 보안을 어떻게 보호하나요?

강력한 비밀번호 사용: 복잡하고 길며 임의의 비밀번호를 설정하고 정기적으로 변경하세요.

접근 권한 제한: 필요한 사용자에게만 권한을 부여하고 접근 범위를 제한합니다.

정기적으로 데이터 백업: 데이터베이스를 정기적으로 백업하여 데이터 손실을 방지하고 백업 데이터를 안전한 장소에 보관하세요.

업데이트 및 패치 적용: 알려진 보안 취약성으로부터 보호하기 위해 패치 및 보안 업데이트를 통해 MySQL 및 운영 체제를 최신 상태로 유지하세요.

방화벽 사용: 방화벽을 사용하여 MySQL 포트에 대한 액세스를 제한하고 인증된 IP 주소만 연결하도록 허용합니다.

SSL/TLS 활성화: SSL/TLS를 사용하여 연결을 암호화하여 데이터 전송 보안을 보호합니다.

모니터링 및 감사: 데이터베이스 활동을 모니터링하고 감사를 수행하여 비정상적인 동작을 감지합니다.

불필요한 기능 비활성화: 불필요한 MySQL 기능 및 플러그인을 비활성화하여 잠재적인 보안 위험을 줄입니다.

3. MySQL 데이터베이스에 대한 액세스를 어떻게 제한하나요?

강력한 비밀번호 만들기: 각 사용자에 대해 강력한 비밀번호를 만들고 정기적으로 변경합니다.

사용자 권한 제한: 너무 많은 권한을 부여하지 않도록 사용자에게 필요한 최소한의 권한만 부여합니다.

방화벽 사용: 방화벽을 사용하여 MySQL 포트에 대한 액세스를 제한하고 인증된 IP 주소만 연결하도록 허용합니다.

원격 액세스 비활성화: MySQL에 대한 원격 액세스가 필요하지 않은 경우 구성 파일에서 원격 액세스를 비활성화할 수 있습니다.

네트워크 액세스 제한: 네트워크 수준에서 방화벽이나 네트워크 장치를 통해 MySQL 서버에 대한 액세스를 제한합니다.

SSL/TLS 암호화 연결 사용: SSL/TLS 암호화 연결을 활성화하여 전송 중 데이터 보안을 보호합니다.

IP 화이트리스트 사용: 특정 IP 주소의 사용자만 MySQL 서버에 액세스하도록 허용합니다.

4. MySQL 데이터베이스의 민감한 데이터를 어떻게 보호하나요?

데이터 암호화: 중요한 데이터를 암호화하여 저장하여 데이터가 도난당하더라도 해독할 수 없도록 합니다.

데이터 둔감화: 민감한 데이터를 둔감하게 하여 사용자 개인 정보를 보호합니다.

엄격한 액세스 제어: 중요한 데이터에 액세스하는 데 필요한 사용자에게만 권한을 부여하고 액세스 권한을 제한합니다.

정기 감사: 민감한 데이터의 접근 기록을 정기적으로 감사하여 이상 행위를 적시에 감지합니다.

데이터베이스 로깅 활성화: MySQL의 로깅 기능을 활성화하여 민감한 데이터의 액세스 및 수정 기록을 기록합니다.

데이터베이스 보안 강화: 해커로부터 데이터베이스 서버의 보안을 보호하여 민감한 데이터 유출을 방지합니다.

정기적으로 데이터 백업: 중요한 데이터를 정기적으로 백업하고 백업 데이터를 안전한 장소에 저장하여 데이터 손실이나 손상을 방지합니다. 위 내용은 MySQL 보안 관련 면접 질문과 답변입니다. 도움이 되셨으면 좋겠습니다.