아까 밑에 데이터 수 십만행 넘어가니
다른 테이블과 조인 없고, 그냥 이 테이블로만 페이징하는데 시간 좆나 늘어난다고 물어봤는데
찾아보니까 특정 컬럼 때문에 인덱스 사용을 못하더라고 (그 컬럼에 인덱스는 걸어뒀음)
1. 시간 좆나게 늘어지게하는 컬럼 2개 발견함
2. 이 컬럼들 특징이 다른 PK테이블과 참조 관계에 있는 컬럼들임 (A컬럼, B컬럼이라고 칭하겠음)
3. A컬럼(FK)의 행들에는 딱 2가지의 문자열 값만 있음 Empty, ABCDE 그리고 PK에는 당연히 저 2가지 값이 있고...
4. B컬럼(FK)의 행들에는 딱 1가지의 문자열 값만 있음 Empty 그리고 PK에도 저 Empty 값만 있는 중
------
페이징에 검색 조건들마다 분기하고 하면 노가다 심하니까 모든 컬럼에 다 인덱스 비용 지불하고 편하게 Col1 LIKE @param1 + '%' AND Col2 LIKE @param2 + '%'....
이렇게 사용 중이고 페이징 위해서 Where ........ AND Number NOT IN ( TOP(...) .... Where ... ) 이런 식으로 innerJoin 발생되는 중
------
컬럼들이 20개 정도되는데 나머지 18개는 실행하면 바로 결과 뱉음, 퍼포먼스 문제 없음
저 2개의 컬럼들이 문제인데... 예를 들어 Empty와 ABCDE라는 PK값만 있는 참조관계에 있는 A컬럼을 조건문에 추가하면 결과 뱉는데 몇초로 늘어남
그리고 Empty값만 있는 PK와 참조 관계에 있는 B컬럼을 조건문에 추가하면 아주 오래걸림
그리고 쿼리 실행 플랜 들여다보니 저 B컬럼을 추가하면 Index Missing 발생함...
Empty만 있어서 그런가? 저 Empty만 있는 PK 테이블 인덱스 들여다보면 인덱스로 ssd공간 쓰고 있고 인덱싱 되어있던데...
그리고 별 상관 없을 거 같지만 모두 NONCLUSTERED INDEX임...
컬럼들이 allow null 해두면 컨트롤러에서 귀찮아서 db에는 모두 not null로 해두고 대신 참조관계 맺어야하는 곳들끼리 겹쳐서 검색할 때
한쪽은 값 있으면 한 쪽은 빈 값이어야해서 PK테이블에 Empty로 행 하나 넣어두고 그걸 참조하게 했는데
데이터 공간을 비용으로 그냥 지불하고 노가다 줄이려고 했는데 이런 문제를 맞닦뜨리니 너무 귀찮다...
그럼 왜 empty값만 들어있는 pk와 참조관계에 있는 fk컬럼에서 인덱스 미싱이 발생하는지 구글링하러 가볼게...
nosql쓰면 아예 조인이 없으니 그냥 편하게 되지 않나? nosql nosql 요즘 많이들 쓰던데 트랜잭션만 잘되는 거 있으면 써보고 싶다.
아 읽기 싫다
ㅄ아 읽을 줄 모르거지 뭐가 싫어. 여기 프갤 ㅄ들이 알 거 같냐?
너무 길어서 맨 아래만 읽었는데 nosql 에 조인이 없다는 건 조인이 셀프라는 뜻임;;;
암튼 한줄요약하면 SQL에서 empty값만 있는 pk와 참조관계에 있는 fk컬럼을 이너조인하면 그 empty값만 있는 fk 컬럼은 인덱싱을 못하고 풀스캔을 한다는 거임. 분명 empty도 값인데 인덱스 걸어둬서 인덱싱 중이고... 근데 사용을 못함. 왜 그런지는 솔직히 내가 dba도 아니고 왜 이런 것때문에 내가 고통받아야하나 좆같음
해당 댓글은 삭제되었습니다.
ㅄ아 뭐가 널값이야 empty라고 ㅄ새끼야
프갤 ㅄ새끼 아니랄까봐 어디 잠깐 보고 뭔가 아는 거 같다고 좆나 막 지껄이네 ㅄ새끼.
개소리 자제하시고요 ㅄ새끼야. empty도 값이야. 이 병신새끼는 빈값하고 널하고 구분을 못하네
돼 ㅄ새끼야. 저 empty랑 ABCDE만 있는 PK테이블가서 empty로 조건 걸고 돌리면 empty에 인덱싱 타고 결과 뱉는 거 볼 수 있음. ㅄ새끼가 자꾸 헛소리 지껄이고 있어.
ㅄ새끼야 SQL에서 empty도 값이라니까, 내가 ㅅㅂ련아 노파심 좆나 많은 성격이라 PK테이블에 empty 중복되나 안되나 안 넣어봤을 거 같냐? 허용 안돼 ㅄ아 PK야
ㅄ새끼야 SQL에서 empty도 값이고 null과 다르고, empty PK 걸면 중복 안돼 애미디진 년아. 그리고 SQL은 MS꺼야 오라클 꺼져 ㅄ아.
ㅄ아 김치에서나 sql을 rdb의 의미로 쓰지. 해외에서는 sql하면 그냥 mssql이야. 좆라클 꺼져.
나 db잘 모르긴 해. 별로 관심도 없고 이런 거는 그냥 클라우드가 서버 서비스하듯 db도 돈 받고 알아서 좀 해주면 안되나?
SQL 하면 MySQL이다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 진지 빨자면 SQL 표준 구현 정도를 주도하는 건 SQLite다 진심으로 하는 말임
안 알려줘도 돼. 솔직히 니가 하는 말 하나도 도움 안돼. 어차피 원인 찾아서 바로 해결됨.
원인 찾았으니 고치면되는데 좆나 하기 싫다. ㅅㅂ 서버처럼 db도 그냥 클라우드가 좀 해주면 안되나?
한줄요약만 보고 대충 하는 소린데 한 테이블의 PK 하나에 매칭되는 다른 테이블 FK row들이 양이 좀 많음? 뭐 정말 그런 거면 NoSQL들 상당수는 columnar니까 좀 나을 수도 있겠군 아니면 다른 기능 많은 RDB 써보던지 PostgreSQL 같은
ㅇㅇ 그게 지금 수 십만이고 한 달이면 많으면 거의 1억될 같은데
좀 찾아봤는데 그냥 이런 거 쓰면 될지도?
https://stackoverflow.com/questions/37801680/sql-partition-by-column-value
그리고 다른 얘긴데 그냥 artifical한 정수형 id 만들지 왜 굳이 string을 직접 PK로 만들었어? 정수형이면 동작이 다를지도 몰라 FK 매칭은 그 string을 UK 해서 하면 될 거 같은데 음?
ㅇㅇ 원인 찾았으니 해결은 할 수 있는데 좀 편하게 해보려고 꼼수부리다 도로 다시 일하려니 좆나 하기 싫다... 답변 ㄱㅅ
그 컬럼도 게시판의 검색처럼 그 안에 있는 값들로 다 AND AND AND 해서 한꺼번에 쉽게 검색되라고.. 지금은 empty만 있지만 나중에 서비스 내용에 따라 값 들어갈 거라고 예상한 컬럼이고...
ㅇㅇ semantic이 있는 PK가 편한건 맞는데... 하긴 NoSQL 쓰면 이런 건 신경 안 쓰고 모델링할 듯 일리가 있네