경험상 인덱스란거는  "만들어야 한다."   "만들지 말아야한다. "  , "써야한다 "  ,"쓰지말아야한다"    이런 절대적인 기준보다는  "상황에 따라 다르다" 가 더 적합한듯 합니다.  특별한 설정없이 인덱스를 만들면 null 도 인덱스에 포함되고 정렬됩니다. 잘만 활용하면 검색뿐 아니라정렬에 대한 부하도 줄여줄수 있지요.

null 이 많다고 하셨는데, 많다는 기준이 10% 내외를 말씀하신건지  90%이상인건지,,,,,,검색시 null을 제외할건지등이 명확치가 않네요.null이 대부분을 차지하고 검색시 대량의 데이터를 뽑는게 아니라면  인덱스를 만드는게 유리하겠지요 . SQL2008 이시면 필터를 걸어서 인덱스 크기를 최소하할수도 있구요.

null 의 비율이 가령 50%정도로 애매하게 분포하고 있어도. 조회화면에서  인덱스커버시킬수있다면 인덱스를 만들어 랜덤억세스와

소트의 부하를 없앨수 있습니다.

또한 쪽지에 대한 조회화면이 한두개뿐이고 그 화면이 모두 님이 말씀하신대로 읽은날짜기준으로  조회와 정렬이 되야한다면, 아예 클러스터인덱스의 첫번째 키로 넣을수도 있을듯합니다.   다만 이방법은 경우의 수를 얘기한것이지 추천하는건 아닙니다. 클러스터인덱스가 수정되는 컬럼이 되는건 좋지 않거든요.
이런저런경우도 아니라면 차라리 인덱스를 만들지 말고 옵티마이저가  풀스캔을 하든 다른 인덱스를 스캔하든 냅두는게 나을수도 있습니다.    저같으면 넌클러스터 인덱스를 만들되 커버시키는 방법을 먼저 찾아볼듯 합니다.

맨즈밤님 말과 같이 null도 인덱스에 포함이 됩니다.

따라서 null의 분포도를 고려하여 index 정책을 세워 가는 것이 중요할 것으로 보입니다.

다만 null 이 없도록 처리 하는것이 데이터 무결성이나 SARG로서의 연산자 사용이 수월합니다.