Add indexed queries to MySqlEventStore

[marcuswinkler]

We recently noticed that the MySql event store does not actually use the index when loading events for an aggregate.

This PR copies the implementation from the Maria DB event store. Note that it does so only for the single stream strategy, as this is what we use.

We have been running this in production for several weeks now (patched on top of 1.10.5).

[codeliner]

Thx for the PR @marcuswinkler

Can you elaborate more on the problem? In 2017 @prolic and @ogg did a lot of testing to figure the best index for MySql. It is documented here: #43 (comment) along with test scripts etc.

What MySql version are you using and can you provide some EXPLAIN results, that show that the index is not used. Also please share your event store configuration that you used for testing, before patching the strategy.

The other issue is, that I don't think we can merge the PR as-is. This would have a huge impact on existing installations and would break existing streams.

So let us first figure out your exact problem and then discuss a solution. We did a similar thing yesterday for MySql having problems with projections: #224

[marcuswinkler]

Well that's a bit embarrassing.

Trying to prove with EXPLAIN that this PR is necessary, I now find that the correct index is used in master after all.

My assumption that MySql would not use the index for generated columns unless the generated column was directly referenced in the query was incorrect. Therefore it is also not required to translate the column names as in the Maria DB event store.

(See also https://dev.mysql.com/doc/refman/5.7/en/generated-column-index-optimizations.html)

A few weeks ago, cpu usage on our database instance was shooting up to 100%. Looking at the queries in the process list, I found that many of the following took minutes to complete:

SELECT * FROM `events` USE INDEX(ix_query_aggregate, PRIMARY)
WHERE JSON_UNQUOTE(metadata->"$._aggregate_type") = 'email_identity'  AND JSON_UNQUOTE(metadata->"$._aggregate_id") = '7678e75f-85a9-4c97-b5c7-c12575f3634c'  AND `no` >= 1;

When I examined those with EXPLAIN they were not using an index. Running it right now on the same database they do use the index:

+----+-------------+--------+------------+-------+----------------------------+--------------------+---------+------+------+----------+-----------------------+
| id | select_type | table  | partitions | type  | possible_keys              | key                | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+--------+------------+-------+----------------------------+--------------------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | events | NULL       | range | PRIMARY,ix_query_aggregate | ix_query_aggregate | 754     | NULL | 36 |   100.00 | Using index condition |

However, the changes in this PR did immediately fixed our cpu usage issues at the time. I have no explanation for that.

Database: MySql 5.7.17 on an AWS t2.small instance
Using a MySqlSingleStreamStrategy with ~ 5 million events, ca. 4.3 GB in the events table
Typical cpu usage < 10 %

[codeliner]

Good to know. Thx for the feedback. Any other result would have been strange, because pdo-event-store is available since 3 years and downloaded ~400 times a day, meaning many teams are using it in production. We also ran a lot of benchmarks and never noticed the lack of a missing or wrongly configured index. But you never know ;)
One thing I could imagine is that you somehow used the SimpleStreamStrategy instead of the SingleStreamStrategy.