MySQL 저장 프로세스의 장단점 분석

MySQL 5.0 버전부터 스토리지 프로세스를 지원합니다.저장 프로세스(Stored Procedure)는 데이터베이스에 저장된 복잡한 프로그램으로 외부 응용 프로그램이 호출할 수 있도록 하는 데이터베이스 대상이다.저장 프로세스는 특정 기능을 완성하기 위한 SQL 문장 집합으로 컴파일되어 데이터베이스에 저장되며, 사용자는 저장 프로세스의 이름을 지정하고 매개 변수(선택 사항)를 지정하여 실행을 호출할 수 있습니다.
저장 프로세스는 SQL 문장의 복용률을 효과적으로 높일 수 있고 관련 SQL 그룹을 저장 프로세스에 넣으면 응용 프로그램의 여러 차례 조회로 인해 MySQL 서버와의 연결 지연과 점용되는 네트워크 자원을 피할 수 있다.다음은 id를 입력하여 지정한 id를 삭제하고 확장표의 학생 정보를 삭제하는 데 사용되는 저장 프로세스의 예입니다.이러한 방식으로 관련 데이터를 처리할 수 있으며, 응용 프로그램이 두 번 SQL 조작을 할 필요가 없다.

DROP PROCEDURE IF EXISTS delete_student_by_id;

delimiter $$

CREATE PROCEDURE delete_student_by_id(IN p_id INT)
BEGIN
	DELETE FROM t_students
  WHERE id = p_id;
      
  DELETE FROM t_students_info
  WHERE student_id = p_id;
END
$$
    
delimiter ;
일반적으로 스토리지 프로세스의 이점은 다음과 같습니다.
  • 데이터베이스 층에서 직접 실행함으로써 네트워크 대역폭의 점용을 줄이고 조회 작업의 실행 지연을 감소시킨다
  • 코드의 복용성과 유지보수성을 향상시키고 업무 규칙을 집합하여 일치성을 강화하며 안전성을 높일 수 있다
  • 안전성 우위와 우아한 권한 제어 수단을 가져올 수 있다.하나의 전형적인 예는 바로 은행의 이체 저장 과정이다.저장 프로세스는 하나의 업무에서 이체와 기록을 완성하여 후속 심사에 사용할 완전한 조작 로그를 기록합니다.관련 테이블에 대한 권한 부여 없이 저장 프로세스를 통해 액세스를 완료할 수 있습니다
  • 서버는 메모리 프로세스의 실행을 캐시합니다. 이렇게 하면 중복 실행의 부하를 줄일 수 있습니다
  • 저장 프로세스는 서버에 저장되기 때문에 서비스 명세서의 배치, 백업과 유지보수에 있어 저장 프로세스가 더욱 잘 유지보수된다
  • 응용 개발자와 데이터베이스 개발자의 업무를 분리할 수 있기 때문에 데이터베이스 소유자가 저장 과정을 작성하게 하고 일부 응용 개발자가 SQL 수준이 높지 않은 문제를 피할 수 있다.
  • 물론 이로운 점은 반드시 폐단이 있고 저장 프로세스에도 약간의 결함이 있을 수 있다.
  • MySQL은 좋은 개발 및 디버깅 도구를 제공하지 않기 때문에 저장 프로세스의 디버깅은 상대적으로 쉽지 않다
  • SQL 언어 자체의 효율은 응용 프로그램이 없는 프로그래밍 언어의 효율이 높고 상대적으로 초급이다.그래서 복잡한 업무를 처리하기 어렵다..
  • 저장 프로세스도 응용 배치의 복잡도를 증가시킬 수 있다. 응용 코드와 데이터베이스 테이블을 배치해야 할 뿐만 아니라 저장 프로세스를 배치해야 한다
  • 접속된 각 스토리지 프로세스의 실행 계획 캐시는 독립적입니다.만약 많은 연결이 같은 저장 프로세스를 호출한다면, 반복적으로 캐시하면 자원의 낭비를 초래할 것이다
  • 저장 프로세스는 실행 부합을 데이터베이스 서버로 옮겼기 때문에 데이터베이스 서버의 확장이 더욱 어렵고 응용 서버의 확장 대가보다 높을 것이다
  • 저장 프로세스가 차지하는 자원을 제어하기 어려워서 버그가 발생하면 서버가 다운될 수 있습니다
  • 저장 프로세스의 코드는 판독하기 어렵고, 단순히 CALL XYZ('A')와 같은 형식으로 저장 프로세스를 호출하면 느린 조회 로그를 분석하기 어렵다.저장 프로세스의 코드를 찾고 안에 있는 문장을 검사해야 하기 때문에..
  • 문장급의 binlog나 복제에 대해 저장 프로세스를 사용하면 많은 함정이 저장 프로세스를 사용할 수 없게 될 수 있다. 즉, 잠재적인 문제를 엄격하게 검사하지 않는 한.
  • 따라서 일반적으로 상술한 결함을 피하기 위해 저장 프로세스를 작고 간결하게 유지해야 한다.물론, 어떤 조작을 할 때, 저장 과정은 더욱 빨리 운행할 수 있으며, 특히 저장 과정에서 순환을 사용하여 여러 개의 작은 조회를 완성할 수 있다.만약 조회가 충분하게 작다면, SQL 문장과 네트워크 통신을 해석하는 것은 작업 부하가 너무 높은 중요한 요소가 된다.이럴 때 저장 프로세스의 장점이 뚜렷하게 드러날 것이다.다음 저장 프로세스 코드를 예로 들 수 있습니다.
    
    DROP PROCEDURE IF EXISTS insert_many_rows;
    
    delemiter //
    
    CREATE PROCEDURE insert_many_rows(IN loops INT)
    BEGIN
    	DECLARE v1 INT;
      SET v1=loops;
      WHILE v1 > 0 DO
      	INSERT INTO test_table values(NULL, 0,
                                     'aaaaaaaaaaaabbbbbbbbbb',
                                     'aaaaaaaaaaaabbbbbbbbbb');
        SET v1=v1-1;
      END WHILE;
    END
    //
    
    delemiter ;
    	
    
    애플리케이션과 동일한 기능을 비교한 결과 스토리지 프로세스를 사용하는 성능이 2배 이상 향상되었고 MySQL 에이전트를 사용하는 것보다 3배 이상 향상되었습니다.
    결론: 저장 프로세스는 현재 많이 사용되지 않지만 일부 안정적인 업무에 데이터베이스 서버와의 네트워크 요청이 너무 많거나 대량의 네트워크 대역폭을 차지하기 때문에 저장 프로세스를 사용하여 성능을 최적화하고 응답 속도를 높일 수 있다.그러나 저장 프로세스는 의향이 없는 오류로 인해 과도한 시간 검사 문제가 발생하지 않도록 반복적으로 검증해야 한다.
    다음은 MySQL 저장 프로세스의 장단점 분석에 대한 상세한 내용입니다. MySQL 저장 프로세스의 장단점에 대한 더 많은 자료는 저희 다른 관련 글을 주목해 주십시오!

    좋은 웹페이지 즐겨찾기