Based on your comment about the end goal here:
Incoming cases should be linked to a person account only if the case information that comes in (name and email) exists on one, and one account only
I think there's another way to approach this.
Suppose you have a list of Cases,
List<Case> newCases. Each Case has an
Email and a first and last name. You want to find those Person Accounts corresponding to the Email and Name, but only if they're unique.
First, process the Cases into three
, andSet emails`. Then, query for all potentially responsive Person Accounts:
List<Account> possibleAccounts = [SELECT Id, FirstName, LastName, PersonEmail
WHERE IsPersonAccount = true
AND (FirstName IN :firstNames OR lastName IN :lastNames OR PersonEmail IN :emails)
Then, process this result list too, into a
Map<String, List<Account>> keyedAccounts keyed on a composite key: the concatenation of the First Name, Last Name, and Email, separated by some delimiter like
\n. For example, Mike Jones
<email@example.com> would be stored in the
List<Account> keyed under
Lastly, walk through your Cases one more time, and for each one construct that composite key. Then, you have your answer as to whether it has one and only one corresponding Account:
keyedAccounts.containsKey(compositeKey) && keyedAccounts.get(compositeKey).size() == 1.
This is not invulnerable to pathological cases (what if you have 50,000 guys named Carl, for instance?) but it's a pattern you can tailor somewhat to your org's specific data volume and structure and is likely to be more resilient than your current aggregate approach.