영상버전 : https://youtu.be/iTmkJ2iWJuU 지금 프로젝트에서 개발자들이 프로시저를 만들다보니 개발자의 의식의 흐름대로 데이터 처리를 만들다보니 커서를 이용해서 테이블 변수에 넣고 그걸. 변수로 다른 테이블에서 조회하는 식으로 짜놨네요.. 튜닝할 때 항상 하는 이야기 이죠.. Trigger와 커서는 절대 쓰지 말라구요.. 이것처럼 속도를 저하시키고 락을 유발 시키는 장치는 없거든요.. 트리거는 트리거링 포인트가 되었을 때 대상 테이블을 락을 건 뒤에 트리거 처리를 하고 나서 락을 해제 하기 때문에 아무리 빨리 끝나도 동시에 들어오는 쿼리에 따라서는 데드락에 빠질 가능성도 있습니다. 마찬가지로 커서 역시 테이블을 열고 커서를 만들어 처리하기 때문에 그 모든 처리가 끝날 때까지 락이 걸린 상태가 됩니다. 데이터가 변동하면 안되니까요.. 그래서 트리거와 커서를 사용하면 기본 서너배는 느려집니다. 커서랑 트리거만 없어도 50만명 받을 서비스가 15만명도 못받게 되는거죠.. 경우에 따라서는 수백배 느리게 짤 수도 있는게 커서와 트리거 입니다. 그냥 서비스를 떨구든 말든 자기 편한대로 만들겠다는 생각이 있지 않는한 커서는 피하셔야 합니다. 개발자들이 커서를 많이 이용하는 이유는 커서를 이용해서 만들면 복잡한 처리를 할 때 별로 생각하지 않고 개발 코드처럼 만들어도 가능하기 때문이죠 이번 쿼리도 커서를 사용해서 아주 길게 만들어놨네요.. 한 줄 읽어서 상태에 따라서 데이터를 매핑해서 테이블 변수에 넣고를 쭈욱 한 뒤에 그 테이블 변수를 다시 읽어서 다른 테이블의 값을 가져오는데.. 튜닝을 잘하려면 이 모든 데이터가 머리속에 연결구조를 그려서 하나의 비정규화 된 배열을 만들 수 있어야 합니다. 매번 이야기 하지만, DB엔진이 강력한 이유는 데이터 처리를 할 때 한 줄씩 읽어서 처리하는게 아니라 배열 계산을 해주기 때문에 배열 x 배열을 하는 시간과 한 라인 처리하는 시간이 거의 같습니다. 물론 엄밀히