Simple SELECT taking too long to run
Basically, you have 3 options, using regular indexes (b-trees):

Create a clustered index on DAY_DATE. But chances are that you already have a clustered index on something else, and you cannot, for some reason, change that.

Create a non-clustered index on DAY_DATE. Whether or not this will be used by the optimizer depends on how many rows you return for that condition (2,066,381) compared to number of rows in the table (unknown to us). For each row, SQL Server would need at least one page access to go fetch that page. 

Create a non-clustered index that covers the query with DAY_DATE as the key column and the other columns that you query refers to as included columns. Since you have to do SELECT *, then you would need all columns in that index, making it as big as the data it self (a bit bigger, even). Quite likely not doable.

A columnstore index might help, depending on the compression level you achieve in the end. But, again, that index would need all columns!

Bottom line: Do you really need that many rows and that many columns?