1	비공개 손님 … 2015-04-01 13:05:52
	캐싱 아닐런지? 예를 들어 오라클의 경우에 같은 세션으로 같은 쿼리를 날리면 이전에 보낸 쿼리 응답을 그대로 다시 사용하는 경우도 있습니다.

2	비공개 손님 … 2015-04-01 13:07:28
	그게... ibatis (데몬)에서 날린 쿼리를 query edit 에서 날려도 같은 현상이 보여집니다... 다른 세션. 다른 커넥션에서도 그렇다는건데 .....

3	비공개 손님 … 2015-04-01 13:08:05
	뭐라고 검색해야하지...

4	비공개 손님 … 2015-04-01 13:11:43
	1이 답입니다 검색하고 뭐하고 할것도 없이 그냥 튜닝 하셔야겠네요

5	비공개 손님 … 2015-04-01 13:18:36
	답변 감사합니다 튜닝이 나을지 모든 경우의수를 스케쥴링으로 들고있는게 나을지 고민을 해봐야될거같습니다

6	비공개 손님 … 2015-04-01 13:24:55
	60초나 걸리는건 쿼리문 자체가 제대로 되어있는지도 확인 해보셔야할듯요 참조항이 너무 많거나 카티셜 조인을 사용하고 있는게 아닌지 ...

8	비공개 손님 … 2015-04-01 13:58:33
	EXPLAIN 으로 쿼리 내용 분석부터 해 보시져 아마 제생각에는 vtable join 이나 n*n 연산 발생해서 그런것같은데

9	비공개 손님 … 2015-04-01 14:14:12
	개발 할 때 쿼리 주기적으로 펑펑 널려서 캐시 생각못하고 어련히 빠르겠구나하고 짰는데 이거 ;ㄴㅇ;;;;

10	비공개 손님 … 2015-04-01 14:21:06
	1. 아니 글쎄 풀스캔을 하고있지 뭐에요! 2. limit 로 잘라서 subquery 로 뽑아오는 필드가 있는데 아니 미친 subquery 로 뽑고나서 limit로 짜르지 뭡니까 ㅎㅎ

11	비공개 손님 … 2015-04-01 14:25:13
	역시 범인은 n*n 연산

12	비공개 손님 … 2015-04-01 14:27:36
	그럼에도 불구하고 양에차지 않ㅅ브니다... 더 빨라져야해...

13	비공개 손님 … 2015-04-01 14:46:12
	인덱스는 제대로 돼있나요? 애초에 리밋걸어서 짜르는게 양이 많으면 노답

14	비공개 손님 … 2015-04-01 14:47:45
	인덱스는 잘 타고 있습니다 다만 정수형으로 들어갈 데이터를 문자열로 넣은게 좀 뼈아프네요 이거 언제고치지 ㅎㅎㅎ 수집단까지 다 건들여야하나

15	비공개 손님 … 2015-04-01 14:57:58
	인덱싱이나 FK로 쓸거아니면 14정도의 오버헤드는 무시해도 되여...

16	비공개 손님 … 2015-04-01 15:12:28
	답15 pk 입니다(눈물)

17	비공개 손님 … 2015-04-01 16:12:41
	혹시 많은 양의 레코드를 정렬하고 있지는 않은가요?

18	비공개 손님 … 2015-04-01 16:27:34
	답17 정렬하는 부분이 있긴한데 모든 케이스를 측정해보진 않았지만 기껏해야 수백라인 정렬하는거라 큰 로드는 없어보이네요

19	비공개 손님 … 2015-04-01 16:28:38
	일단 최초 조회 기준으로 맥시멈 10초, 평균 2-3정도로 했는데 남은건... 저... 저....

20	비공개 손님 … 2015-04-01 16:28:55
	mssql ㄴ은 각 부분별로 시간 얼마나 걸리는지도 뽑아주던데

21	비공개 손님 … 2015-04-02 13:03:21
	explain plan이랑 인덱스 함 보여주시져

22	비공개 손님 … 2015-05-14 01:19:12
	첫번째 쿼리가 오래걸리고 두번째 쿼리가 짧은거는 오라클의 경우 잠깐 메모리에 한번 담궈놓고 다시 호출하면 메모리에서 읽어와서 빠르다고합니다. SQL DEVELOPER경우(F6) 누르면 나오는데 사용량 나오는데 달라질거에요