I'm seeing some very odd queries when I enable triggers that use the nodata() function. They are appearing when the zabbix_server needs to retrieve values from the database for the value cache. Here are some example log entries:

2185:20140304:084900.602 In zbx_vc_get_value_range() itemid:76102 value_type:3 seconds:0 count:1 timestamp:1393951740
2185:20140304:084900.602 query [txnlev:0] [select clock,ns,value from history_uint where itemid=76102 and clock<=1393951740 and clock>1393948140 order by clock desc,ns desc]
2185:20140304:084900.602 query [txnlev:0] [select clock,ns,value from history_uint where itemid=76102 and clock<=1393948140 and clock>1393861740 order by clock desc,ns desc]
2185:20140304:084900.603 query [txnlev:0] [select clock,ns,value from history_uint where itemid=76102 and clock<=1393861740 and clock>1393256940 order by clock desc,ns desc]
2185:20140304:084900.603 query [txnlev:0] [select clock,ns,value from history_uint where itemid=76102 and clock<=1393256940 and clock>1390664940 order by clock desc,ns desc]
2185:20140304:084900.603 query [txnlev:0] [select clock,ns,value from history_uint where itemid=76102 and clock<=1390664940 order by clock desc,ns desc]
2185:20140304:084900.604 End of zbx_vc_get_value_range():SUCCEED count:0 cached:1

The item in question is the agent.ping item. It has a single trigger defined as:
{hostname:agent.ping.nodata({$LINUX.ZBX.AGENT.TIMEOUT})}=1. The "{$LINUX.ZBX.AGENT.TIMEOUT}" macro is set to "1h".

The problem with these queries is three-fold:
1. For one trigger that needs one set of values, why are there five separate queries that ran?
2. Why is there an "order by clock desc, ns desc" statement on these? That only slows things down. Maybe it's required for the value cache, but it seems strange to me.
3. My nodata() function is set to only need one hour worth of data. Why are some of the queries trying to look for data FAR older than that? Take a look at the fourth query down. It's looking at data from Jan 25 all the way to Feb 24!

Now the really strange thing about this is that this problem does not happen for every host that has this exact same trigger. I have been able to replicate this in both my production and staging Zabbix environments.