한국어
한국어
MySQLI 확장자를 사용하는 경우 MySQLI :: STMT_INIT는 명령문 객체를 작성하는 표준 방법이며 준비 기능은 SQL 쿼리 문을 준비하는 데 사용됩니다. MySQLI 확장을 사용할 때 많은 개발자가 루프 또는 여러 쿼리에서 준비 기능이 반복적으로 호출되는 상황을 만날 수 있습니다. 그러나 기능을 준비하기위한 자주 호출이 성능에 영향을 미칩니 까? 이 기사는 실제 측정을 통해이 문제를 분석하고 최적화 제안을 제공합니다.
우선, mysqli :: stmt_init 의 역할을 이해하고 기능을 준비하는 것이 매우 중요합니다. mysqli :: stmt_init은 새 명령문 객체를 초기화하는 것이며 준비 기능은 SQL 문을 MySQL 데이터베이스 서버에 전달하고 준비하고 일반적으로 실행 전에 구문 검사 및 쿼리 최적화를 수행합니다.
$conn = new mysqli("localhost", "username", "password", "database");
$stmt = $conn->stmt_init();
if ($stmt->prepare("SELECT id, name FROM users WHERE email = ?")) {
$stmt->bind_param("s", $email);
$stmt->execute();
$stmt->close();
}
위의 코드는 mysqli :: stmt_init를 사용하고 쿼리 작업을 수행 할 준비를하는 방법을 보여줍니다.
준비하는 각 호출은 구문 분석 및 최적화를 위해 SQL 쿼리 명령문을 데이터베이스에 보냅니다. MySQL은 쿼리 명령문의 구문을 확인하고 실행 계획을 생성하며 결과를 캐시에 저장합니다. 쿼리 문이 동일하면 데이터베이스 시스템은 쿼리 캐시를 사용합니다. 그러나 동일한 쿼리 명령문 조차도 자주 전화하면 특히 높은 동시성 환경에서 추가 성능 오버 헤드가 발생할 수 있습니다.
// 오류 데모：매번 전화합니다 prepare 기능
foreach ($emails as $email) {
$stmt = $conn->stmt_init();
if ($stmt->prepare("SELECT id, name FROM users WHERE email = ?")) {
$stmt->bind_param("s", $email);
$stmt->execute();
$stmt->close();
}
}
이 예에서 준비 기능은 모든 루프라고 불리며 데이터베이스가 쿼리 될 때마다 데이터베이스를 구문 분석하고 실행 된 계획을 생성합니다.
MySQL 데이터베이스는 일반적으로 실행 된 쿼리를 캐시하지만 준비하기 위해 자주 호출하면 데이터베이스가 캐시 된 쿼리 실행 계획을 최대한 활용하여 CPU 및 메모리 오버 헤드가 증가하지 않습니다. 장기 반복 통화는 특히 많은 양의 데이터를 처리 할 때 응답 시간이 느려질 수 있습니다.
매번 준비를 하지 않기 위해 SQL 문은 사전 컴파일되고 재사용 될 수 있습니다. 쿼리가 여러 번 실행 되더라도 반복 준비 전화를 피해야합니다.
// 최적화 데모：한 번만 호출됩니다 prepare，후속 재사용
$stmt = $conn->stmt_init();
if ($stmt->prepare("SELECT id, name FROM users WHERE email = ?")) {
foreach ($emails as $email) {
$stmt->bind_param("s", $email);
$stmt->execute();
}
$stmt->close();
}
이 방법은 루프 외부에 준비된 호출을 넣고 하나의 사전 컴파일 작업 만 수행함으로써 데이터베이스의 반복 된 SQL 쿼리 구문 분석의 오버 헤드를 줄입니다.
쿼리를 하나씩 실행하는 대신 배치 작업을 사용하여 쿼리를 수행 할 수있는 경우 한 번에 여러 SQL 쿼리를 실행하면 성능이 향상 될 수 있습니다. MySQL에서는 트랜잭션 및 배치 인서트를 통해 여러 작업의 실행을 최적화 할 수 있습니다.
// 배치 실행 데모：트랜잭션을 사용하여 여러 쿼리를 수행하십시오
$conn->begin_transaction();
foreach ($emails as $email) {
$stmt->bind_param("s", $email);
$stmt->execute();
}
$conn->commit();
$stmt->close();
이 접근법은 데이터베이스 트랜잭션 및 연결의 전환을 줄여 성능을 향상시킬 수 있습니다.
동시 응용 프로그램이 높은 경우 연결 풀링 및 지속적인 연결은 데이터베이스 성능을 크게 향상시킬 수 있습니다. MySQLI는 지속적인 연결 기능을 제공하여 요청이 필요할 때마다 연결을 설정 하는 오버 헤드를 줄이고 반복 된 호출의 성능 영향을 더욱 줄입니다.
실제 테스트 중에 최적화와 최적화없이 두 시나리오의 성능 성능을 비교했습니다.
최적화가 없으면 데이터베이스는 일반적으로 SQL 쿼리가 더 복잡하고 성능 손실이 더 분명한 경우 각 호출마다 쿼리를 실행 하는 데 시간이 더 걸립니다.
기능을 준비하기 위한 통화 수와 재사용 명령문을 줄임으로써 실행 시간이 크게 단축됩니다. 특히 많은 양의 데이터를 처리 할 때 최적화 된 코드가 더 잘 수행됩니다.
최적화 없음 : 준비 할 때마다 쿼리를 실행하는 데 시간이 오래 걸리고 CPU 및 메모리 발자국이 높습니다.
최적화 후 : 사전 컴파일 된 문을 재사용하고 트랜잭션을 사용하여 배치로 실행할 때 쿼리 시간이 크게 단축되고 리소스 사용이 효과적으로 제어됩니다.
이 기사의 분석을 통해 기능을 준비하기 위해 자주 호출하면 특히 동시성이 높은 경우 및 복잡한 쿼리의 경우 데이터베이스 성능에 영향을 미친다는 결론을 내릴 수 있습니다. 성능을 향상 시키려면 다음과 같이 권장됩니다.
사전 컴파일 및 재사용 SQL 문.
트랜잭션을 사용하여 배치에서 여러 쿼리를 실행하십시오.
연결 풀 또는 지속적인 연결을 사용하여 연결 오버 헤드를 줄입니다.
위의 최적화 방법을 통해 응용 프로그램과 데이터베이스 간의 상호 작용 효율을 크게 개선하여 전체 성능을 최적화 할 수 있습니다.
