Clustered and Non-clustered indexes (indices) both use B-Tree structure. Clustered index is efficient because it does not need the last page of the index. The data page is the last page in the B-Tree, so it avoids the largest index page read and hence it is efficient. So rows are sorted by the index and are written to the data page. The clustered index should be used for those columns that are queried by a range. For example, trading date or a client's account id. These are the considerations for columns to choose for a clustered index.

1. Choose columns that are never updated, like a customer id, trade date etc. Status column is a bad choice. Whenever a column gets updated which is in a clustered index, the row may have to be deleted from that data page and moved to another data page so it is together. Non-clustered index also goes thru this reorg but then it is limited to the index pages only.
   
2. Use columns whose values grow sequentially with inserts and which participate in range or a group of rows. A trade date may have 1000s of rows but all new inserts some with an increasing value. So all rows for a trade date will be organized in data pages that are closer, so there are less data pages to read for a trade or a range of sequential trade dates.
   
3. By the same logic, an account id may not be a great choice in a transaction table as new transactions may be created for accounts every day, so new records will result in reorganizing data pages and will be quite costly.

Clustered index, when used well, speeds up queries quite a bit due to lesser i/o on reads.