Part of your World

SQL 오류 노트: 오류 코드 1064

#### 문제 설명

SQL 오류 코드 1064는 문법 오류를 나타냅니다. 이는 SQL 쿼리의 구문이 잘못되었음을 의미합니다. 주어진 쿼리에서 `LEFT JOIN` 구문이 잘못되었습니다. `LEFT JOIN` 뒤에는 조인할 테이블을 명시해야 합니다.

#### 발생 상황

`SELECT *   FROM tb_point p  LEFT JOIN tb_point_history ph ON p.ID = ph.POINT_ID;`

위 쿼리에서 `LEFT JOIN` 구문 사용에 문제가 발생했습니다.

#### 확인 사항

- `LEFT JOIN` 뒤에 어떤 테이블을 조인할 것인지 명확히 명시해야 합니다.
- 조인이 필요 없는 경우, 조인을 사용하지 않는 것이 좋습니다.

#### 해결 방안

조인 없이 값을 삽입하는 쿼리는 다음과 같이 수정할 수 있습니다:

INSERT INTO tb_point_history   
(POINT_ID, USE_POINT, TRANSACTION_ID, RETURN_VAL, 
RESIDUAL_POINT, CREATED_AT, CHARGEBOX_ID, CHARGEPOINT_ID, CONNECTOR_ID)   
VALUES       (
#{pointId}, #{usePoint}, #{transactionId}, #{returnVal},        
(SELECT p.`POINT`         
FROM tb_point p         
WHERE p.ID = #{pointId}         
LIMIT 1),        
CURRENT_TIMESTAMP, 
#{chargeBoxId}, 
#{chargePointId}, 
#{connectorId});

- `LEFT JOIN`을 사용하지 않고, 서브쿼리를 통해 `tb_point`에서 필요한 값을 직접 조회하여 삽입합니다.

#### 주의사항

- 항상 쿼리 문법을 검토하고, 테이블과 열 이름이 올바르게 지정되었는지 확인하십시오.
- SQL 쿼리의 실행 계획을 이해하고, 필요 없는 조인 사용을 피하십시오.

발생한 원인... 기존 홈페이지에서 서로 다른 테이블을 같은 쿼리 결과를 보여주고 싶을때!

UNION을 사용해야할때!

(SELECT
행1, 행2, 행3, 행4, 행5
FROM a.테이블
WHERE 조건)

UNION

(SELECT
행1, 행2, 행3, 행4, 행5
FROM b.테이블
WHERE 조건)

위처럼 사용할 수 있는데, 슬프게도… JPA에서는 사용할 수 없다..!

그래서 nativeQuery로 변경이 필요하다!

public interface RepositoryCustom {
    @Query(value = "(SELECT\\n" +
            "    행1, 행2, 행3, 행4, 행5\\n" +
            "FROM\\n" +
            "    a.테이블\\n" +
            "    INNER JOIN 조인할 테이블\\n" +
            "WHERE\\n" +
            "    id = di)\\n" +
            "\\n" +
            "UNION\\n" +
            "\\n" +
            "(SELECT\\n" +
            "    행1, 행2, 행3, 행4, 행5\\n" +
            "FROM\\n" +
            "    a.테이블\\n" +
            "    INNER JOIN 조인할 테이블\\n" +
            "WHERE\\n" +
            "    id = di)\\n" +
            "\\n",nativeQuery = true,
            countQuery = "SELECT COUNT(*) FROM a.테이블 INNER JOIN 조인할 테이블 WHERE id = :id\\n"+
                         "UNION\\n" +
                         "SELECT COUNT(*) FROM a.테이블 INNER JOIN 조인할 테이블 WHERE id = :id\\n")

    Page<DTO.ListData> findByList(Pageable pageable, DTO.ListRequest requestParam, @Param("id") int id);

}

이런식으로 Repository에 만들면 된다~~ 그리고 내가 실수한 부분은 countQuery부분이다..

SELECT COUNT(*) 에서 * 을 찾을 수 없고
countQuery 부분도 UNION으로 만들어야한다!

다음에는 틀리지 말자!!

낙관적 락

낙관적 락은 트랜잭션이 데이터에 대한 변경을 실제로 커밋하려고 할 때만 데이터 충돌이 발생할 것으로 가정한다.
이 방법은 데이터의 동시 액세스 충돌이 거의 발생하지 않는 시스템에서 잘 작동한다.
이는 각 트랜잭션이 충돌 없이 진행될 수 있다는 "낙관적" 가정에 기반을 두고 있다.

낙관적 락에서는 버전 번호, 타임스탬프, 또는 두 가지 모두를 사용하여 각 데이터 행이나 항목을 추적할 수 있다.
트랜잭션이 항목을 읽을 때, 그 항목의 버전 정보도 함께 읽힌다.
트랜잭션이 데이터를 업데이트하려고 할 때, 시스템은 해당 데이터 항목의 현재 버전이 트랜잭션 시작시 읽은 버전과 동일한지 확인한다.
만약 버전이 다르면, 다른 트랜잭션이 데이터를 변경했다는 것을 의미하며, 이 경우 충돌이 발생했다고 판단하고 업데이트를 거부한다.

이러한 방식은 병렬 처리를 최대화하고 잠금으로 인한 대기 시간을 최소화하는 데 있어 매우 유용하지만, 충돌이 자주 발생하는 시스템에서는 낙관적 락이 아닌 다른 방법을 고려해야 할 수 있다.
이런 경우엔 "비관적 락"이라는 다른 접근 방식을 사용하는 것이 더 효과적일 수 있다. 비관적 락은 트랜잭션이 데이터를 읽는 즉시 데이터를 잠그는 방법으로, 다른 트랜잭션들이 동일한 데이터를 변경하지 못하도록 한다. 이 방식은 충돌 가능성이 높은 시스템에서 유용하다.

비관적 락

비관적 락(Pessimistic Locking)은 동시성 제어를 위한 데이터베이스 잠금 메커니즘의 한 가지로, 다중 사용자가 동시에 데이터베이스의 동일한 데이터를 엑세스하려는 경우 데이터 무결성을 보호하는 방법이다.

비관적 잠금은 이름에서 알 수 있듯이, 충돌이 발생할 가능성이 높다고 "비관적으로" 가정한다.
따라서 이 메커니즘은 트랜잭션이 해당 데이터를 처음 읽는 시점에서 잠금을 설정한다.
이렇게 하면 해당 트랜잭션이 종료되어 잠금이 해제될 때까지 다른 트랜잭션에서는 해당 데이터에 대한 변경을 시도할 수 없다.

예를 들어, 데이터베이스에서 특정 레코드를 읽고 변경하려는 트랜잭션이 있다고 가정할때,
비관적 잠금을 사용하는 경우, 이 트랜잭션이 해당 레코드를 읽는 즉시 해당 레코드는 잠긴다.
그 결과, 다른 트랜잭션들은 그 레코드를 수정하거나 삭제할 수 없게 된다.
이 트랜잭션이 작업을 마치고 레코드의 잠금을 해제하면, 그제서야 다른 트랜잭션들이 해당 레코드에 접근할 수 있게 된다.

비관적 락의 주요 단점은 데이터에 대한 접근이 제한되므로, 대기 시간이 길어질 수 있다는 것이다.
이는 특히 공유 데이터에 대해 많은 사용자가 거의 동시에 작업을 시도하는 경우에 문제가 될 수 있다.
그러나 이 방법은 데이터 무결성을 보장하며, 충돌이 예상되는 환경에서는 매우 유용하다.