Imagine you have 2 projects: project A and project B.
In option (1), you create a docker environment for project A and a different docker environment for project B. That means that the MySQL database for project A will be in a different container than the MySQL database for project B. I personally prefer this approach, because:
it guarantees you that each project is isolated and can have different dependencies. If you need to update the MySQL version for project A, you can do that easily without the need to update project B as well.
there is no possibility of unwanted interaction between the two projects. Project A can not see Project B data, there are no possibile misconfigurations that results in a wrong interaction between the projects.
On the other hand, it is not trivial to run the 2 projects concurrently if they use separate docker environment: you will need to modify a lot of configurations to make them use separate ports without creating conflicts.
Option (2) is basically the opposite. You create only one container for each service, and the two projects use the same containers. You will have a single MySQL container with 2 different databases, one used by project A and one used by project B.
The main strength of this approach is the ability to run the projects at the same time, with minimal effort.
On the other hand, things get complicated if the projects require a different version of the same dependendcy and a misconfiguration can result in unexpected interactions (e.g. you may wrongly setup the Redis database in one project and the two projects would share the same bucket, with the possibility of overlaps and problems that are very hard to detect and debug)
As a rule of thumb, I would use option (2) in case the two projects are strongly dependent on each other and will be developed together and option (1) in all other situations.