An index holds only what you project
Projection decides which attributes an index carries, trading storage against an extra read.
Why
A secondary index is a copy of your items, and you choose how much of each item it copies. The lean index here projects only the order total; the full index projects everything. Both are keyed on order status.
Query the lean index and each row carries only its keys and total. Query the full index and every attribute is there. The lean index is cheaper to store and cheaper to write, but a read that needs the customer or address has to fetch it from the table, one GetItem per row. Project for the read you actually serve.
KEYS_ONLY and INCLUDE indexes are cheap but make reads fetch the rest; ALL avoids the fetch but roughly doubles the index cost.
Try it. Then change it.
Predict what each request will do. Run it, inspect the response, then change a value in the workbench and try again.
The lean index projects only total. Each row comes back with its keys and total, and nothing else.
The same axis, projected ALL: the same orders, now with every attribute. No table fetch, but a costlier index.
On the lean index, getting the customer or address means a GetItem per row back to the table. Here is one of those reads.
The lean index projects only total. Each row comes back with its keys and total, and nothing else.
Choose an access pattern above, or build your own request. See what comes back and what it costs.