저라면 테이블을 아예 분리해버리기도 합니다. 특정 기준( 일, 월,주 단위 등으로 )

날짜 단위로만 보는 경우에는 가장 좋더군요. 물론 달별 로그 보려면 무식하게 union 해야 하는 문제가 있습니다.

-----------------------------------------------
이제부터는 사견인데요, MySQL 내부 로직은 제가 알 수 없지만, 일반적인 개발자라면 DATETIME을 관리하는데 2가지를 놓고 따지게 됩니다. 이종 플랫폼/OS 간 데이터를 편하게 유지하는 목적으로 DATETIME을 string형태로 저장하기도 하고, 적은 저장공간과 비교의 편의를 위해 time_t 혹은 time64_t 등을 사용해서 저장하기도 합니다.

 time_t 등의 basic type으로 저장한 경우에는 cpu에서 1 cycle만에 비교할 수 있을테고, string들은 strcmp api를 통해서 비교하게 되는데, cpu에서 고속의 비교 명령어를 제공한다고 해도 한번에 32bit나 64bit밖에 비교하지 못합니다. 

따라서, 'YYYY-MM-DD hh:mm:ss'를 char로 비교하게 되면, 최소 길이로 바꾼다고 해도 4+2+2+2+2+2 = 14바이트이고, 32bit환경에서 동시에 4bytes씩 비교한다고 해도, 최소 4회의 cycle이 소요됩니다.

말씀해주신 대로 year-month-day로 분리하고 키를 year-month-day 3컬럼에 대해 멀티플 컬럼 키를 설정한다고 하면 결국 8byte에 대해 strcmp를 수행하게 되는데, 32bit환경에서는 2 cycle에 비교가 완료되게 됩니다. 만약에 MySQL이 time_t에 기반한 DATETIME 컬럼 처리를 하고 있다면 이에 비해서는 char 처리가 다소 느리게 될 듯 싶습니다.

장황하게 적었는데요, MySQL의 내부 구현에 따라 내용이 달라질테니, 저라면 백만건 더미 데이터 넣어두고 양쪽을 비교해볼 것 같습니다. DATETIME에 대한 인덱스냐, char(4)+char(2)+char(2)에 대한 멀티키 인덱스냐로 말이죠.