mysql> EXPLAIN SELECT * FROM `condominio_boleto`
INNER JOIN `contrato_contrato` ON (`condominio_boleto`.`contrato_id` = `contrato_contrato`.`id`)
INNER JOIN `cadastro_imovel` ON (`contrato_contrato`.`imovel_id` = `cadastro_imovel`.`id`)
INNER JOIN `cadastro_pessoa` ON (`contrato_contrato`.`pessoa_id` = `cadastro_pessoa`.`id`)
ORDER BY `condominio_boleto`.`id` DESC LIMIT 1;
+----+-------------+-------------------+--------+---------------------------------------------------------------+----------------------------+---------+------------------------------------+------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------------+--------+---------------------------------------------------------------+----------------------------+---------+------------------------------------+------+---------------------------------+
| 1 | SIMPLE | cadastro_imovel | ALL | PRIMARY | NULL | NULL | NULL | 128 | Using temporary; Using filesort |
| 1 | SIMPLE | contrato_contrato | ref | PRIMARY,contrato_contrato_33999a20,contrato_contrato_8b5ebd9d | contrato_contrato_33999a20 | 4 | mydb.cadastro_imovel.id | 1 | |
| 1 | SIMPLE | cadastro_pessoa | eq_ref | PRIMARY | PRIMARY | 4 | mydb.contrato_contrato.pessoa_id | 1 | |
| 1 | SIMPLE | condominio_boleto | ref | condominio_boleto_91c8cd68 | condominio_boleto_91c8cd68 | 4 | mydb.contrato_contrato.id | 9 | |
+----+-------------+-------------------+--------+---------------------------------------------------------------+----------------------------+---------+------------------------------------+------+---------------------------------+
4 rows in set (0.00 sec)
此查询需要3-4秒才能在Google Cloud SQL(D0实例)上运行。如果我删除ORDER BY
子句,它将不再显示Extra Using temporary; Using filesort
并且速度最高可达<100ms。但是因为它是由Django管理员自动生成的,所以我无法删除ORDER BY
条款。
所有这些表都非常小。 condominio_boleto
有5k记录,所有其他表的记录少于500条。
我可以使用索引加快速度吗?这是Google Cloud SQL上的已知问题吗?
答案 0 :(得分:1)
我在Google Cloud SQL Tier D0(128MB RAM)上有类似的经历。我的一个网站运行速度很慢,需要很长时间才能返回页面。运行Jet Profiler后,我发现我的数据库查询运行缓慢(执行2-3s,平均7个线程)。问题查询是具有内部联接和订单的问题。所以我升级到第D1层(512MB RAM),正如预期的那样,没有更慢的查询。我的猜测是D0不能处理高度负载或复杂查询。它主要适用于低使用率和测试。