as per above indication index were used insert and update operation, but not SELECT statement, can i consider that unused index?

One more question. Index may be performance degrade of transaction and cause of Lock Waits/sec > 0 and Lock Wait Time (ms) > 0 those counter non zero values over the time period, it might be blocking issues on database.

I am going to capture the blocking text and duration at Profiler and choose blocked process event, before start profiler can change the value of blocked process threshold = 10 at instance leve, what will be impact after chage the value 10? default value 0.

Based on that query you aren't looking at range_scan_count or singleton_lookup_count so it looks like you don't know if this index is used by selects. I prefer to look at sys.dm_db_index_usage_stats. I wouldn't consider dropping the index on the basis of the current information that you have provided.

I wouldn't recommend running profiler against a production server as it has a negative performance impact. You can define the trace using profiler, script it, and run it as a server-side trace, which has a much lower impact on the server.

To aid what Jack has already said, use the DMV to get a better idea of whether or not the index is actually used...and remmber to keep in mind that these statistics are kept as a running total of since the last time the SQL service was restarted. So if you recently restarted your server, your results may be skewed and you might want to wait a longer period of time before making any decisions to drop an index.A script I like to use (and I believe it came from SSC) is:

I checked unused index, As per that script result return value only two column in NONCLUSTERED

total 4 NONCLUSTERED index values as below and Remaining all the column values are 0 (Zero),

user_updates = 36361 - it is used for UPDATE SQL statement, so this is not unused index.system_scans = 12

total 23 UNIQUE CLUSTERED index values apperad in system_scans column and Remaining all the column values are 0 (Zero), so will it be unused index?

The user_updates column means the number of times a user action caused a modification of the index, not how many times the index was used to satisfy an update query. If there are more user updates by a significant amount than there are user seeks then the resources used to maintain the index structure may be greater than the benefit the index provides. Glenn Berry, Jason State, and Kendra Little all have scripts on their blogs that do a pretty good job of identifying indexes that may be candidates for dropping or modification.

Furthermore, check out Brent Ozar's sp_BlitzIndex (as Jack mentioned) - it does a good job of isolating potential indexes that are not used, and/or ones that are potentially duplicated: http://www.brentozar.com/blitzindex/

______________________________________________________________________________"Never argue with an idiot; They'll drag you down to their level and beat you with experience"

We would need to see the queries that are causing it. Could be UPDATE statements seeing that there's frequent rowlocks but just shooting in the dark here and haven't yet finished my first cup of coffee.

______________________________________________________________________________"Never argue with an idiot; They'll drag you down to their level and beat you with experience"