我正在尝试优化运行大约需要30分钟的查询。我想要做的是利用分区修剪来最小化搜索的行。分区表的变量范围是来自不同表的变量。似乎mysql正在搜索所有分区。
以下是表格(切除的部分是无效的): (顺便说一下,我确实知道int(x)没有改变int的大小。我在知道更好之前设计了那个表,并且没有修复它)
expectedEvent | CREATE TABLE `expectedevent` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`eventId` int(5) NOT NULL,
`unitGroup_id` int(6) NOT NULL,
`minOccur` int(9) NOT NULL,
`periodInDays` int(4) NOT NULL,
PRIMARY KEY (`id`),
KEY `eventId` (`eventId`),
KEY `unitGroup_id` (`unitGroup_id`),
CONSTRAINT `expectedevent_ibfk_1` FOREIGN KEY (`unitGroup_id`) REFERENCES `unitgroup` (`id`)
event_message | CREATE TABLE `event_message` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`unitId` varchar(15) NOT NULL,
`eventId` smallint(6) NOT NULL,
`eventName` varchar(50) NOT NULL,
`gpsDateTime` datetime NOT NULL,
`weekInfo` tinyint(4) NOT NULL,
`odometer` int(11) NOT NULL,
...
KEY `id` (`id`),
KEY `unitId` (`unitId`,`eventId`),
KEY `eventId` (`eventId`)
...
!50100 PARTITION BY RANGE (weekInfo)
ARTITION p0 VALUES LESS THAN (1) ENGINE = InnoDB,
ARTITION p1 VALUES LESS THAN (2) ENGINE = InnoDB,
unitGroup | CREATE TABLE `unitgroup` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(60) DEFAULT NULL,
unitGroup_devices | CREATE TABLE `unitg
`id` int(11) NOT NULL AUTO_INCREMENT,
`unitGroup_id` int(11) NOT NULL,
`scopeDevice_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `unitGroup_id` (`unitGroup_id`),
KEY `scopeDevice_id` (`scopeDevice_id`)
...
这个查询需要将近30分钟(选择,没有解释):
explain partitions
select ee.eventId, scopeDevice_id as scopeDevId, sd.unitId as unitId, count(em.id) as evtCount, minOccur, periodInDays
from expectedEvent ee left join unitGroup ug on ee.unitGroup_id=ug.id
left join unitGroup_devices ugd on ug.id=ugd.unitGroup_id
left join scopeDevice sd on ugd.scopeDevice_id=sd.id
left join event_message em on sd.unitId=em.unitId and em.eventId=ee.eventId
where gpsDateTime>=DATE_SUB(DATE(now()),INTERVAL periodInDays DAY)
and weekInfo>=WEEKOFYEAR(DATE_SUB(DATE(now()),INTERVAL periodInDays DAY))
and weekInfo <=WEEKOFYEAR(DATE(now()))
group by ee.id, ugd.scopeDevice_id;
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-----------------------------------------------------------------------------------------------------------------------------------------------------------+--------+-----------------------------+--------------+---------+------------------------------------------------+------+---------------------------------+
| 1 | SIMPLE | ee | NULL | ALL | eventId,unitGroup_id | NULL | NULL | NULL | 1 | Using temporary; Using filesort |
| 1 | SIMPLE | ug | NULL | eq_ref | PRIMARY | PRIMARY | 4 | navsat_scope.ee.unitGroup_id | 1 | Using where; Using index |
| 1 | SIMPLE | ugd | NULL | ref | unitGroup_id,scopeDevice_id | unitGroup_id | 4 | navsat_scope.ee.unitGroup_id | 11 | Using where |
| 1 | SIMPLE | sd | NULL | eq_ref | PRIMARY,unitId | PRIMARY | 4 | navsat_scope.ugd.scopeDevice_id | 1 | Using where |
| 1 | SIMPLE | em | p0,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20,p21,p22,p23,p24,p25,p26,p27,p28,p29,p30,p31,p32,p33,p34,p35,p36,p37,p38,p39,p40 | ref | unitId,eventId | unitId | 19 | navsat_scope.sd.unitId,navsat_scope.ee.eventId | 682 | Using where |
+----+-------------+-------+-----------------------------------------------------------------------------------------------------------------------------------------------------------+--------+-----------------------------+--------------+---------+------------------------------------------------+------+---------------------------------+
expectedEvent中只有一个条目,因此它基本上等同于执行以下操作。 此查询大约需要3分钟(选择,没有解释):
select ee.eventId, scopeDevice_id as scopeDevId, sd.unitId as unitId, count(em.id) as evtCount, minOccur, periodInDays
from expectedEvent ee left join unitGroup ug on ee.unitGroup_id=ug.id
left join unitGroup_devices ugd on ug.id=ugd.unitGroup_id
left join scopeDevice sd on ugd.scopeDevice_id=sd.id
left join event_message em on sd.unitId=em.unitId and em.eventId=ee.eventId
where gpsDateTime>="2012-09-29"
and weekInfo>=WEEKOFYEAR("2012-09-29")
and weekInfo <=WEEKOFYEAR("2012-10-01")
group by ee.id, ugd.scopeDevice_id;
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------------+--------+-----------------------------+--------------+---------+------------------------------------------------+------+---------------------------------+
| 1 | SIMPLE | ee | NULL | ALL | eventId,unitGroup_id | NULL | NULL | NULL | 1 | Using temporary; Using filesort |
| 1 | SIMPLE | ug | NULL | eq_ref | PRIMARY | PRIMARY | 4 | navsat_scope.ee.unitGroup_id | 1 | Using where; Using index |
| 1 | SIMPLE | ugd | NULL | ref | unitGroup_id,scopeDevice_id | unitGroup_id | 4 | navsat_scope.ee.unitGroup_id | 11 | Using where |
| 1 | SIMPLE | sd | NULL | eq_ref | PRIMARY,unitId | PRIMARY | 4 | navsat_scope.ugd.scopeDevice_id | 1 | Using where |
| 1 | SIMPLE | em | p39,p40 | ref | unitId,eventId | unitId | 19 | navsat_scope.sd.unitId,navsat_scope.ee.eventId | 682 | Using where |
+----+-------------+-------+------------+--------+-----------------------------+--------------+---------+------------------------------------------------+------+---------------------------------+
我对解决方法的想法是首先在我的C#app中读取expectedEvent表,然后使用实际日期而不是变量构建查询。
但我更愿意在MySQL中完成所有这些操作。如何优化查询? ExpectedEvent最终将包含许多行。
谢谢!
答案 0 :(得分:2)
MySQL在准备SQL语句时(当MySQL为语句生成执行计划时)执行“分区修剪”。为了将“分区修剪”作为计划的一部分,MySQL需要在分析时已知的值;对于在分析时未知的值,未实现分区修剪。
当MySQL执行SQL语句时,MySQL首先准备执行计划,然后执行该计划。 “分区修剪”是在准备阶段决定的执行计划的细节。 (这解释了为什么你在谓词中使用常量的语句显示分区修剪,但你的引用列的语句没有显示任何修剪。)
答案 1 :(得分:1)
您需要使用WHERE子句中的实际值,而不是通过JOIN获取值。想一想,当MySQL为查询准备执行计划时,它不知道表中的值是gpsDateTime
的值。因此,它无法知道它只需要查询中的某些分区来获取所需的数据。
在你的情况下,事先用查询获取过滤器中使用的日期值要快得多,然后在制作select查询时使用实际值,就像你在第二个例子中所做的那样。