Database design for bigger tracking table
Honestly, 912 million records may seem daunting but it's nothing that regular indexing won't be able to handle, especially since your main query is to return only the current day's prayer types for the current user which is a very small amount of data. I've managed Tables with 10s of billions of rows in them and proper indexing allowed us to return small sets of data in milliseconds runtime, on very modest hardware. And I'm sure Tables in the 100s of billions would've been fine as well. Note this was using SQL Server instead of MySQL but the principals are the same on how indexing works in regards to storing and fetching data.
At your current rate (no user growth) for example, you wouldn't hit 100 billion rows for about 100 years. If you're able to implement Akina's suggestion then you'll be able to cut the amount of data down by 80% too. So that 100 billion rows now becomes only 20 billion in 100 years. (In other words, it withstands the test of time. :) If you're able to archive data after X number of years you can also alleviate the data load of your Table.
Finally in regards to indexing I think to support a query that will select all prayer type records for a given user only on a given day, you should create the index on user_id, date (and depending on which MySQL engine you're using include type_id if it's not by default) for best indexing.