Three things should never be put in the Mysql database _mysql

picture, file, binary data never put in MySQL database。

Many people feel that since the database supports BLOB-type data, it's definitely not wrong to cram files into a BLOB field!? Wrong, not like this! Otherwise, in many database languages, it is not easy to deal with large segments.
There are many questions about storing files in a database:

1. The speed of reading/writing to the database will never catch up with the speed of file system processing.
2. Database backup becomes huge and more time-consuming
3. Access to files needs to traverse your application and database tiers
The latter two are the real killers.
So thumbnail survival to the database? As a result, you cannot use Nginx or other types of lightweight servers to handle them.
Make it easy for yourself to simply store a relative path to your files on a disk in a database, or use a service such as a S3 or CDN.

Short life data not to be placed in MySQL database

Use statistical data, measurement data, GPS positioning data, session data, any data that is useful to you in a short time, or that is constantly changing. If you find yourself using timed tasks to delete data from a table that is valid for only one hour, day, or weeks, you are not looking for the right way to do things. Using Redis,statsd/graphite, Riak, they are all more appropriate tools for doing this kind of thing. This recommendation also applies to data collected for those short life periods.
Of course, it's also possible to plant potatoes in the back garden with an excavator, but it's much slower than taking a shovel out of a storage room, booking an excavator, and digging a hole in your garden. You have to choose the right tools to handle the things at hand.

Log files should not be placed in the MySQL database

Keeping the log data in the database looks good on the surface, and "Maybe I'll need to make complex inquiries about the data in the future." This is not a particularly bad practice, but if you store the log data and your product data in a database, it's very bad.
Maybe your log records are very conservative, and each Web request produces only one log. For every event in the entire site, this still produces a lot of database inserts, competing for the database resources your users need. If your log level is set to verbose or debug, wait and see if your database is on fire.
You should use some such as Splunk loggly or plain text files to store your log data. It may be inconvenient to look at them like this, but it's not much, and sometimes you need to write some code to analyze the answers you want, but it's worth it in general.