【问题标题】:Optimising query with large WHERE IN and Date clause使用大型 WHERE IN 和 Date 子句优化查询
【发布时间】:2020-07-29 04:32:14
【问题描述】:

我有一个类似的查询:

SELECT
    ANY_VALUE(name) AS `name`,
    100 * SUM(score) / SUM(sum(score)) OVER (PARTITION BY date(scores.created_at)) AS `average_score`,
    ANY_VALUE(DATE_FORMAT(scores.created_at, "%Y-%m-%d")) AS `shift_date`
FROM
    `scores`
    INNER JOIN `shifts` ON `shifts`.`id` = `scores`.`shift_id`
WHERE
    `shifts`.`table_c_id` in(1, 2, 3, 4, 5, 6, 7, 8, 9, 10……)
    AND date(`scores`.`created_at`) >= '2020-01-01'
GROUP BY
    `name`,
    date(scores.created_at)
ORDER BY
    `shift_date` ASC;

where in 最多可以是 2000 个 ID,这些 ID 可能不是连续的, created_at where 最多可以是 14 个月前。目前,在这些级别上,执行时间为 10-20 秒。

我正在尝试对此进行优化。我尝试在scores 表上的created_at 上添加索引,但这没有效果。我还尝试将日期 where 子句更改为:

AND `scores`.`created_at` >= '2020-01-01 00:00:00

这又没有任何区别。

阅读了该主题后,有些人建议创建一个临时表,但我看不出这有什么好处。我也不确定如何在一个查询中执行此操作(甚至可能吗?)。

scores 表上的索引是:shift_idemployee_idname,created_at(用于另一个查询)。正如我所说,created_at 索引对此没有帮助。

班次表在table_c_idcreated_at 上有索引

一些网站建议使用WITHCTEs,但同样,我不确定这将如何工作或性能是否会真正提高。

分数和班次的架构是:

DROP TABLE IF EXISTS `scores`;
CREATE TABLE `scores` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `shift_id` int unsigned NOT NULL,
  `hash` varchar(40) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `sscore` double(8,2) unsigned NOT NULL,
  `created_at` timestamp NULL DEFAULT NULL
  PRIMARY KEY (`id`),
  KEY `scores_hash_index` (`hash`) USING BTREE,
  KEY `scores_shift_id_index` (`shift_id`) USING BTREE,
  KEY `scores_name_created_at_index` (`name`,`created_at`)
) ENGINE=InnoDB AUTO_INCREMENT=3140922 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

DROP TABLE IF EXISTS `shifts`;
CREATE TABLE `shifts` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `table_c_id` int unsigned NOT NULL,
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `shifts_table_c_id_index` (`table_c_id`),
  KEY `shifts_created_at_index` (`created_at`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=536392 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

更新

使用查找表查找名称:

names table: int unsigned, id, primary; varchar,名称

SELECT
    names.name AS `name`,
    100 * SUM(score) / SUM(sum(score)) OVER (PARTITION BY date(scores.created_at)) AS `average_score`,
    ANY_VALUE(DATE_FORMAT(scores.created_at, "%Y-%m-%d")) AS `shift_date`
FROM
    `scores`
    INNER JOIN `shifts` ON `shifts`.`id` = `scores`.`shift_id`
    INNER JOIN `names` ON `names`.id = `scores`.`name_id`
WHERE
    `shifts`.`table_c_id` in(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506)
    AND `scores`.`created_at` >= '2019-04-03'
GROUP BY
    `names`.`name`,
    date(scores.created_at)
ORDER BY
    `shift_date` ASC;

没有任何好处。在scores 表上为shift_idname_idcreated_at 建立索引也没有帮助。

【问题讨论】:

  • SUM(sum(score)) 好像错了
  • @zealous 没错
  • 最好写一个子查询并使用BETWEEN而不是IN
  • 输入 ID 可能并不总是连续的。将更新帖子。
  • 显示两个表的 DDL。将ANY_VALUE(DATE_FORMAT(scores.created_at, "%Y-%m-%d")) 替换为date(scores.created_at)

标签: mysql sql optimization mysql-8.0 database-optimization


【解决方案1】:

A 计划:避免使用窗口函数(其中许多比人们想象的要慢。)

SELECT
    ANY_VALUE(brand_name),
    100 * SUM(score) / init.tot AS `average_score`,
    DATE(scores.created_at) AS `shift_date`
FROM
    `scores`
INNER JOIN `shifts` ON `shifts`.`id` = `scores`.`shift_id`
JOIN ( SELECT SUM(score) AS tot FROM shifts
        WHERE table_c_id IN (...)
          AND `created_at` >= '2020-01-01' ) AS init
WHERE
    `shifts`.`table_c_id` in(1, 2, 3, 4, 5, 6, 7, 8, 9, 10……)
    AND `scores`.`created_at` >= '2020-01-01'
GROUP BY
    shift_date,
    `brand_name`
ORDER BY
    `shift_date` ASC;

注意事项:

  • 状态语法发生了一些变化。
  • 我认为namebrand_name 是相同的
  • 通过翻转GROUP BY 顺序,可以避免第二次排序。
  • 我使用派生表来计算总计,因此不需要OVER
  • scores 上的这种复合、覆盖、索引可能会有所帮助:

    INDEX(created_at, shift_id)
    

Plan B:使用 CTE 计算 SUM(score),然后完成查询。

【讨论】:

  • 这样快很多,但结果不正确。 stackoverflow.com/questions/61169223/… 是我提出的关于计算的问题 - 这似乎是一个奇怪的问题!
  • 你的不起作用的原因是init.tot是所有的总数,而窗口函数只是按日期聚合
  • @Shiv - 然后子查询需要按 DATE 分组。或类似的东西。 (我不明白原始查询的意图,所以我可能弄错了。)
  • 必须添加组,然后在外部查询中检查日期是否正确的位置大大减慢了速度
猜你喜欢
  • 1970-01-01
  • 2020-03-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-02-25
  • 1970-01-01
相关资源
最近更新 更多