推荐最新

mysql多结果集+覆盖索引无法满足需求的时候，有哪些优化sql的方式？什么时候会用到ES？

最初问题的背景是这样： * 例如对某个客户的报表生成需求，需要查询该客户在特定时间范围内的账单明细为了简化说明，下面忽略连接查询，则可能的sql如下： select out_trade_no, payer_id, amount, status, gmt_create from order where merchant_id=123 and gmt_create between #{start} and #{end} order by gmt_create desc; 那么至少会需要一个"(merchant_id, gmt_create)"这样的一个多列索引。此时因为要查询的字段比较多，所以不可能创建一个很长的多列索引来避免回表查询。而按照我的理解，这样的sql只能在二级索引上查到一条id就回表查询一次，如果gmt_create的范围拉的比较长（比如1个月），则会出现较多的随机IO。一个能想到的可能优化是通过增加每页可以读取的数据来提高查询效率——延迟关联,那么将sql改为如下： select o.out_trade_no, o.payer_id, o.amount, o.status, o.gmt_create from order as o inner join ( select id from order where merchant_id=123 and gmt_create between #{start} and #{end} ) as sub using(id) order by o.gmt_create desc; 应该是可以进一步提高效率的。不过最近我发现有些公司会直接使用ES来存储订单/明细表的数据，然后将类似这样的查询（例如报表需求）转发到es上执行，我想知道这样可以进一步提高查询效率吗？还是因为存在别的需求共同导致他们选择了es来代替这类sql查询？

浏览量337

楠楠不难难

请教mysql查询时创建中间表的效率问题？

数据库有一个学生表t_student有两个字段 id, name 我想找出name相同的所有数据的id，并根据name排序，好做对比。如 id | name ---|--- 1 | 张三 2 | 李四 3 | 张三 4 | 王五 5 | 王五我想找出的数据是 id | name ---|--- 1 | 张三 3 | 张三 4 | 王五 5 | 王五写下的sql如下 select id, name from t_student where name in (select name from t_student where name is not null group by name having count(*) > 1) order by name; 虽然能得到想要的数据，但是查询的速度很慢。要6s左右。后面发现这种写法，在数据量大时，查询时间能缩短10倍以上。由6s -> 0.6s。而区别是多了个中间表。 select id, name from t_student where name in (select t.name from (select name from t_student where name is not null group by name having count(*) > 1) as t) order by name; 为了判断是否是中间表的创建导致的查询效率的提升，我换了一种写法 select ts.id, ts.name from t_student ts inner join (select t.name from t_student where name is not null group by name having count(*) > 1) as t on ts.name = t.name order by name; 通过创建中间表然后join的方式，还是很快，大概也是0.6s。我想知道为什么这样，创建中间表为什么会比不创建要快这么多

浏览量138

CTang

为什么这个sql左连接这么慢？

SELECT ad.id, d.device_id, d.d_id AS variable_id, d.d_name, d.oper_type, d.d_type, d.d_decimal AS 'decimal', d.data_prot_param, ad.tag, ad.modbus_reg_addr, ad.modbus_area FROM box_api_data ad LEFT JOIN box_data_info d ON d.d_id = ad.variable_id WHERE ad.unique_code = '7000224061716030893' AND ad.topic_id = 572137887207493 AND d.unique_code = '7000224061716030893' 这个sql查询要6s多，但是我两张表数据量都不是很大呀。box_api_data目前40000条，box_data_info目前10006条。基本都是比较少的，这么个数据量连接查询居然干到了6s，是我sql有问题吗？目前两张表都没有索引。 CREATE TABLE `box_data_info` ( `id` int(11) NOT NULL AUTO_INCREMENT, `unique_code` varchar(50) NOT NULL COMMENT '所属编号', `device_id` int(11) NOT NULL COMMENT '所属设备', `d_id` int(11) NOT NULL COMMENT '变量标识', `d_name` varchar(128) NOT NULL COMMENT '变量名称', `oper_type` int(11) NOT NULL COMMENT '操作类型(0:只读,1:只写,2:读写)', `d_type` int(11) NOT NULL COMMENT '数据类型', `unit` varchar(30) DEFAULT NULL COMMENT '变量单位', `d_decimal` int(11) DEFAULT '0' COMMENT '小数位数', `min_range` varchar(20) DEFAULT NULL COMMENT '最小量程', `max_range` varchar(20) DEFAULT NULL COMMENT '最大量程', `r_formula` varchar(156) DEFAULT NULL COMMENT '读公式', `w_formula` varchar(156) DEFAULT NULL COMMENT '写公式', `d_status` int(11) DEFAULT NULL COMMENT '变量状态 0:离线，1:在线', `is_store` int(11) DEFAULT '0' COMMENT '是否存储', `data_prot_param` varchar(1000) DEFAULT NULL COMMENT '特殊配置', `is_custom` int(11) NOT NULL DEFAULT '0' COMMENT '是否是自定义变量(0：不是，1：是)', `trans_modbus_param` varchar(1000) DEFAULT NULL COMMENT '转换Modbus协议参数', `remark` varchar(256) DEFAULT NULL COMMENT '备注', `data_index` int(11) DEFAULT NULL COMMENT '数据索引', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=848295 DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC COMMENT='点表'; CREATE TABLE `box_api_data` ( `id` int(11) NOT NULL AUTO_INCREMENT, `topic_id` bigint(20) DEFAULT NULL COMMENT '主题id', `variable_id` int(11) DEFAULT NULL COMMENT '数据标识', `device_id` int(11) DEFAULT NULL COMMENT '设备id', `tag` varchar(127) DEFAULT NULL COMMENT '数据标签', `modbus_area` varchar(10) DEFAULT NULL COMMENT 'modebus区域', `modbus_reg_addr` int(11) DEFAULT NULL COMMENT 'modebus寄存器地址', `modbus_data_type` int(11) DEFAULT NULL COMMENT 'modbus在寄存器中的实际数据类型', `opcua_data_con` mediumtext COMMENT 'opcua特殊数据', `type` char(10) DEFAULT 'variable' COMMENT '类型（variable:变量，rule:规则）', `unique_code` varchar(50) NOT NULL COMMENT '网关编号', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2452557 DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC COMMENT='接口变量表'; "image.png" (https://wmprod.oss-cn-shanghai.aliyuncs.com/c/user/20240919/efc6db6479b42d768c5d721df073177e.png)

浏览量156

编程界菜niao

在MySQL中，用update join，里面有order by，会导致MySQL崩溃吗？

我现在有两个SQL文，第一个可以正常执行，第二个一执行MySQL就崩溃。。崩溃指的是：docker里面对应的那个MySQL容器直接没了，docker ps -a都看不到的那种。 «第一个SQL文：» update cfg_dev_network_push_status as T1 inner join cfg_dev_network_bind_status as T2 on T1.task_id = T2.id and T1.del_flag = '0' and T1.push_type = '1' and T1.push_result != '0' and T1.push_retry_times < 3 and T2.del_flag = '0' and T2.dev_id = 'theDevId' and T2.status = '1' set T1.push_retry_times = T1.push_retry_times + 1, T1.push_status = '1', T1.push_end_time = '20231010141154002', T1.push_result = '1', T1.fail_reason = '109' order by T1.id asc «第二个SQL文：» update cfg_dev_network_push_status as T1 inner join cfg_dev_network_bind_status as T2 on T1.task_id = T2.id and T1.del_flag = '0' and T1.push_type = '1' and T1.push_result != '0' and T1.push_retry_times < 3 and T2.del_flag = '0' and T2.dev_id = 'theDevId' and T2.status = '1' set T1.push_retry_times = T1.push_retry_times + 1, T1.push_status = '1', T1.push_end_time = '20231010141154002', T1.push_result = '1', T1.fail_reason = '109' order by T1.push_status desc, T1.push_retry_times desc, T1.id asc 经测试，第二个SQL文里面，"T1.push_status desc"和"T1.push_retry_times desc"，加任意一个，都会导致MySQL崩溃，只有"T1.id asc"的时候，是可以正常执行的。 push_status的数据类型是char(1)，数据里面非0即1。 push_retry_times的数据类型是int。数据库中两个表的数据都在50条左右，不存在内存过大的影响；直接在DBeaver中进行数据查询，不考虑锁的影响。之后我在服务器中没找到MySQL相关崩溃的日志。。。。所以，为啥会崩呗，求各路大神帮助~ ================================================================= 建表文如下所示 -- `lebon-infra-dev`.cfg_dev_network_push_status definition CREATE TABLE `cfg_dev_network_push_status` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '流水号 | 与id为同一字段，自增数列', `task_id` varchar(16) NOT NULL COMMENT '任务ID', `push_status` char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '0' COMMENT '推送状态(0:待推送/1:已推送/2:已取消)', `push_plan_time` char(14) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '预约推送时间（YYYYMMDDHHMMSS）', `push_type` char(1) NOT NULL COMMENT '推送种类(1:推送配置项/2:推送优先度/3:推送重启命令)', `dev_id` varchar(32) NOT NULL COMMENT '设备ID', `config_group_id` varchar(16) NOT NULL COMMENT '配置组ID', `config_item_id` varchar(16) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '配置项ID', `push_begin_time` char(17) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '00000000000000000' COMMENT '推送开始时间（YYYYMMDDHHMMSSFFF）', `push_end_time` char(17) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '00000000000000000' COMMENT '推送结束时间（YYYYMMDDHHMMSSFFF）', `push_duration_s` int NOT NULL DEFAULT '0' COMMENT '推送耗时', `push_result` char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '推送结果0:成功/1:失败', `fail_reason` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '失败原因', `push_retry_times` int NOT NULL DEFAULT '0' COMMENT '重试次数', `remark` varchar(256) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '备注', `del_flag` char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '0' COMMENT '删除状态', `version` int NOT NULL DEFAULT '0' COMMENT '版本锁', `create_by` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '创建人', `create_time` datetime NOT NULL COMMENT '创建时间', `update_by` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '更新人', `update_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `cfg_dev_network_push_status_un` (`id`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=149 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='配置-终端网络配置推送状态'; -- `lebon-infra-dev`.cfg_dev_network_bind_status definition CREATE TABLE `cfg_dev_network_bind_status` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '任务ID | 与id为同一字段，自增数列', `dev_id` varchar(32) NOT NULL COMMENT '设备ID', `config_group_id` varchar(16) NOT NULL COMMENT '配置组ID', `config_group_name` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '配置组名', `status` char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '0' COMMENT '状态', `push_plan_time` char(14) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '预约推送时间(YYYYMMDDHHMMSS)', `push_begin_time` char(17) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '00000000000000000' COMMENT '推送开始时间(YYYYMMDDHHMMSSFFF)', `push_end_time` char(17) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '00000000000000000' COMMENT '推送结束时间(YYYYMMDDHHMMSSFFF)', `push_duration_s` int NOT NULL DEFAULT '0' COMMENT '推送耗时', `effective_time` char(17) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '00000000000000000' COMMENT '实际生效时间(YYYYMMDDHHMMSSFFF)', `invalid_time` char(17) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '00000000000000000' COMMENT '实际失效时间(YYYYMMDDHHMMSSFFF)', `fail_reason` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '失败原因', `cancel_reason` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '取消原因', `operator` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '操作者', `remark` varchar(256) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '备注', `version` int NOT NULL DEFAULT '0' COMMENT '版本锁', `del_flag` char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '0' COMMENT '删除状态', `create_by` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '创建人', `create_time` datetime NOT NULL COMMENT '创建时间', `update_by` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '更新人', `update_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`) USING BTREE, UNIQUE KEY `cfg_dev_network_bind_status_un` (`id`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=1070 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='配置-终端网络配置绑定状态';

浏览量15

嚯嚯嚯嚯嚯嚯

如何找到mysql中都执行了哪些全表扫描的sql？

通过 mysql_global_status_select_scan 参数可以获得全表扫描的sql执行数量，是否可以通过某种手段得到这些sql？尝试从general log中查询，但是没有找到相关信息。除了full scan类型的查询外还有full join等其他类型，也是同样的道理，这种sql如何定位呢？

浏览量17