기본 키의 mariadb 최적화가 작동하지 않음

기본 키의 mariadb 최적화가 작동하지 않음

null이 아닌 열에 대해 where-parts 없이 카운트를 사용하면 옵티마이저는 해당 테이블의 행 수만 반환합니다.

PRIMAY KEY와 같이 늘 이외의 UNIQE 컬럼에 DISTINT 카운트를 요구하면 답변은 동일해야 하지만 이번에는 mariadb가 지정된 계산을 수행합니다.

다른 테이블에서 조인한 상태로 where 부품이 없는 경우에도 결과는 해당 테이블의 행 수여야 합니다.

mariadb가 thous optimizations를 사용하지 않는 이유가 있나요?필터링되지 않은 기본 키의 DISTINT 카운트가 해당 탭의 행 수 이외의 결과를 제공할 수 있는 경우가 있습니까?

케이스:

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 |
+------+-------------+----------+-------+---------------+---------+---------+------+--------+-------------+

세 번째, 기본 키에서 구별되며 부품 위치 없이 왼쪽 조인

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 |
+------+-------------+--------------------+-------+---------------+---------+---------+----------------------------------+--------+-------------+

"mariadb가 thous optimizations를 사용하지 않는 이유가 있나요?" MySQL/MariaDB에는 수많은 최적화가 누락되어 있습니다.역사를 살펴봅시다.

MySQL은 약 20년 전에 린하고 비열한 데이터베이스 엔진으로 시작되었습니다.오버헤드를 최소화하면서 대부분의 사람들이 필요로 하는 기능에 초점을 맞췄습니다.즉, 많은 드문 최적화는 초기 릴리스에는 없었으며, 시간이 지남에 따라 충분히 중요한 경우에만 추가된다는 것을 의미합니다.

를 사용하다PRIMARY KEY,예를들면.UNIQURE로 정의되어 있습니다.BTree가 정리되어 있습니다.또한 InnoDB에서는 클러스터로 정의됩니다.다른 벤더는 다양한 조합의 클러스터링, 비 BTREE 인덱싱 등을 허용합니다.MySQL은 이러한 제한이 "대부분" 사용자에게 "충분히" 적합하다고 판단했습니다.

몇 년 동안 '최악의' 누락이 점차 수정되었다.거래가 가장 크고 중요할 것입니다.2001년(?)에 도착했으며, 올해(2016년) 8.0이 등장하면서 MyISAM이 제거되고 있습니다.

4.1(2002?)에서는 서브쿼리가 표시되었습니다.그 이전에는 tmp 테이블을 작성하는 것으로 충분했습니다.현재 (8.0) 서브쿼리는 CTE에 의해1개 업되고 있습니다.이것은 tmp 테이블이나 서브쿼리 모두 효율적으로 수행할 수 없는 몇 가지 사항을 커버하고 있습니다.

MySQL 5.6 및 5.7과 MariaDB 10.x에는 수많은 최적화가 적용되어 있습니다.여러분들은 아마 그 중 몇 개 이상을 사용하지 않았을 것입니다.상품이 '수익 감소'에 빠져 있다.향후 수천 개의 매우 드문 최적화를 확인하기 위해 최적화 도구의 속도를 늦추면 "위험하고 평균적인" 전통을 훼손할 수 있습니다.

「MySQL/MariaDB」의 「MySQL/MariaDB」의 「MySQL/MariaDB는, 「MySQL/MariaDB」를 참조해 주세요. 해결 방법이 있습니다."고고말말말말다다, 짧다COUNT(*)당신의 경우는요.깔끔한 회피책이 있기 때문에 제안사항이 구현되기까지는 앞으로 10년이 걸릴 수 있습니다.mariadb.com mariadb.com mariadb.com 입니다.

없는 또 하나의 거거 another른른 른른른른이다.INDEX(a ASC, b DESC)ORDER BY a ASC, b DESC8.0.8.0으로 하지만 5,000개 중 2개 이상의 쿼리가 정말로 필요한지는 의문입니다.(저는 많은 쿼리를 봐왔습니다.)나는 그것의 희귀성이 그것을 시행하는데 20년이 걸린 이유라고 제안한다.깔끔한 회피책의 부족이 그것이 10년 더 걸리지 않은 이유이다.

언급URL : https://stackoverflow.com/questions/39766192/mariadb-optimisation-of-primary-key-not-working