超大表上的 MySQL 数据库性能选择

Question

我有一个销售数据表，其中平均每天插入 1,329,415 行。我必须每天从表格中生成不同格式的报告。但是从表中查询太慢了。这是我的 SHOW CREATE TABLE 命令输出。

CREATE TABLE `query_manager_table` (
  `mtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `region_id` int(2) NOT NULL,
  `rtslug` varchar(10) DEFAULT NULL,
  `dsid` int(3) NOT NULL,
  `dpid` int(3) NOT NULL,
  `route_number` int(4) NOT NULL,
  `route_id` int(11) NOT NULL,
  `rtlid` int(11) NOT NULL,
  `retailer_code` varchar(16) DEFAULT NULL,
  `platform_code` varchar(16) DEFAULT NULL,
  `prid` int(4) NOT NULL,
  `skid` int(4) NOT NULL,
  `group` int(4) NOT NULL,
  `family` int(4) NOT NULL,
  `volume` float DEFAULT NULL,
  `value` float(7,2) DEFAULT NULL,
  `date` date NOT NULL DEFAULT '0000-00-00',
  `outlets` int(4) NOT NULL,
  `visited` int(4) NOT NULL,
  `channel` int(3) DEFAULT NULL,
  `subchannel` int(3) DEFAULT NULL,
  `tpg` int(4) DEFAULT NULL,
  `ioq` int(10) DEFAULT NULL,
  `sales_time` int(11) DEFAULT NULL,
  PRIMARY KEY (`dpid`,`route_id`,`rtlid`,`prid`,`skid`,`date`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

/*!50100 PARTITION BY LIST (YEAR(date) * 100 + QUARTER(date))
(PARTITION y2017q1 VALUES IN (201701) ENGINE = InnoDB,
 PARTITION y2017q2 VALUES IN (201702) ENGINE = InnoDB,
 PARTITION y2017q3 VALUES IN (201703) ENGINE = InnoDB,
 PARTITION y2017q4 VALUES IN (201704) ENGINE = InnoDB,
 PARTITION y2018q1 VALUES IN (201801) ENGINE = InnoDB,
 PARTITION y2018q2 VALUES IN (201802) ENGINE = InnoDB,
 PARTITION y2018q3 VALUES IN (201803) ENGINE = InnoDB,
 PARTITION y2018q4 VALUES IN (201804) ENGINE = InnoDB,
 PARTITION y2019q1 VALUES IN (201901) ENGINE = InnoDB,
 PARTITION y2019q2 VALUES IN (201902) ENGINE = InnoDB,
 PARTITION y2019q3 VALUES IN (201903) ENGINE = InnoDB,
 PARTITION y2019q4 VALUES IN (201904) ENGINE = InnoDB) */

现在我只想通过以下查询了解从 9 月 1 日到 9 月 9 日的零售商销售额 -

SELECT
            query_manager_table.dpid,
            query_manager_table.route_id,
            query_manager_table.rtlid,
            query_manager_table.prid,
            SUM(query_manager_table.`volume`) AS sales,
            1 AS memos
        FROM
            query_manager_table
        WHERE
            query_manager_table.date BETWEEN '2018-09-01'
        AND '2018-09-08'    
GROUP BY
            query_manager_table.dpid,
            query_manager_table.rtlid,
            query_manager_table.date

但这需要大约 500-700 秒。我添加了dpid IN (1,2,.....) 和prid IN (1,2,....)，因为这两个文件都被添加为主键。然后输出在 300 秒后出现。我做错了什么？

+----+-------------+---------------------+------+---------------+------+---------+------+-----------+----------------------------------------------+
| id | select_type | table               | type | possible_keys | key  | key_len | ref  | rows      | Extra                                        |
+----+-------------+---------------------+------+---------------+------+---------+------+-----------+----------------------------------------------+
|  1 | SIMPLE      | query_manager_table | ALL  | PRIMARY       | NULL | NULL    | NULL | 129065467 | Using where; Using temporary; Using filesort |
+----+-------------+---------------------+------+---------------+------+---------+------+-----------+----------------------------------------------+

当我在 where 条件下添加所有 dpid 和 prid 时，EXPAIN 看起来像

+----+-------------+---------------------+-------+---------------+---------+---------+------+--------+----------------------------------------------+
    | id | select_type | table               | type  | possible_keys | key     | key_len | ref  | rows   | Extra                                        |
    +----+-------------+---------------------+-------+---------------+---------+---------+------+--------+----------------------------------------------+
    |  1 | SIMPLE      | query_manager_table | range | PRIMARY       | PRIMARY | 4       | NULL | 128002 | Using where; Using temporary; Using filesort |
    +----+-------------+---------------------+-------+---------------+---------+---------+------+--------+----------------------------------------------+

有没有办法优化表或查询？ 如果我为第一个运行 EXPLAIN PARTITIONS SELECT... 然后得到 -

+----+-------------+---------------------+-------------------------------------------------------------------------------------------------+------+---------------+------+---------+------+-----------+----------------------------------------------+
| id | select_type | table               | partitions                                                                                      | type | possible_keys | key  | key_len | ref  | rows      | Extra                                        |
+----+-------------+---------------------+-------------------------------------------------------------------------------------------------+------+---------------+------+---------+------+-----------+----------------------------------------------+
|  1 | SIMPLE      | query_manager_table | y2017q1,y2017q2,y2017q3,y2017q4,y2018q1,y2018q2,y2018q3,y2018q4,y2019q1,y2019q2,y2019q3,y2019q4 | ALL  | PRIMARY       | NULL | NULL    | NULL | 127129410 | Using where; Using temporary; Using filesort |
+----+-------------+---------------------+-------------------------------------------------------------------------------------------------+------+---------------+------+---------+------+-----------+----------------------------------------------+

我得到的第二个 -

+----+-------------+---------------------+-------------------------------------------------------------------------------------------------+-------+---------------+---------+---------+------+--------+----------------------------------------------+
| id | select_type | table               | partitions                                                                                      | type  | possible_keys | key     | key_len | ref  | rows   | Extra                                        |
+----+-------------+---------------------+-------------------------------------------------------------------------------------------------+-------+---------------+---------+---------+------+--------+----------------------------------------------+
|  1 | SIMPLE      | query_manager_table | y2017q1,y2017q2,y2017q3,y2017q4,y2018q1,y2018q2,y2018q3,y2018q4,y2019q1,y2019q2,y2019q3,y2019q4 | range | PRIMARY       | PRIMARY | 4       | NULL | 153424 | Using where; Using temporary; Using filesort |
+----+-------------+---------------------+-------------------------------------------------------------------------------------------------+-------+---------------+---------+---------+------+--------+----------------------------------------------+

Answer 1

INDEXes 用于提高SELECTs 的效率。

PRIMARY KEY（在 MySQL 中）根据定义是唯一的 INDEX。它应该有一组最小的列来唯一标识一行。

任何唯一索引（包括 PK）也是“唯一性约束”——这可以防止插入具有相同 if 值集的多行。

索引是“从左边”使用的。也就是说，对于INDEX(a,b)，如果a 没有用处，它就不会到达b。

PARTITION BY LIST 几乎没用。它很少（如果有的话）提高性能。您向我们展示了几个问题；让我们看看更多典型查询，以便我们可以帮助您处理索引和分区。

    WHERE
        query_manager_table.date BETWEEN '2018-09-01'
                                     AND '2018-09-08'    

请求INDEX(date)。在复合索引中，不会到达“范围”之后的列。也就是说，在INDEX(date, x, y) 中，测试date 的范围（例如WHERE 中的8 天），不会让它使用x 或y。另一方面，WHERE date = '2018-09-01' AND x=1 将使用更多的索引。

float(7,2) -- 不要在FLOAT 或DOUBLE 上使用(m,n) 选项。而是切换到DECIMAL。

INT 始终为 4 个字节。请参阅TINYINT（1 字节）、SMALLINT（2 字节）等。仅此一项，就可以将表大小减半。

解释一下：

PRIMARY KEY (`dpid`,`route_id`, ...
WHERE ... AND dpid IN (...) AND ...

设法将第一个（记住：'leftmost'）用于伪范围 IN，但不能在 PK 中使用其他任何东西，因为 route_id 是下一个。

这解释了为什么第二个 EXPLAIN 有一个较小的“行”。另外，请注意“key_len”中的“4”——这是dpid 中的字节数。

完成其中一些更改后，请返回，以便我们讨论如何使用汇总表加快处理速度。但是，“修改”可能会导致这种优化变得复杂。

你有多少内存？ innodb_buffer_pool_size的值是多少？

除非必须，否则不要使用 GUID；由于随机性，它们会减慢大型表上的操作。

Answer 2

我不会结合实际数据字段来创建主键。我将有一个字段，并使用一个自动递增的整数或者可能是一个 GUID 作为值。必须通过六个字段来识别唯一记录比通过一个需要更多时间，并且正如您所说，如果用户输入关键数据，您将面临重复字段的风险。

如果您出于业务原因将这六个字段放在一起时是唯一的，您还应该制定一个例程来确定插入的记录是否与这些字段的现有记录重复。如果您是批量插入，您需要在插入记录后执行此操作，而不是在插入时检查每条记录。您还需要索引这六个字段，以加快重复查询。

至于您的SELECT 查询，您可能希望索引WHERE 子句中的字段。在任何情况下，您都需要阅读执行计划并尝试使用不同的索引和关键结构（可能更容易对数据子集进行操作）。谷歌“mysql 执行计划”获取大量信息。