Best way to design this mileage table?
Computed columns are your friend.  Use them to capture simple calculations you're going to do anyway, and to guarantee that the computed values are correct.  
Persist the results if you want to index or filter on them; don't persist them if you just need to pull the value once in a while.
Capture all data constraints using CHECK constraints.


Here is a pseudo-schema definition:

  id               PRIMARY KEY
, truck_num

, start_date
, end_date         CHECK (end_date &gt; start_date)

, start_miles      CHECK (start_miles &gt;= 0)
, end_miles        CHECK (end_miles &gt; start_miles)

                   -- what if they refill the tank?
, start_gals       CHECK (start_gals &gt;= 0)
, end_gals         CHECK (end_gals &lt; start_gals AND end_gals &gt;= 0)

-- all these should be computed
, miles = end_miles - start_miles
, gals = start_gals - end_gals
, mpg = miles/gals


As for indexing the table, here's what I think:


Cluster on start_date ASC. This will satisfy your WHERE clause. You are always inserting data by increasing start_date, meaning your writes will always be sequential under this clustering scheme.  You are also always querying by start_date so you satisfy your biggest query pattern as well. (3,000 inserts per week is nothing. Because you have such a low volume of inserts, you could even cluster on start_date ASC, end_date ASC.)
Create a non-clustered index on truck_num and INCLUDE mpg. This should satisfy your SELECT, JOIN, and GROUP BY clauses. If you want to ORDER BY mpg, then make mpg part of the index key after truck_num instead of just INCLUDE-ing it.


When you're done, test your setup as follows:


Create a test table
Pump it full of test data
Create the indexes
Update statistics
Run your most common queries
Check their plans and run times