For the recorded statistics, should I use database redundancy fields for Real-Time query or other methods?

As the question. Statistics fields are usually displayed and updated frequently. How can we efficiently process this type of data? For example, the number of answers to SF questions, collection, and voting statistics. Please provide a good solution. Thank you! As the question. Statistics fields are usually displayed and updated frequently. How can we efficiently process this type of data?
For example, the number of answers to SF questions, collection, and voting statistics. Please provide a good solution. Thank you!

Reply content:

As the question. Statistics fields are usually displayed and updated frequently. How can we efficiently process this type of data?
For example, the number of answers to SF questions, collection, and voting statistics. Please provide a good solution. Thank you!

This is what I do. I split the table vertically first, and then write the data in a delayed manner as needed.

For this type of frequently read/write data:
1. If the request volume is not very high, you can consider maintaining an InnoDB Engine table and storing statistical data separately. Real-Time query and update can basically meet the requirements;
2. if the request volume is very high, consider storing the data in memory-type databases (such as Memcache and Redis). If the data needs to be stored permanently (the memory-type databases are more or less prone to data loss) add another scheduled task to regularly write data to the database. In case of data loss in the memory, you can read the data from the database again.