什么会导致查询 A 而不是查询 B 中的性能问题？

Question

我有一个带有 apx 的表 (MYSQL 8)。 100M 条记录存储各种位的股票数据（价格、日期等），下面的查询 A 运行时间 date 上有一个索引，表的主键是（symbol，date）。什么会导致这两个查询之间出现如此显着的差异，以及什么可能会加快表现不佳的速度？

查询 A：

SELECT symbol, MIN(date)
FROM Stocks
WHERE date BETWEEN '2015-01-01' AND '2020-01-01'
GROUP BY symbol

查询 B

SELECT symbol, MIN(date)
FROM Stocks
WHERE date BETWEEN '2015-01-01' AND '2020-01-01' AND market_cap > 20
GROUP BY symbol

我面临的另一个挑战是，有时我想按market_cap 进行过滤，但有时我想按其他数字字段（gross_profit、total_assets 等）进行过滤。查询是由一个表单生成的，该表单具有许多与参数相关的可选输入。

表架构

CREATE TABLE IF NOT EXISTS cri_v0_995 (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  company_id MEDIUMINT UNSIGNED NOT NULL, 
  dt DATE NOT NULL,
  price DECIMAL(18, 2),
  market_cap DECIMAL(12, 4),
  div_yield DECIMAL(4,2), -- this is always 0
  price_to_nte DOUBLE,
  price_to_mte DOUBLE,
  nte_to_price DECIMAL(16, 10),
  ante_to_price DECIMAL(16, 10),
  ate_to_price DECIMAL(18, 10),
  price_to_sales DOUBLE,
  price_to_earnings DOUBLE,
  cur_liq_to_mcap DECIMAL(4, 2), -- this is always 0
  net_liq_to_mcap DOUBLE,
  g3_rev_growth_and_trend DECIMAL(14, 10),
  p_cri_score DECIMAL(14, 10),
  f_cri_score DECIMAL(10, 7),
  cri_score DECIMAL(14, 10),
  PRIMARY KEY (id),
  FOREIGN KEY (company_id) REFERENCES companies (id),
  UNIQUE KEY (company_id, dt)
);

请注意，有几个列我不确定。它们一直是零，但我不知道它们背后的意图是什么。

（编辑 1 以解决缺少的GROUP BYs） （编辑 2 添加表架构）

Answer 1

第一个查询可以简单地遍历表：

• 对于每个符号（方便地是 PK 的开始）
• 找到第一行（“第一”，因为索引的第二部分是date）也是>=开始日期
• 如果该日期不是

第二个查询需要查看每一行来检查market_cap；它不能跳过桌子。

如果您在Symbols 表中有current_market_cap，则可以在market_cap 之前 JOINing 过滤到此表。

WHERE 子句中的两个范围使得优化变得非常困难。 INDEX 是一维的。

使用PARTITION BY TODAYS(date) 需要对表进行重大的结构更改。它可能（也可能不会！）帮助您的查询运行得更快——通过使用“分区修剪”来限制需要检查的行数。 （我说“可能不是”，因为查询正在查看 5 年的范围，这可能是整个数据的很大一部分。）

更多关于分区的讨论：http://mysql.rjweb.org/doc.php/partitionmaint 和 http://mysql.rjweb.org/doc.php/find_nearest_in_mysql -- 后一个链接讨论了一个不同的 2D 问题（地理“查找最近”）；将其应用于您的查询有点牵强。

由于您有很多最终用户可能会过滤的列和 1 亿行，让我们从另一个方向着手：最小化表大小。如果表不能完全缓存在 buffer_pool 中，这一点尤其重要——导致 I/O 绑定。告诉我们SHOW CREATE TABLE；让我们讨论一下每一列，以及它是否可以缩小。

更多

• 将 symbol VARCHAR... 更改为 company_id MEDIUMINT UNSIGNED 可能在数据和索引之间节省了 1GB。
• 摆脱id，提升UNIQUE(company_id, dt)为PK。通过消除唯一的二级索引，这将节省几 GB。 （您的更改可能是有益的。
• 大部分DOUBLEs 都是矫枉过正？ FLOAT 每个会节省 4 个字节，但仍会为您提供 6-7 个有效数字。
• 您可能需要INDEX(dt) 进行其他查询。
• market_cap 上的过滤器可能会妨碍分组最大优化。
• 根据磁盘空间和其他查询，可能对PARTITION BY RANGE(TO_DAYS(dt)) 有益，但按年分组。 （5 年 + 1 天）跨度将达到 6 个分区。 （参见“分区修剪”）这实际上不会对性能产生太大影响。
• （大约 18 年前，我使用过这样的数据集。）
• price DECIMAL(18, 2) 占用 9 个字节。它允许数十亿美元，尚未达到。它只有 2 位小数，因此在转换为小数之前（从 /2、/4、/8、/16 等），它不会精确保存金额。
• market_cap DECIMAL(12, 4)（6 字节）对于某些公司来说可能不够大，对于索引当然也不够。小数点后 4 位可能是浪费。
• 建议运行SELECT MAX(market_cap), MAX(price), ... 看看现在的数字有多大。

Answer 2

对于这两个查询，您可能应该按符号进行聚合。因此，第二个当前非性能查询应该是：

SELECT symbol, MIN(date)
FROM Stocks
WHERE date BETWEEN '2015-01-01' AND '2020-01-01' AND market_cap > 20
GROUP BY symbol;

你想要的索引至少应该覆盖整个WHERE子句：

CREATE INDEX ON Stocks (date, market_cap);

如果您对两个查询都运行EXPLAIN，在添加GROUP BY 之后，您可能会发现您当前的日期单列索引甚至没有在第二个查询中使用。

Answer 3

也许您需要在 sql 查询 B 中强制使用索引。

SELECT symbol, MIN(date)
FROM Stocks use index (`indexNameOfDate`)
WHERE date BETWEEN '2015-01-01' AND '2020-01-01' AND market_cap > 20
GROUP BY symbol

或者你可以强制使用primaryKey index。

这样做可以节省 sql 引擎选择索引本身的时间。 你也可以找到哪个更快。

另外，如果你通常使用date 和market_cap 来过滤数据，也许你需要创建一个索引来覆盖它们。

就像@Tim Biegeleisen 所说的那样。

创建股票指数（日期、市值）；