Change server collation to `utf8_unicode_ci` in Google Cloud SQL

Assuming the Linux/Apache/PHP part of your stack runs on a local server and you are somewhere in the same hemisphere as your cloud database server...

But first, let's recap what is at play:

1. Your PHP program sends the query to the database for execution.
2. The database parses the query.
3. The database executes the query and locate which rows to return.
4. The database reads the rows from storage (disk) and returns them.
5. The rows are transmitted to the PHP program.
6. The PHP program processes the rows.

Let's assume that Google Cloud SQL is as efficient at doing 2, 3 and 4 as running MySQL on your hardware. There could be a difference particularly in step 4 if the Cloud SQL server is provisioned against slow storage but I don't know so we will ignore this factor for now.

So the factors to analyze are 1 (sending the query to the database) and 5 (sending the rows from the database to the PHP server).

When you run the database on the same box as your Apache/PHP server, there is virtually no delays in sending the query. The transmission of the rows from the database to the PHP program occurs over a Linux socket on the same host, so again, the speed is near instantaneous.

When you move your database on a different server than your Apache/PHP server, but within the same data center, you have 1) some networking delays for the query to get to the database (a negligible delay as the size is very small), and 5) the time it takes to transmit the results back to PHP. Depending how many rows are being returned, step 5 can take much longer than if the database was on the same host. However, this "much longer" is relative - it is really negligible in a normal data center with Gbps networking or better between servers.

Now, let's move the database server to Google Cloud. What's your connection to the Internet? Let's assume a high quality, low latency 100Mbps fiber optic connection to an ISP.

The latency of the network between your PHP server and the database just went from <1ms to >30ms - that's a 30x increase in latency. In practice, you'll see more than 30x increase because you're transmitting a lot more information - particularly at step 5 of returning the data from the database to the server.

The chart Latency Numbers Every Programmer Should Know, seen in many sites, articles and books, gives you good stable points to think with. Some places you can find it, in various forms.

• Book: The practice of Cloud system Administration by Thomas Limoncelli, Strata Chalup, Christina Hogan
• https://dzone.com/articles/every-programmer-should-know
• http://highscalability.com/numbers-everyone-should-know
• https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html

Is there a solution? Without knowing more what you are trying to do, solve and produce, I would say the solution is simply to move the compute (PHP) to Google Cloud Platform, where it will be close to the database.

There is no such thing, a Google Cloud SQL instance being part of the same VPC/Subnet as a Compute Engine instance isn't possible. Cloud SQL is a managed service, which means that Google owns the instance and the network it's connected to. As such it cannot be in one of your project's networks.

Also, Adding an address to the authorized network in Cloud SQL will only work for Public IP connectivity, Private IP is a different story.

In fact as explained here, if you need private connectivity, Cloud SQL will create a network peering between the SQL instance and the Compute Engine network(VPC) of your choice. This means that only the instances in that specific network will be able to reach Cloud SQL.

I would suggest going to the Cloud-SQL details page under 'Connections' tab, and check in-there which network you have associated (Right below 'Associated networking'). Then you just need to make sure that your client machine is part of that particular network(VPC). Also important your client subnet needs to be on the same region as your Cloud SQL instance.