node_access_rebuild batch process needlessly uses DISTINCT and may encounter infinite loop

I have not been able to get to the root cause of this, but I have a database that returns some unusual results for very simple queries:

SELECT COUNT(nid) FROM node; 
# returns 21019

SELECT COUNT(DISTINCT nid) FROM node; 
# returns 0

explain SELECT COUNT(DISTINCT nid) FROM node; 
# returns 1	SIMPLE	node	index	NULL	node_changed	4	NULL	20276	Using index

SELECT COUNT( vid) FROM node; 
# returns 21019

SELECT COUNT(DISTINCT vid) FROM node; 
# returns 21019

SELECT DISTINCT nid  FROM node; 
#  returns a list of 21019 nids (starting at 10000)

SELECT COUNT( nid), COUNT( vid) FROM node; 
# returns 21019	21019

SELECT COUNT(DISTINCT nid), COUNT(vid) FROM node; 
# returns 0	21019

SELECT COUNT(DISTINCT vid) FROM node; 
# returns 21019

SELECT COUNT(DISTINCT nid), COUNT(DISTINCT vid) FROM node; 
# returns 0	0

The query SELECT COUNT(DISTINCT nid) FROM node; is of particular interest, because it is used in _node_access_rebuild_batch_operation(), which is the batch operation for rebuilding node access permissions. Since this query may return 0 here, and the batch process uses this for the max value, the batch gets stuck in an infinite loop because it tries to compute the completion percentage, but it's dividing by zero instead.

Since nid is the primary key in the node table , it should already be unique, so why does DISTINCT need to be used here at all? I suggest removing it. Otherwise the workaround is to use hook_batch_alter() to replace the _node_access_rebuild_batch_operation() with your own re-implementation with a corrected query. Patch fixing the query to follow.

I have not been able to replicate this in a fresh install. The database I'm working with is from a site that's been around for a while, which previously migrated from D6 by another team of developers who I don't know. So I don't rule out any oddities in database quality, but I haven't encountered any issues in collation etc., This operation has been completely re-written in D8, so presumably it's not an issue there, but I have not tested it.

Misc details:

• Drupal 7.39
• PHP 5.4.45
• MySQL Server version: 5.5.45-37.4-log Percona Server (GPL), Release 37.4, Revision 042e02b