With site-to-site tunnels, there are generally 2 ACLs on each side of the tunnel: 1 ACL allows the traffic to enter the firewall itself, then the other ACL defines which traffic is to be sent over the tunnel (generally called "interesting traffic"). You would need both ACLs to account for your traffic flow. The first, to authorize the server to talk with its partner, and the other to tell it that the traffic is part of a tunnel, so it knows how to reach the destination.
Edit (examples of the ACLs on each side of the tunnel):
Firewall 1:
access-list from-inside extended permit tcp host xxx.xxx.xxx.xxx host yyy.yyy.yyy.yyy eq 3306
access-list site-to-site-acl extended permit ip host xxx.xxx.xxx.xxx host yyy.yyy.yyy.yyy
Firewall 2:
access-list from-inside extended permit tcp host yyy.yyy.yyy.yyy eq 3306 host xxx.xxx.xxx.xxx
access-list site-to-site-acl extended permit ip host yyy.yyy.yyy.yyy host xxx.xxx.xxx.xxx
So, the from-inside ACL is allowing the traffic into the firewall (with those source and destinations inverted on either side), and the site-to-site-acl accounts for the traffic to be sent over the tunnel on each side (with the source and destinations inverted on either side). The only difference in what I wrote is that one is limiting the protocol to TCP and the port to 3306, while the other is allowing "ip", meaning it allows all protocols and all ports). The reason for that is, each time you need to allow something else over the tunnel, you don't have to change the crypto-map ACL (which would require bouncing/rebooting the tunnel - you can just add an entry on the from-inside ACL to allow the traffic in, and leave the site-to-site-acl alone.
For the record, this is only valid for policy-based site-to-site tunnels. Route-based tunnels do not use crypto maps or the associated "interesting traffic" ACL.