MYSQL 在优化器缺陷在次验证，与MYSQL 熄火了还是成熟了？？

news2024/11/25 0:21:40

开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共850人左右 1 + 2 + 3）新人会进入3群。

上次在写了一篇关于MYSQL的优化器关于索引方面的问题的文章后，有同学说不对，当时答应在做更深入的测试，来深度证明MYSQL 的确在索引方面的一些问题。

我们还是产生1000万的数据，MYSQL 数据库版本8.030

CREATE TABLE `app_user` (

`id` int NOT NULL AUTO_INCREMENT COMMENT '主键',

`name` varchar(50) DEFAULT '' COMMENT '用户名称',

`email` varchar(50) NOT NULL COMMENT '邮箱',

`phone` varchar(20) DEFAULT '' COMMENT '手机号',

`gender` tinyint DEFAULT '0' COMMENT '性别（0-男：1-女）',

`password` varchar(100) NOT NULL COMMENT '密码',

`age` tinyint DEFAULT '0' COMMENT '年龄',

`create_time` datetime DEFAULT CURRENT_TIMESTAMP,

`update_time` datetime DEFAULT CURRENT_TIMESTAMP,

PRIMARY KEY (`id`),

KEY `idx_app_name_email_phone_gender_age_create_time` (`name`,`email`,`phone`,`gender`,`age`,`create_time`),

KEY `idx_app_name_email_phone_gender_age_create_time_pdate_time` (`name`,`email`,`phone`,`gender`,`age`,`create_time`,`update_time`)

) ENGINE=InnoDB AUTO_INCREMENT=11000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='app用户表'

SET GLOBAL log_bin_trust_function_creators=TRUE;

DELIMITER $$

CREATE FUNCTION mock_data()

RETURNS INT

BEGIN

DECLARE num INT DEFAULT 11000000;

DECLARE i INT DEFAULT 0;

WHILE i < num DO

INSERT INTO app_user(`name`,`email`,`phone`,`gender`,`password`,`age`)

VALUES(CONCAT('用户',i),'2548928007qq.com',CONCAT('18',FLOOR(RAND() * ((999999999 - 100000000) + 1000000000))),FLOOR(RAND() * 2),UUID(),FLOOR(RAND() * 100));

SET i = i + 1;

END WHILE;

RETURN i;

END;

DELIMITER $$

SELECT mock_data();

set session optimizer_trace = 'enabled=on';

针对以上的表进行查询

select * from app_user where name in ('用户1','用户2') and create_time = '2023-04-14'；

通过trace 最终走了 name 与 create_time的索引

我们调整索引将 name 和 create_time 的索引清理后，在添加一个name ,phone,create_time 的索引，在使用同样的查询后，查询并没有在走我们新添加的索引，而是走了一个更大的索引 idx_app_name_email_phone_gender_age_create_time` (`name`,`email`,`phone`,`gender`,`age`,`create_time`) 而没有走 (name,phone,create_time) 索引，按照我们常人的思维模式，我在选择一个不能覆盖我所有查询返回值的情况下，我应该选择一个更小的索引，而让我占据的 share buffer pool , 而 MYSQL的优化器竟然选择了，不是最大的索引也不是最小的索引，而是一个 13不靠的索引。

我们经过查询发现实际上，针对于MYSQL 索引的大小并在计算COST 中虽然三个索引都符合要求，但是在COST的计算上这三个索引的COST 是一点都不差。但明眼人都看的出，这个索引本身在使用的时候是有差别的，根据查询的语句与索引的匹配，最优的 idx_name_phone_create_time,但是没有走。