NON-CLUSTERED 를 잘 모르겠습니다

1.
그건 아니구요.
단어에 따라 [물리적으로 저장되는 위치]가 정해진다는 비유이지,
정말 영한 사전처럼 순차적으로 이어서 저장되진 않습니다.
실제로는 트리 계열 (B-Tree) 알고리즘을 이용해서 저장될 위치가 결정되는데
이는 DB 제품마다 조금씩 다를 수 있습니다.

2.
보통 닉네임을 정할때 중복없이 생성하게 되는데 이걸 색인으로 만들면 특정 이름을 찾는데에 모든 플레이어들의 이름을 다 비교하는게 아닌가요? 

-> 그렇지 않습니다. 오히려 반대로 이해하고 계시네요.

CASE1 : accountName에 색인이 없을 경우
- 특정 이름을 찾고 싶어도 데이터들이 accountName을 기준으로 정렬되어 있지 않으니
모든 데이터의 플레이어 이름을 다 비교해야 함. (데이터 1억개라면 1억번 비교 GG)

CASE2: accountName에 색인이 있을 경우
- 색인을 보고 빠르게 찾을 수 있음

가령, 어떤 1000페이지 짜리 책에 accumulate이라는 단어가 등장하는지 알고 싶다고 가정해봅시다.
책 뒤에 있는 색인을 보면, accumulate()가 122, 125페이지에 등장하는 것을 알 수 있으니 바로 찾을 수 있겠죠.


아마 위 내용이 잘 이해 안 가시는 가장 큰 이유는
자료구조&알고리즘 쪽의 균형 이진 트리 쪽 지식이 부족해서일 것으로 보입니다.
기회가 되면 AVL이나 Red-Black Tree라거나 
트리 쪽 공부를 해보면 쉽게 와닿을 것 같네요.
간단하게 요약하면, 균형 이진 트리는

왼쪽은 더 작고, 오른쪽으로 가면 더 큰 형태로 데이터가 저장되어 있습니다.
이런 트리 구조를 accountName에도 응용한다면,
사전 순서상 작은 단어는 왼쪽, 더 크면 오른쪽에 배치하는 형태로
logN 시간 복잡도에 빠르게 서칭할 수 있는 구조를 만들 수가 있습니다.

아니면 색인을 넣어줘야지 위처럼 찾는 기능이 가능한건가요?

찾는 기능 자체는 INDEX 여부와 무관하게 항상 사용 가능합니다.
단 성능 자체가 어마무시하게 차이가 나게 됩니다.
INDEX가 걸려있지 않다면, 데이터가 1억개일 경우 1억개를 다 서칭할 것이고
INDEX가 적절하게 걸려 있다면, 100회 미만의 서칭 개수로 데이터를 찾을 수 있게 됩니다.