主键无效的mariadb优化

Question

如果您对一个非空列使用计数，在一个表上，没有任何where部分，优化器只返回该表中的行数。

如果您要求对UNIQE非空列(如主键)进行不同的计数，答案应该是相同的，但是这次mariadb进行了计算。

如果您在其他表上留下了join，但仍然没有where-parts，结果应该仍然是该表中的行数。

mariadb不使用此类优化是否有原因？如果一个未过滤的主键的不同计数可以给出任何其他结果，那么该表中的行数是否存在？

案件：

CREATE TABLE products (
    our_article_id varchar(50) CHARACTER SET utf8 NOT NULL,
    ...,
    PRIMARY KEY(our_article_id)
);

CREATE TABLE product_article_id (
    article_id varchar(255) COLLATE utf8_bin NOT NULL,
    our_article_id varchar(50) CHARACTER SET utf8 NOT NULL,
    ...
    PRIMARY KEY(article_id),
    INDEX(our_article_id)
);

计数查询，第一次，基本计数

DESCRIBE SELECT COUNT(our_article_id) FROM products;         
+------+-------------+-------+------+---------------+------+---------+------+------+------------------------------+
| id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                        |
+------+-------------+-------+------+---------------+------+---------+------+------+------------------------------+
|    1 | SIMPLE      | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | Select tables optimized away |
+------+-------------+-------+------+---------------+------+---------+------+------+------------------------------+

主键上的第二个不同

DESCRIBE SELECT COUNT(DISTINCT our_article_id) FROM products;
+------+-------------+----------+-------+---------------+---------+---------+------+--------+-------------+
| id   | select_type | table    | type  | possible_keys | key     | key_len | ref  | rows   | Extra       |
+------+-------------+----------+-------+---------------+---------+---------+------+--------+-------------+
|    1 | SIMPLE      | products | index | NULL          | PRIMARY | 152     | NULL | 225089 | Using index |
+------+-------------+----------+-------+---------------+---------+---------+------+--------+-------------+

第3次，主键独立，左联接，不含任何地方。

DESCRIBE SELECT COUNT(DISTINCT our_article_id) FROM products LEFT JOIN product_article_id USING (our_article_id);
+------+-------------+--------------------+-------+---------------+---------+---------+----------------------------------+--------+-------------+
| id   | select_type | table              | type  | possible_keys | key     | key_len | ref                              | rows   | Extra       |
+------+-------------+--------------------+-------+---------------+---------+---------+----------------------------------+--------+-------------+
|    1 | SIMPLE      | products           | index | NULL          | PRIMARY | 152     | NULL                             | 225089 | Using index |
|    1 | SIMPLE      | product_article_id | ref   | PRIMARY       | PRIMARY | 152     | testseek.products.our_article_id |  12579 | Using index |
+------+-------------+--------------------+-------+---------------+---------+---------+----------------------------------+--------+-------------+

Answer 1

“mariadb不使用此类优化有什么原因吗？”-- MySQL/MariaDB中有无数缺失的优化；这是缺失的。让我们来看看历史。

大约20年前，MySQL作为一个精益的数据库引擎诞生了。它将重点放在大多数人需要的特性上，同时最小化开销。这意味着许多罕见的优化不在早期版本中，只有当它们看起来足够重要时才会添加。

以PRIMARY KEY为例。它被定义为独特的。它是由BTree组织的。而且，对于InnoDB，它也被定义为集群。其他供应商允许不同的组合聚类、非BTree索引等。MySQL认为这些限制对于“大多数”人来说“足够好”。

多年来，“最糟糕”的疏漏已逐渐得到解决。交易可能是最大也是最重要的。它是在2001年(？)到达的，随着8.0的出现，MyISAM今年(2016年)将被移除。

4.1 (2002年？)saw子查询。在此之前，创建一个tmp表是“足够好”的。现在，(8.0)子查询正在由CTE统一处理，这涵盖了tmp表和子查询都无法有效完成的一些事情。

在MySQL 5.6和5.7以及MariaDB 10.x中已经有了大量的优化；您可能只使用了其中的几个。产品分为“递减回报”。如果它放慢优化器的速度以检查下一个非常罕见的优化，那么它就会破坏它的“精益”传统。

同时，像我这样的人花了很多时间说"MySQL/MariaDB没有这种功能，这是解决办法“。在你的情况下，它是较短的COUNT(*)。由于有一个干净的解决办法，你的建议可能要再过十年才能得到落实。可以向bugs.mysql.com或mariadb.com提交错误报告，以建议优化。

另一个几乎从来不需要的情况是INDEX(a ASC, b DESC)作为优化ORDER BY a ASC, b DESC的一种方法。那是8.0版的。但我怀疑每5000人中是否有一个以上的查询确实需要它。(我见过很多问题。)我认为，它的稀缺性就是为什么它花了20年才得以实施的原因。没有一个干净的解决办法，这就是为什么它不需要再用十年。