Google Cloud SQL overestimating storage usage and reporting unknown errors

Question

I have a Google Cloud SQL instance that I'm having trouble manipulating.

Originally I had a database uploaded to the instance. I have been trying to drop and replace that database with a new database of the same name. This has since given me a few problems...

1. The database is ~500KB. Cloud SQL reports that I'm using ~50MB of data.
2. The instance contains several other expected databases (performance_schema, information_schema, mysql). I'm unsure if these were accidentally uploaded from my local MySQL instance and if there are subsequent problems from overwriting these databases.
3. I now keep getting client-side errors (caught and reported by Google) in the Cloud SQL console.
4. The operations panel reports unknown errors next to all my attempts to upload the database from a .sql file. No errors reported for attempts from files without an extension.

I have no idea where to begin, so any help is appreciated. Right now, I am worried most about the miscalculation of storage usage, as I don't want to explain unexpected increases in billing.

--

Update:

I created the database in phpMyAdmin and exported it using the export tab. The "~500KB" is the size of the exported file. I originally assumed that all my failed uploads were still being saved, but unaccessible and therefore unremovable.

I'm still skeptical that all three extra databases are necessary, mostly because I found (through a possibly unreliable source) that Cloud SQL does not use performance_schema.

The error messages do not contain any useful information. Client-side errors include (paraphrased) "There was a problem with the console, please refresh the page" or "Google has encountered a client-side error", both in the Cloud SQL page of the developer console. Server-side errors are only found in the Operations section under the "Message" column and just say "an unknown error has occurred".

Answer 1

The size of an MySQL dump is not expected to match the storage use by a running MySQL server that contains the same data because the formats in which the data is stored are widely different.

The Cloud SQL is using MySQL which in turn uses InnoDB as the default storage engine. An empty D0 contains at least the following 3 files:

18874368 ibdata1
16777216 ib_logfile0
16777216 ib_logfile1

That the ~50MB you are seeing. The ib_logfile0 and ib_logfile1 are fixed size files that are used as a circular buffer by InnoDB. The ibdata1 is the main table space and is used for storing the actually data and other auxiliary data (the UNDO log for example). The table spaces are never shrink but the empty space inside is reused.

One more thing: the tables that show in INFORMATION_SCHEMA and PERFORMANCE_SCHEMA are synthetic and don't take any space.

Answer 2

1. I expect the size you are seeing (Storage used) is the size of all databases, including system ones (performance_schema, information_schema & mysql). An instance I have is using ~58MB, with only one small database, however the free quota for even the smallest instance size is 500MB, so no need to worry about this. How did you calculate the 500KB?

2. All three (performance_schema, information_schema & mysql) system databases are necessary are present on my instance too.

3. ...

4. The size of the .sql database export file from phpmyadmin is not the same as the database file used by the server. It is contains SQL commands necessary to recreate the database.

It is not a miscalculation of "memory usage", it is the amount of (disk) storage used.