The combination of "PRIMARY KEY(id)" above and  "GROUP BY id" here locks you into a single unrealistic worst case scenario where every row gets its own group and every group trivially has a count of 1.

One possible alternative Is to add a group_id column to the base table and use that in the view's GROUP BY.
This would make a more realistic scenario and enable a client command line parameter to control the total number of groups separately from the total number of rows -- by limiting the range of the group_id values.
Using a very large range would simulate the current scenario of 1-element groups.
Using a narrow range (like 0-9) would allow us to benchmark the best-case scenarios of very large groups.

Another simple adjustment to the client -- again using the SAME ddl -- could use a different pseudo-random distribution of group_ids in the same small range to test groups of uneven sizes.

This kind of flexibility using an unchanged DDL can be very informative.