Mysql Sql查询填充/tmp，运行时间为分钟

我有一个查询，它没有对大量数据（IMHO）进行操作，但执行需要几分钟（5-10）的时间，最后在执行时填充了/tmp空间（高达20GB）。一旦完成，空间将再次释放

查询如下：

SELECT c.name, count(b.id), c.parent_accounting_reference, o.contract, a.contact_person, a.address_email, a.address_phone, a.address_fax, concat(ifnull(concat(a.description, ', '),''), ifnull(concat(a.apt_unit, ', '),''), ifnull(concat(a.preamble, ', '),''), ifnull(addr_entered,''))                FROM
                booking b
            join visit v on (b.visit_id = v.id)
            join super_booking s on (v.super_booking_id = s.id)
            join customer c on (s.customer_id = c.id)
            join address a on (a.customer_id = c.id)
            join customer_number cn on (cn.customer_numbers_id = c.id)
            join number n on (cn.number_id = n.id)
            join customer_email ce on (ce.customer_emails_id = c.id)
            join email e on (ce.email_id = e.id)
            left join organization o on (o.accounting_reference = c.parent_accounting_reference)
            left join address_type at on (a.type_id = at.id and at.name_key = 'billing')
            where s.company_id = 1
            and v.expected_start_date between '2015-01-01 00:00:00' and '2015-02-01 00:00:00'
            group by s.customer_id
            order by count(b.id) desc

对此的解释计划如下：

+----+-------------+-------+--------+--------------------------------------------------------------+---------------------+---------+--------------------------------------+-------+----------------------------------------------+
| id | select_type | table | type   | possible_keys                                                | key                 | key_len | ref                                  | rows  | Extra                                        |
+----+-------------+-------+--------+--------------------------------------------------------------+---------------------+---------+--------------------------------------+-------+----------------------------------------------+
|  1 | SIMPLE      | s     | ref    | PRIMARY,FKC4F8739580E01B03,FKC4F8739597AD73B1                | FKC4F8739580E01B03  | 9       | const                                | 74088 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | ce    | ref    | FK864C4FFBAF6458E3,customer_emails_id,customer_emails_id_2   | customer_emails_id  | 9       | id_dev.s.customer_id                 |     1 | Using where                                  |
|  1 | SIMPLE      | cn    | ref    | FK530F62CA30E87991,customer_numbers_id,customer_numbers_id_2 | customer_numbers_id | 9       | id_dev.ce.customer_emails_id         |     1 | Using where                                  |
|  1 | SIMPLE      | c     | eq_ref | PRIMARY                                                      | PRIMARY             | 8       | id_dev.s.customer_id                 |     1 |                                              |
|  1 | SIMPLE      | e     | eq_ref | PRIMARY                                                      | PRIMARY             | 8       | id_dev.ce.email_id                   |     1 | Using index                                  |
|  1 | SIMPLE      | n     | eq_ref | PRIMARY                                                      | PRIMARY             | 8       | id_dev.cn.number_id                  |     1 | Using index                                  |
|  1 | SIMPLE      | v     | ref    | PRIMARY,FK6B04D4BEF4FD9A                                     | FK6B04D4BEF4FD9A    | 8       | id_dev.s.id                          |     1 | Using where                                  |
|  1 | SIMPLE      | b     | ref    | FK3DB0859E1684683                                            | FK3DB0859E1684683   | 8       | id_dev.v.id                          |     1 | Using index                                  |
|  1 | SIMPLE      | o     | ref    | org_acct_reference                                           | org_acct_reference  | 767     | id_dev.c.parent_accounting_reference |     1 |                                              |
|  1 | SIMPLE      | a     | ref    | FKADDRCUST,customer_address_idx                              | FKADDRCUST          | 9       | id_dev.c.id                          |   256 | Using where                                  |
|  1 | SIMPLE      | at    | eq_ref | PRIMARY                                                      | PRIMARY             | 8       | id_dev.a.type_id                     |     1 |                                              |
+----+-------------+-------+--------+--------------------------------------------------------------+---------------------+---------+--------------------------------------+-------+----------------------------------------------+

---

它似乎使用了正确的索引，所以我不明白为什么/tmp的使用量大，执行时间长。

您的查询使用了一个临时表，您可以通过

使用临时表看到它解释结果中的注释。您的MySQL设置可能配置为使用/tmp存储临时表

如果要进一步优化查询，可能需要研究为什么需要临时表。最好的方法是逐步简化查询，直到找出原因。在本例中，可能只是需要处理的行数，因此如果确实需要所有这些数据，那么可能也需要临时表。但不要放弃为我优化；）

顺便说一句，另一方面，您可能需要研究COALESCE来处理空值。
您被困在一个临时表中，因为您正在执行聚合查询，然后根据聚合中的一个结果对其排序。您的优化目标应该是减少临时表中的行和/或列的数量

在
访问中添加索引。预计开始日期
。这可能有助于MySQL更快地满足您的查询，特别是当您的
visit
表中有许多行位于查询的日期范围之外时

看起来您正在努力寻找特定日期范围内预订量最多的客户

因此，让我们从一个子查询开始，以汇总数据库中最少的材料

        SELECT count(*) booking_count, s.customer_id           
          FROM  visit v
          JOIN  super_booking s ON v.super_booking_id = s.id
          JOIN  booking b ON v.id = b.visit_id
         WHERE  v.expected_start_date <= '2015-01-01 00:00:00'
           AND  v.expected_start_date >  '2015-02-01 00:00:00'
           AND  s.company_id = 1
         GROUP BY s.customer_id 

通过减少需要汇总的数据量，这将大大加快您的工作

注意：注意
日期之间的陷阱。你真的想要吗

     date >= this
 AND date < that

您似乎误用了对
分组依据
的非标准MySQL扩展。这使得您很难猜测查询的意图。读这个。
     date >= this
 AND date < that

    date >= this
AND date <= that