Google Cloud SQL中slow

Google Cloud SQL中slow_log表的低性能(Low performance of slow_log table in Google Cloud SQL)

我正在将Google Cloud SQL实例用于Google App Engine上的项目。 我已启用慢查询日志标志来存储慢查询。 但是slow_log表的性能非常糟糕，仅仅为了选择一些数据需要大约6分钟。

我还注意到记录的查询并不是真的“慢”，我的意思是它们的查询时间和锁定时间都是0。 见例子：

mysql> SELECT * FROM slow_log LIMIT 900000,1; start_time: 2015-05-01 20:06:16 query_time: 00:00:00 lock_time: 00:00:00 rows_sent: 1 rows_examined: 1 sql_text: select * from mysql> SELECT * FROM slow_log LIMIT 900000,1; start_time: 2015-05-01 20:06:16 query_time: 00:00:00 lock_time: 00:00:00 rows_sent: 1 rows_examined: 1 sql_text: select * from services where name = 'facebook' limit 1 1 row in set (6 min 23.37 sec)

我应该在表中添加一些索引吗？ 或者我应该截断它以减少行数？

I'm using a Google Cloud SQL instance for a project on Google App Engine. I have enabled the slow query log flag to store slow queries. But the slow_log table's performance is really bad, just for selecting some data took about 6 minutes.

I have also noted that the logged queries are not really "slow", i mean they have 0 as query time and lock time. See example:

mysql> SELECT * FROM slow_log LIMIT 900000,1; start_time: 2015-05-01 20:06:16 query_time: 00:00:00 lock_time: 00:00:00 rows_sent: 1 rows_examined: 1 sql_text: select * fromserviceswherename= 'facebook' limit 1 1 row in set (6 min 23.37 sec)

Should I add some indexes to the table? or should I truncate it to decrease the number of rows?

最满意答案

慢查询不是需要很长时间才能执行的查询。 这不是一个有用的检测工具，因为你可以通过简单的时间检测自己。 它告诉你的是设计糟糕的查询在编译时它检测到没有好的索引并且必须扫描整个表。 。 这是至关重要的，因为它告诉您查询将是大数据的问题，即使现在需要零时间。 Tldr：添加适当的索引。

I have found the problem, the flag long_query_time was set to 0, so every log was stored.