영상버전 : https://youtu.be/iTmkJ2iWJuU
지금 프로젝트에서 개발자들이 프로시저를 만들다보니
개발자의 의식의 흐름대로 데이터 처리를 만들다보니 커서를 이용해서 테이블 변수에 넣고
그걸. 변수로 다른 테이블에서 조회하는 식으로 짜놨네요..
튜닝할 때 항상 하는 이야기 이죠.. Trigger와 커서는 절대 쓰지 말라구요..
이것처럼 속도를 저하시키고 락을 유발 시키는 장치는 없거든요..
트리거는 트리거링 포인트가 되었을 때 대상 테이블을 락을 건 뒤에 트리거 처리를 하고 나서 락을 해제 하기 때문에 아무리 빨리 끝나도 동시에 들어오는 쿼리에 따라서는 데드락에 빠질 가능성도 있습니다.
마찬가지로 커서 역시 테이블을 열고 커서를 만들어 처리하기 때문에 그 모든 처리가 끝날 때까지 락이 걸린 상태가 됩니다. 데이터가 변동하면 안되니까요..
그래서 트리거와 커서를 사용하면 기본 서너배는 느려집니다.
커서랑 트리거만 없어도 50만명 받을 서비스가 15만명도 못받게 되는거죠..
경우에 따라서는 수백배 느리게 짤 수도 있는게 커서와 트리거 입니다.
그냥 서비스를 떨구든 말든 자기 편한대로 만들겠다는 생각이 있지 않는한 커서는 피하셔야 합니다.
개발자들이 커서를 많이 이용하는 이유는 커서를 이용해서 만들면 복잡한 처리를 할 때 별로 생각하지 않고 개발 코드처럼 만들어도 가능하기 때문이죠
이번 쿼리도 커서를 사용해서 아주 길게 만들어놨네요..
한 줄 읽어서 상태에 따라서 데이터를 매핑해서 테이블 변수에 넣고를 쭈욱 한 뒤에
그 테이블 변수를 다시 읽어서 다른 테이블의 값을 가져오는데..
튜닝을 잘하려면 이 모든 데이터가 머리속에 연결구조를 그려서
하나의 비정규화 된 배열을 만들 수 있어야 합니다.
매번 이야기 하지만,
DB엔진이 강력한 이유는 데이터 처리를 할 때
한 줄씩 읽어서 처리하는게 아니라 배열 계산을 해주기 때문에
배열 x 배열을 하는 시간과 한 라인 처리하는 시간이 거의 같습니다.
물론 엄밀히 이야기 하면 내부적으로 계산하는 개수가 있으니 조금 다르지만;;
커서로 10만줄을 계산하는 쿼리가 있어 1분 걸렸다면
배열 계산으로 0.05초 정도에 나오게 되죠..
배열을 한 번에 계산하는 능력이 CPU에는 있기 때문에
배열 처리 속도는 엄청나게 빠릅니다.
그래서 튜닝을 잘하는 사람은
배열을 잘 만들어서 계산을 던지는 사람인 것이지요.
이번에도 자세히 보니까 뭔가 무지무지 복잡하지만,
대충 머릿속에 그려보니 전부 JOIN 가능하지 않을까?
라는 생각을 했는데..
요즘 머리가 안돌아가고 귀차니즘이 발발..
이 때 생각난 것이 chatgpt..
너의 실력을 보여줘!
하고 쿼리를 통으로 던지고 커서좀 없애줘!
라고 간다하게 말했습니다.
그랬더니 커서를 JOIN으로 바꾼 결과를 주었네요!
오오오오!
실 데이터로 기존 SP와 커서를 뺀 새로만든 SP를 실행시켜 결과가 같음을 확인하고
이걸 그대로 고객에게 줬습니다.
성능은 약 10%가까지 향상 되었네요..
아마도 테이블 변수에 넣고 재쿼리 하고를 반복했기 때문에 커서로 인한 효과는 10%정도였나 봅니다.
그런데.. 잘 생각해보니.. 커서도 없애주는데 테이블 변수도 없애고 그냥 JOIN해도 되지 않나?
싶어서 chatgpt에게
커서를 없애고, 테이블 변수나 temp table도 없애줘.
라고 했더니..
뭔가 생각보다 많이 짧은 쿼리를 받았습니다.
이걸 SP v3으로 만들어서 서로 결과 비교를 했더니 정상으로 보이는 것 같네요..
성능을 비교했더니..
4배 빨라짐!
아주 좋잖아?
하고 줬는데… 문득 생각이 났습니다.
지금 이거 내가 아니고 고객이
내가 한 것처럼 chatgpt에게 지시만 하면
난 필요 없어지는거 아닌가?
음…
그래도 아직까진 이렇게 chatgpt에게 던지는 사람이 적다는 것에
가슴을 쓸어내리며
가급적 chatgpt가 이정도의 능력을 갖고 있다는 사실을
많은 사람이 알지 못하길 기도해봅니다. ;;;
이 정도까지 쿼리를 튜닝해버리면,
이젠 나를 부를 고객도 줄어들지 않을까
걱정을 해보면서
AI시대에
뭘로 먹고살지 고민을 하게 하는 하루였습니다.
댓글
댓글 쓰기