당연히 그 경우 결합 인덱스를 주는게 좋습니다.

결합 인덱스를 쓰면 미리 target, no 필드를 기준으로 정렬되기 때문에 order by 시에도 data page를 읽을 필요없이 index 참조만으로 해결되므로 filesort 가 불필요해지므로 속도에 영향을 많이 줍니다. firesort를 별도로 정렬를 위해 불필요한 작업을 했다는 의미니까요.

그리고 500건 정도는 색인이 있으나 없으나 차이가 없습니다. 오히려 데이타 건수가 작을 때 색인을 쓰면 더 느려집니다.

그 이유는 table data file 에서 읽어 올때 I/O단위가 페이지라는 단위로 일종의 묶음 단위로 읽어오기 때문에 그렇습니다.

그렇게 작은 데이타 건수는 1-2번의 I/O만으로 다 읽어오기 때문에 색인이 있으나 없으나 큰 차이가 없습니다.

색인을 쓸 경우 더 느려지는 경우에 대해서 부연 설명을 하면

색인은 정렬되어 구성되지만 데이타 페이지는 디스크 상에 랜덤하게 저장되어 있을 수 있습니다.

일단 색인에서 데이타페이지의 주소를 참조하고 실재 데이타는 그 주소값으로 데이타파일에서 읽어오게 됩니다.

따라서 색인 검색 range 가 넓어지는 필드에 대한 검색 이를 테면 성별같은 경우는 엄청난 랜덤 엑세스가 일어나므로 색인을 쓰면 더 효율이 좋지가 않습니다.

예를 들어서 책의 색인 페이지를 참조하여 "~은", "~는", "~이", "~가" 같은 경우를 찾는다고 칩시다. (그런 어리석은 경우는 없겠지만...)

아마 색인보고 실재 페이지 찾아서 데이타 읽고 왔다갔다하면서 보느라 정신이 없을겁니다. 차라리 처음부터 순차적으로 페이지 뒤지면서 찾는게 훨씬 빠를겁니다.

그리고 앞에서 설명드렸듯이... DB는 일정 묶음 단위로 (책으로 치면 한꺼번에 10페이지 단위로...) 읽어온다는 것도 기억해주세요.

예를 들어 책이 100페이지 짜리고 1번에 10페이지 단위로 읽어온다면 10번 엑세스해서 모든 페이지를 다 읽어올 수가 있습니다.

만약 색인을 써서 엑세스하는게 이 비용을 상회(10번 보다 더 많이 )한다면 당연히 색인을 쓰지 않는게 더 효율이 좋습니다.

더 헷갈리게 해드린건 아닌지 모르겠네요.

제가 설명은 잼병이라....

즐거운 하루되세요.