Three things should never be put in the mysql database _ MySQL

Three things should never be put in the mysql database Images, files, and binary data are never stored in the mysql database..

Many people think that since the database supports BLOB-type data, there must be no error in inserting files into the BLOB field !? Wrong, not like this! In many database languages, it is not easy to process large fields.
There are many problems with storing files in the database:

1. the read/write speed of the database will never catch up with the processing speed of the file system.
2. database backup has become huge and time-consuming.
3. access to files must go through your application layer and database layer.
The last two are real killers.
So store the thumbnail in the database? As a result, you cannot use nginx or other types of lightweight servers to process them.
Make it easy for yourself. simply store the relative path of your files on the disk in the database, or use services such as S3 or CDN.

Do not put short-lived data in the mysql database

Usage statistics, measurement data, GPS positioning data, session data, and any data that is useful or frequently changed for you in a short period of time. If you find that you are using a scheduled task to delete data that is valid for only one hour, one day, or several weeks from a table, it means you have not found the correct method for doing things. Using redis, statsd/graphite, and Riak is a more suitable tool for doing this. This suggestion also applies to the collection of short-lived data.
Of course, it is also feasible to plant potatoes in the back garden with excavators, but instead of taking out a shovel from the storage room, you reserve a excavator and wait for it to rush to your garden to dig holes, this is obviously slower. You need to select a proper tool to handle the tasks at hand.

Do not store log files in the mysql database

Storing log data in a database seems to be good on the surface, and "I may need to perform complex queries on this data in the future" is quite impressive. This is not a very bad practice, but it is very bad if you store the log data and your product data in a database.
Maybe your logging is quite conservative, and only one log is generated for each web request. For every event on the entire website, this will still produce a large number of database insertion operations, competing for the database resources required by your users. If your log level is set to verbose or debug, check that your database is on fire.
You should use some plain text files such as Splunk logugly to store your log data. It may be inconvenient to view them in this way, but there are not many such cases. sometimes you need to write some code to analyze the answer you want, but it is worth it in general.