Question: ```
Use ANALYTICS

Go

SELECT NWPFFS AS HUB,
       LCRGN AS REG,
       LCDST AS DIST,
       ILLCN AS LOC,
       LCNAM AS [LOC NAME],
       LXLTYP AS LOCTYPE, 
       IXPBSN AS B, 
       IXPGRP AS G, 
       IXPDPT AS D,
       ITITMN AS ITEM,
       ITMFGN AS MFG#,
       ITDSC1 AS DESC1,
       ITDSC2 AS DESC2, 
       ITINVM AS [STK CD], 
       ITVND AS VEND#,
       ITHGT AS VENDOR,
       ILOHNQ AS [ON HAND],
       ILCMTP AS COMPURCH,
       ILCMTC AS COMSALE,
       ILYSLQ AS [SLS YTD QTY],
       ILLYSQ AS [SLS LY QTY], 
       ILINVV AS [INV VAL]
  FROM (dbo.Item_Location_Master 
 INNER JOIN dbo.Item_Master 
    ON ILITMN=ITITMN)
 INNER JOIN dbo.Location_Master 
    ON ILLCN = LCLCN
 WHERE ((LXLTYP='R') OR (LXLTYP='T'))
   AND ((ITBOMT <> 'T') AND (ITBOMT <> 'S')) 
   AND ((ILOHNQ<>0) OR (ILCMTP<>0)) 
   AND (IXPBSN <> 9) 
   AND ((ILITMN<>21542) OR (ILITMN<>21750))
   AND (NWPFFS<>9900)

```

Answer: 
The best you could do is provide indexes on LXLTYP and some of your other fields.
How about giving us more information like your table's current indexes, etc? Those column names are really confusing.

Here's a good article on indexes on SQLTeam.com: <http://www.sqlteam.com/article/sql-server-indexes-the-basics>
Without seeing the query plan or indexes on the tables, I can't really do any sort of concrete diagnosis. However, here are a few suggestions: 

* Examine the query plan to see what operations are taking the time. If the plan is wrong, there will probably be one operation taking 99% of the time.
* Convert the ORs into [s-argable](http://sqlblog.com/blogs/ben_miller/archive/2008/08/29/what-is-a-sarg-exactly-training-classes-and-knowledge-retention.aspx) clauses. See if this changes the query plan.
* Put indexes on the columns used in the joins. See if this changes the query plan.
* Check that the statistics on the tables are up to date. Although this shouldn't really happen on SQL Server, if the statistics get out of date then the optimiser can choose a sub-optimal plan.