Schema design for user activity logging
One of the assumptions that I would ask you to reconsider is whether you really want to have different tables for each event type, or if rather these event types are rows in a table instead of distinct tables.

If you had an EVENT_TYPE table containing your list of event types (about 100 of these) you could take the columns from your current various event tables and make them rows in an EVENT_PARAMETER table.  

This type of design would turn your schema changes into data changes when you add new event types.  That would save you code maintenance issues and also avoid making your queries more complex and potentially slower.

The instances of events would similarly be kept in two tables, for example a LOG table and a LOG_DETAIL table.

LOG would be an intersection between user and event type.

LOG_DETAIL would be an intersection between log and event parameter.

Your data model might look something like this:

Note that one objection some people may have to this approach is that you end up saving the log parameter values in a string format, rather than in a native format.  This is clearly a trade-off.  You have to ask yourself is it a good trade-off for your situation.