I can clarify a bit: in the period, for example, 2018-11-27 10:15 – 10:45 the "Latest data" screen displayed the wrong value "-1". The right value during this time was "0", but due to absense of ordering by NS field in SELECT and equality of the values in the CLOCK field the displayed result was incorrect.

I think there is ORDER BY h.clock and not ORDER BY h.clock,h.ns because of performance concerns. And in turn performance concerns are because of the fact that all history* tables are indexed by itemid,clock and not itemid,clock,ns. Index can be changed in theory but in practice the upgrade procedure will take eons on setups with terabytes of historical data. Therefore it will be a Won't Fix, I'm afraid.

See ZBX-4840, ZBX-8719.

Yes, adding sorting for not indexed column is not a solution. That was just an example.

Maybe some simple "sorting" by NS could be added in PHP code. But I'm not sure it would really resolve the issue if 3 or more values are received in the same second.

cyclone, thank you for a comment. I've read both mentioned ZBX's. However, the situation is still not clear for me.
I see the following:

• ZBX-4840 (dated by April 2012) tells that the new index by (itemid,clock,ns) is very useful for requests like

  select value from history where itemid=24847 and clock<1333520700 order by itemid,clock desc,ns desc limit 1
  

• I don't know why and in what exactly moment this index has been removed back, but it seems that it has been done.
• ZBX-8731 (dated by September 2014) tells, in fact, the same (but for the neighbouring table – history_uint instead of the just history). This ZBX had offered the same solution (creating index by the (itemid, clock, ns) fields), but was closed as duplicate of ZBX-8719.
• ZBX-8719 complains that requests like

  select clock,ns,value from history_uint where itemid=786846 and clock<=1406552958 order by clock desc,ns desc limit 2
  

  are slower then requests like

  select clock,ns,value from history_uint where itemid=786846 and clock<=1406552958 order by clock desc limit 2
  

  It is logical if there is no the appropriate indexes.
  Unfortunately, I could not see any other details in this ZBX: discussions, explanations, solutions, etc.
  However, it seems that instead of creating the needed index the decision was taken just to remove the ordering by NS field.

• Currently we have a real problem: the "Latest data" sometimes displays the wrong info (data is not the latest). My colleague spent a lot of time investigating non-existent problem because he had trusted this Zabbix page.

Fixed in development branches:

• 3.0: svn://svn.zabbix.com/branches/dev/ZBX-15220
• 4.0: svn://svn.zabbix.com/branches/dev/ZBX-15220-4.0

Fixed in:

• 3.0.25rc1 r88867
• 4.0.4rc1 r88868
• 4.2.0alpha3 (trunk) r88869