첫 번째 정규형: 필드 원자성, 두 번째 정규형: 행은 고유하고 기본 키 열을 가지며, 세 번째 정규형: 각 열은 기본 키 열과 관련됩니다.
실제 응용에서는 관련 테이블 수를 줄이고 쿼리 효율성을 높이기 위해 소수의 중복 필드를 사용합니다.
MySQL 데이터베이스 자체가 차단되었습니다. 예: 시스템 또는 네트워크 리소스 부족
SQL 문이 차단되었습니다. 예: 테이블 잠금, 행 잠금 등으로 인해 스토리지 엔진이 해당 작업을 실행하지 못하게 됩니다. SQL 문
인덱스를 잘못 사용하고 인덱싱을 하지 않아서 발생한 현상입니다
테이블에 있는 데이터의 특성상 인덱싱을 사용하지만 테이블 반환 횟수가 엄청납니다
count(*), count(constant), count(primary key) 형식의 개수 함수의 경우 옵티마이저 스캔 비용이 가장 적은 인덱스를 선택하여 쿼리를 실행하면 효율성이 향상됩니다. count(*)、count(常数)、count(主键)形式的count函数来说，优化器可以选择扫描成本最小的索引执行查询，从而提升效率，它们的执行过程是一样的。
而对于count(非索引列)来说，优化器选择全表扫描，说明只能在聚集索引的叶子结点顺序扫描。
count(二级索引列)
count(비인덱스 열)의 경우 최적화 프로그램은 전체 테이블 스캔을 선택합니다. 즉, 클러스터형 인덱스의 리프 노드만 순차적으로 스캔할 수 있습니다. 
count (보조 인덱스 열)는 쿼리 실행을 위해 지정한 열이 포함된 인덱스만 선택할 수 있기 때문에 옵티마이저가 선택한 인덱스 실행 비용이 가장 적게 들지 않을 수 있습니다.
커버링 인덱스로 최적화: MySQL 쿼리가 인덱스에 완전히 도달하면 이를 커버링 인덱스라고 합니다. 쿼리는 인덱스에서만 검색하면 되고 나중에 테이블로 돌아가지 않고 바로 반환될 수 있기 때문에 매우 빠릅니다. 따라서 데이터를 얻으려면 먼저 인덱스의 ID를 찾은 다음 ID를 기반으로 데이터를 얻을 수 있습니다.
업무상 허용되는 경우 페이지 수를 제한하세요
적절한 인덱스 추가: 쿼리 조건으로 사용되는 필드에 대한 인덱스를 생성하고 정렬하고, 여러 쿼리 필드를 고려하여 결합된 인덱스를 설정하고, 결합된 인덱스 필드의 순서에 주의하고, 가장 일반적으로 사용되는 열을 배치합니다. 맨 왼쪽에서 내림차순으로 제한 조건으로 사용되며 인덱스는 일반적으로 5개 이내로 너무 많지 않아야 합니다.
테이블 구조 최적화: 숫자 필드가 문자열 유형보다 낫고, 작은 데이터 유형이 일반적으로 더 좋습니다. NOT NULL을 사용해 보세요
쿼리 문 최적화: SQL 실행 계획 분석, 인덱스에 도달하는지 여부 등 SQL이 매우 복잡하다면 SQL 구조를 최적화하세요. 테이블 데이터의 양이 너무 많으면 테이블 분할을 고려해보세요
show processlist를 실행한 결과 수천 개의 연결이 보였습니다. 이는 동시 연결을 의미합니다.
"현재 실행 중" 문은 동시 쿼리입니다.
동시 연결 수가 많으면 메모리에 영향을 미칩니다.
너무 높은 동시 쿼리는 CPU에 좋지 않습니다. 머신에는 제한된 수의 CPU 코어가 있으며 모든 스레드가 돌진하면 컨텍스트 전환 비용이 너무 높아집니다.
스레드가 잠금 대기에 들어간 후에는 동시 스레드 수가 1개 감소하므로 행 잠금 또는 간격 잠금을 기다리는 스레드는 개수 범위에 포함되지 않습니다. 즉, 잠금을 기다리는 스레드는 CPU를 소비하지 않으므로 전체 시스템이 잠기는 것을 방지할 수 있습니다.
동일한 데이터는 업데이트되지 않습니다.
다양한 binlog 형식에 따라 로그 처리 방법이 다릅니다.
1) 행 모드를 기반으로 하는 경우 서버 계층은 업데이트할 레코드를 일치시키고 새 값이 이전 값과 일치하는지 확인합니다. 값이므로 아무런 조치도 취하지 않습니다. 업데이트되면 binlog를 기록하지 않고 바로 반환됩니다.
2) 명령문 또는 혼합 형식을 기반으로 하는 경우 MySQL은 업데이트 명령문을 실행하고 해당 업데이트 명령문을 binlog에 기록합니다.
datetime의 날짜 범위는 1001-9999입니다. timestamp의 시간 범위는 1970-2038입니다.
datetime 저장 시간은 시간대와 관련이 없으며 표시되는 값도 다릅니다. on 시간대의 저장 공간
datetime은 8바이트이고, 타임스탬프의 저장 공간은 4바이트입니다.
datetime의 기본값은 null이 아니며 기본값은 null입니다. 현재 시간(current_timestamp)
"Read Uncommitted"는 가장 낮은 수준이며 어떠한 상황에서도 보장할 수 없습니다.
"Read Committed"는 더티 읽기 발생을 방지할 수 있습니다.
"Repeatable Read"(반복 읽기)는 더티 읽기 및 반복 불가능 읽기 발생
"직렬화 가능"은 더티 읽기, 반복 불가능 읽기 및 팬텀 읽기의 발생을 방지할 수 있습니다
Mysql의 기본 트랜잭션 격리 수준은 "반복 읽기"입니다
kill 쿼리 + 스레드 ID는 이 스레드에서 실행 중인 명령문을 종료한다는 의미입니다.
kill 연결 + 스레드 ID, 여기서 연결은 기본값이 될 수 있습니다. 이 스레드 연결을 끊는다는 뜻입니다.
리프 노드의 내용에 따라 인덱스 유형은 기본 키 인덱스와 비기본 키 인덱스로 구분됩니다.
기본 키 인덱스의 리프 노드는 전체 데이터 행을 저장합니다. InnoDB에서는 기본 키 인덱스를 클러스터형 인덱스라고도 합니다.
기본 키가 아닌 인덱스의 리프 노드 내용은 기본 키 값입니다. InnoDB에서는 기본 키가 아닌 인덱스를 보조 인덱스라고도 합니다.
클러스터형 인덱스: 클러스터형 인덱스는 기본 키로 생성된 인덱스입니다. 클러스터형 인덱스는 테이블의 리프 노드에 데이터를 저장합니다.
비클러스터형 인덱스: 기본 키가 아닌 인덱스로 생성된 인덱스는 리프 노드에 기본 키와 인덱스 열을 저장하여 데이터를 쿼리할 때 필요합니다. 리프에서 기본 키를 가져온 다음 찾을 데이터를 찾습니다. (기본 키를 가져온 다음 검색하는 과정을 테이블 반환이라고 합니다.)
커버링 인덱스: 쿼리되는 열이 인덱스에 해당하는 열이고 조회를 위해 테이블로 돌아갈 필요가 없다고 가정하면 이 인덱스 열을 커버링 지수.
해시 인덱스는 단일 데이터 행의 추가, 삭제, 수정 및 쿼리를 O(1) 속도로 처리할 수 있지만, 범위 쿼리나 정렬에 직면하면 전체 테이블 스캔 결과로 이어집니다.
B-트리는 리프가 아닌 노드에 데이터를 저장할 수 있습니다. 모든 노드에는 대상 데이터가 포함될 수 있으므로 조건을 충족하는 데이터 행을 찾으려면 항상 루트 노드에서 아래쪽으로 하위 트리를 탐색해야 합니다. 임의 I/O 수가 많아지면 성능 저하가 발생합니다.
B+ 트리의 모든 데이터 행은 리프 노드에 저장되며, 이러한 리프 노드는 아래와 같이 B+ 트리의 데이터를 탐색할 때 "포인터"를 통해 순서대로 연결될 수 있습니다. 하위 노드 파일 사이를 점프하면 디스크 I/O 시간을 많이 절약할 수 있습니다.
이진 트리: 트리 높이가 고르지 않고 자체 균형을 유지할 수 없습니다. 검색 효율성은 데이터(트리 높이)와 관련이 있으며 IO 비용이 높습니다.
Red-black 트리: 데이터 양이 증가할수록 트리 높이가 증가하며 IO 비용이 높습니다.
InnoDB에서 데이터의 전체 행을 저장하는 인덱스 B+ 트리의 리프 노드는 기본 키 인덱스, 즉 클러스터형 인덱스라고도 하며 데이터 저장소와 인덱스를 함께 찾는 경우입니다. 당신은 데이터를 찾을 수 있습니다.
인덱스 B+Tree의 리프 노드에는 기본 키가 아닌 인덱스인 기본 키 값이 저장되며, 비클러스터형 인덱스 또는 보조 인덱스라고도 합니다.
첫 번째 인덱스는 일반적으로 순차 IO이며, 테이블로 돌아가는 동작은 랜덤 IO입니다. 테이블로 반환해야 하는 횟수가 많을수록, 즉 필요한 임의 IO 횟수가 많을수록 전체 테이블 스캔을 더 많이 사용하는 경향이 있습니다.
반드시 쿼리 문에 필요한 모든 필드가 인덱스에 도달하는지 여부가 포함됩니다. 모든 필드가 인덱스에 도달하면 테이블에 다시 쿼리를 수행할 필요가 없습니다. 인덱스는 쿼리해야 하는 모든 필드의 값을 포함(커버)하며, "커버링 인덱스"라고 합니다.
다중 열 인덱스를 생성할 때 비즈니스 요구에 따라 가장 왼쪽 접두사 원칙이 가장 왼쪽에 배치됩니다.
MySQL은 범위 쿼리(>, <, between, like)를 만날 때까지 오른쪽으로 일치를 계속한 다음 a = 1 및 b = 2 및 c > 3 및 d와 같은 일치를 중지합니다. = 4. ( a, b, c, d 순서의 인덱스)인 경우 d는 인덱스에 사용되지 않습니다. (a, b, d, c)의 인덱스를 생성하면 사용할 수 있습니다. a, b, d는 임의로 조정될 수 있습니다.
= 그리고 in은 a = 1, b = 2, c = 3과 같이 순서가 잘못될 수 있습니다. MySQL의 쿼리 최적화 프로그램은 순서에 관계없이 (a, b, c) 인덱스를 생성할 수 있습니다. 색인이 인식할 수 있는 형태로 변환됩니다.
가장 왼쪽 접두사 원칙이 충족되면 가장 왼쪽 접두사를 사용하여 인덱스에서 레코드를 찾을 수 있습니다.
MySQL 5.6 이전에는 ID부터 시작하여 테이블을 하나씩만 반환할 수 있었습니다. 기본 키 인덱스에서 데이터 행을 찾은 다음 필드 값을 비교합니다.
MySQL 5.6에 도입된 인덱스 조건 푸시다운 최적화(인덱스 조건 푸시다운)는 인덱스 순회 과정에서 인덱스에 포함된 필드를 먼저 판단하고 조건에 맞지 않는 레코드를 직접 필터링하고 테이블 수를 줄일 수 있습니다. 보고.
테이블이 자동 증가 기본 키를 사용하는 경우 새 레코드가 삽입될 때마다 레코드는 현재 인덱스 노드의 후속 위치에 순차적으로 추가됩니다. 페이지가 가득 차면 새 페이지가 추가됩니다. 자동으로 열립니다. 자동 증가하지 않는 기본 키(예: 학번, 학번 등)를 사용하는 경우 매번 삽입되는 기본 키의 값은 대략 무작위이므로 각각의 새 레코드는 중간에 삽입되어야 합니다. 기존 인덱스 페이지 이동 및 페이징 작업으로 인해 대량의 조각화가 발생하고 인덱스 구조가 충분히 압축되지 않았습니다. 결과적으로 테이블을 다시 작성하고 채워진 페이지를 최적화하기 위해 OPTIMIZE TABLE(테이블 최적화)을 사용해야 했습니다.
"원자성": 트랜잭션 실행 중 오류가 발생하거나 사용자가 롤백을 실행하면 시스템은 언두 로그를 통해 트랜잭션 시작 상태를 반환합니다.
"지속성": 이를 달성하려면 리두 로그를 사용하세요. 리두 로그가 지속되는 한 시스템이 충돌할 때 리두 로그를 통해 데이터를 복구할 수 있습니다.
"격리": 트랜잭션은 잠금 및 MVCC를 통해 서로 격리됩니다.
"일관성": 동시 상황에서 롤백, 복구 및 격리를 통해 일관성을 달성합니다.
InnoDB 스토리지 엔진: B+ 트리 인덱스의 리프 노드는 데이터 자체를 저장합니다.
MyISAM 스토리지 엔진: B+ 트리 인덱스의 리프 노드는 데이터의 물리적 주소를 저장합니다. InnoDB는 데이터 파일 자체가 인덱스 파일인데, MyISAM에 비해 테이블 데이터 파일 자체는 B+Tree로 구성된 인덱스 구조입니다. 이 인덱스의 키는 테이블의 기본 키이므로 InnoDB 테이블 데이터 파일 자체가 "클러스터형 인덱스" 또는 클러스터형 인덱스라고 하는 기본 인덱스이고 나머지 인덱스는 보조 인덱스 역할을 합니다. 보조 인덱스의 데이터 필드에는 주소 대신 해당 레코드의 기본 키 값이 저장되는데, 이는 MyISAM과도 다릅니다.
기본 키 인덱스의 리프 노드는 전체 데이터 행을 저장합니다. InnoDB에서는 기본 키 인덱스를 클러스터형 인덱스라고도 합니다.
기본 키가 아닌 인덱스의 리프 노드 내용은 기본 키 값입니다. InnoDB에서는 기본 키가 아닌 인덱스를 보조 인덱스라고도 합니다.
인덱스에 왼쪽 또는 왼쪽 퍼지 일치를 사용합니다. 즉, %xx 또는 %xx%와 같은 두 방법 모두 인덱스 오류를 발생시킵니다. 그 이유는 쿼리 결과가 "Chen Lin, Zhang Lin, Zhou Lin" 등이 될 수 있어서 어떤 인덱스 값으로 비교를 시작해야 할지 모르기 때문에 전체 테이블 스캔을 통해서만 쿼리할 수 있기 때문입니다.
인덱스에 함수 사용/인덱스에 대한 계산 표현식: 인덱스는 함수에 의해 계산된 값이 아닌 인덱스 필드의 원래 값을 저장하기 때문에 당연히 인덱스를 사용할 방법이 없습니다.
인덱스에 대한 암시적 유형 변환: 새로운 함수를 사용하는 것과 같습니다.
WHERE 절에서 OR의 의미는 두 조건 중 하나만 만족한다는 의미이므로 조건 열이 하나만 있으면 의미가 없습니다. 인덱스 컬럼 예, 조건 컬럼이 인덱스 컬럼이 아닌 한 전체 테이블 스캔이 수행됩니다.
확장 중지(권장하지 않음)
이중 쓰기 마이그레이션 계획: 확장된 테이블 구조 계획을 설계한 후 단일 데이터베이스와 하위 데이터베이스에 대해 이중 쓰기를 구현합니다. 문제가 없으면 단일 데이터베이스를 닫습니다. 잠시 동안 읽기 트래픽이 안정되면 단일 데이터베이스의 쓰기 트래픽을 닫고 하위 데이터베이스 및 하위 테이블로 원활하게 전환합니다.
서버 계층에서 SQL을 순차적으로 실행하는 단계는 다음과 같습니다.
클라이언트 요청 -> 커넥터(사용자 ID 확인, 권한 부여) -> 캐시가 존재하는 경우 직접 반환 존재하지 않는 경우 후속 작업을 수행합니다) -> 분석기(SQL에 대한 어휘 분석 및 구문 분석 작업) -> 최적화 프로그램(주로 SQL 최적화 실행을 위한 최적의 실행 계획 방법 선택) -> 실행기(실행) 이 엔진에서 제공하는 인터페이스를 사용하기 전에 먼저 사용자에게 실행 권한이 있는지 확인합니다. -> 엔진 레이어로 이동하여 데이터 반환을 얻습니다(쿼리 캐시가 켜져 있으면 쿼리 결과가 캐시됩니다).
MySQL은 정렬을 위해 각 스레드에 메모리(sort_buffer)를 할당합니다. 메모리 크기는 sort_buffer_size입니다.
정렬할 데이터의 양이 sort_buffer_size보다 작으면 메모리에서 정렬이 완료됩니다.
정렬된 데이터의 양이 크고 메모리에 너무 많은 데이터를 저장할 수 없는 경우 디스크의 임시 파일을 사용하여 정렬을 지원합니다(외부 정렬이라고도 함).
외부 정렬을 사용하는 경우 MySQL은 이를 여러 개의 별도 임시 파일로 나누어 정렬된 데이터를 저장한 다음 이러한 파일을 하나의 큰 파일로 병합합니다.
MVCC(다중 버전 동시성 제어)는 동일한 데이터의 여러 버전을 유지하여 동시성 제어를 달성하는 방법입니다. 쿼리 시 읽기 뷰와 버전 체인을 통해 해당 버전의 데이터를 찾습니다.
기능: 동시성 성능을 향상시킵니다. 동시성이 높은 시나리오의 경우 MVCC는 행 수준 잠금보다 비용이 저렴합니다.
MVCC의 구현은 테이블의 세 가지 숨겨진 필드를 통해 구현되는 버전 체인에 의존합니다.
1) DB_TRX_ID: 현재 트랜잭션 ID, 트랜잭션의 시간 순서는 트랜잭션 ID의 크기로 판단됩니다.
2) DB_ROLL_PRT: 롤백 포인터는 현재 행 레코드의 이전 버전을 가리킵니다. 이 포인터를 통해 여러 버전의 데이터가 함께 연결되어 실행 취소 로그 버전 체인을 형성합니다.
3) DB_ROLL_ID: 기본 키. 데이터 테이블에 기본 키가 없으면 InnoDB가 자동으로 기본 키를 생성합니다.
redolog 및 binlog가 영구 디스크를 보장하는 한, binlog 쓰기 메커니즘은 MySQL이 비정상적으로 다시 시작된 후 데이터 복구를 보장할 수 있습니다.
redolog는 시스템 예외 발생 후 손실된 데이터를 다시 실행할 수 있도록 보장하고, binlog는 손실된 데이터를 복구할 수 있도록 데이터를 보관합니다.
트랜잭션 실행 전에 리두로그를 작성하세요. 트랜잭션이 실행되는 동안 로그는 먼저 binlog 캐시에 기록됩니다. 트랜잭션이 제출되면 binlog 캐시가 binlog 파일에 기록됩니다.
데이터 항목이 삭제된 후 InnoDB는 페이지 A를 재사용 가능으로 표시합니다.
전체 테이블의 데이터를 삭제하는 삭제 명령은 어떻습니까? 결과적으로 모든 데이터 페이지는 재사용 가능으로 표시됩니다. 그러나 디스크에서는 파일이 작아지지 않습니다.
많은 추가, 삭제, 수정을 거친 테이블에는 구멍이 있을 수 있습니다. 이 구멍도 공간을 차지하기 때문에 이 구멍을 제거하면 테이블 공간을 축소하려는 목적을 달성할 수 있습니다.
테이블을 다시 구성하면 이 목적을 달성할 수 있습니다. alter table Aengine=InnoDB 명령을 사용하여 테이블을 다시 빌드할 수 있습니다.
row 형식 binlog는 작업 행의 기본 키 ID와 각 필드의 실제 값을 기록하므로 기본 및 백업 작업 데이터에 불일치가 없습니다. .
statement: 기록된 소스 SQL 문
mixed: 처음 두 개가 혼합되어 있는데 왜 혼합 형식의 파일이 필요한가요? 명령문 형식의 일부 binlog는 기본 로그와 백업 로그 사이에 불일치를 일으킬 수 있기 때문에 행 형식이 사용됩니다. 하지만 행 형식의 단점은 많은 공간을 차지한다는 것입니다. MySQL은 타협을 취했습니다. MySQL 자체는 이 SQL 문이 기본 서버와 보조 서버 사이에 불일치를 일으킬 수 있는지 여부를 판단합니다. 가능하면 행 형식을 사용하고, 그렇지 않으면 명령문 형식을 사용합니다.
원리 1: 잠금의 기본 단위는 다음 키 잠금이고, 다음 키 잠금은 전면 열기 및 후면 닫기 간격입니다.
원칙 2: 검색 프로세스 중에 액세스된 개체만 잠깁니다.
최적화 1: 인덱스에 대한 동등한 쿼리, 고유 인덱스를 잠그면 다음 키 잠금이 행 잠금으로 변질됩니다.
최적화 2: 인덱스에 대한 동등한 쿼리의 경우 오른쪽으로 순회하고 마지막 값이 동등 조건을 충족하지 않으면 다음 키 잠금이 간격 잠금으로 변질됩니다.
버그: on the 고유 인덱스 범위는 조건을 충족하지 않는 첫 번째 값까지 액세스를 쿼리합니다.
"더티 읽기(Dirty reading)": 더티 읽기(Dirty reading)는 다른 트랜잭션에서 커밋되지 않은 데이터를 읽는 것을 의미합니다. 데이터가 존재하지 않습니다. 결국에는 존재하지 않을 수도 있는 데이터를 읽는 것을 더티 읽기(dirty reading)라고 합니다.
"반복 불가능한 읽기": 반복 불가능한 읽기는 트랜잭션 내에서 처음에 읽은 데이터가 트랜잭션이 끝나기 전 언제든지 읽은 동일한 데이터 배치와 일치하지 않는 상황을 나타냅니다.
"팬텀 읽기": 팬텀 읽기는 두 번의 읽기로 얻은 결과 집합이 다르다는 것을 의미하지 않습니다. 팬텀 읽기의 초점은 특정 선택 작업으로 얻은 결과의 데이터 상태가 후속 비즈니스 작업을 지원할 수 없다는 것입니다. 보다 구체적으로 말하면, 특정 레코드가 존재하는지 여부를 선택하고, 존재하지 않는 경우 레코드를 삽입할 준비를 합니다. 그러나 삽입 실행 시 해당 레코드가 이미 존재하므로 이때는 팬텀 읽기를 수행할 수 없습니다. 발생합니다.
잠금 유형에는 공유 잠금과 단독 잠금이 있습니다.
1) 공유 잠금: 읽기 잠금이라고도 하며, 사용자가 데이터를 읽으려는 경우 여러 공유 잠금을 동시에 추가할 수 있습니다.
2) 배타적 잠금: 쓰기 잠금이라고도 하며, 사용자가 데이터를 쓰고자 할 때 데이터에 배타적 잠금을 추가할 수 있으며, 다른 배타적 잠금 및 공유 잠금과 함께 배타적입니다. .
잠금의 세분성은 특정 스토리지 엔진에 따라 다릅니다. InnoDB는 행 수준 잠금, 페이지 수준 잠금 및 테이블 수준 잠금을 구현합니다.
잠금 오버헤드는 큰 것부터 작은 것까지 다양하며 동시성 성능도 큰 것부터 작은 것까지 다양합니다.
마스터의 업데이트 이벤트(업데이트, 삽입, 삭제)가 순서대로 bin-log에 기록됩니다. 슬레이브가 마스터에 연결되면 마스터 머신은 슬레이브에 대한 binlog dump 스레드를 열고 스레드는 bin-log 로그를 읽습니다. bin-log中。当Slave连接到Master的后,Master机器会为Slave开启binlog dump线程,该线程会去读取bin-log日志。
Slave连接到Master后,Slave库有一个I/O线程 通过请求binlog dump thread读取bin-log日志,然后写入从库的relay log日志中。
Slave还有一个 SQL线程
I/O 스레드가 있습니다. 로그에 있는 도서관의 릴레이 로그 코드>입니다. SQL 스레드도 있습니다. 2. Mysql 마스터-슬레이브 복제 동기화 방법은 무엇입니까?
비동기 복제:
Mysql 마스터-슬레이브 동기화는 기본적으로 비동기 복제됩니다. 즉, 위의 세 단계 중 첫 번째 단계만 동기식입니다(즉, Mater가 bin 로그 로그를 작성합니다). 즉, 마스터 라이브러리는 binlog 로그를 작성한 후 binlog를 기다리지 않고 클라이언트에 성공적으로 반환할 수 있습니다. 슬레이브 라이브러리로 전송할 로그입니다.동기 복제:
동기 복제의 경우 마스터 호스트가 슬레이브 호스트에 이벤트를 보낸 후 모든 슬레이브 노드(슬레이브가 여러 개인 경우)가 데이터 복제 성공 정보를 마스터에 반환할 때까지 대기합니다.위 내용은 MySQL의 기본적인 문제는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
