2003-01-06 00:48:59 +01:00
drop table if exists t1,t2;
2001-09-28 07:05:54 +02:00
create table t1 (a int auto_increment , primary key (a));
insert into t1 values (NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL);
update t1 set a=a+10 where a > 34;
update t1 set a=a+100 where a > 0;
update t1 set a=a+100 where a=1 and a=2;
update t1 set a=b+100 where a=1 and a=2;
2003-06-04 17:28:51 +02:00
ERROR 42S22: Unknown column 'b' in 'field list'
2001-09-28 07:05:54 +02:00
update t1 set a=b+100 where c=1 and a=2;
2003-06-04 17:28:51 +02:00
ERROR 42S22: Unknown column 'c' in 'where clause'
2001-09-28 07:05:54 +02:00
update t1 set d=a+100 where a=1;
2003-06-04 17:28:51 +02:00
ERROR 42S22: Unknown column 'd' in 'field list'
2001-09-28 07:05:54 +02:00
select * from t1;
2001-02-17 23:03:37 +01:00
a
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
145
146
2001-09-28 07:05:54 +02:00
drop table t1;
CREATE TABLE t1
(
place_id int (10) unsigned NOT NULL,
shows int(10) unsigned DEFAULT '0' NOT NULL,
ishows int(10) unsigned DEFAULT '0' NOT NULL,
ushows int(10) unsigned DEFAULT '0' NOT NULL,
clicks int(10) unsigned DEFAULT '0' NOT NULL,
iclicks int(10) unsigned DEFAULT '0' NOT NULL,
uclicks int(10) unsigned DEFAULT '0' NOT NULL,
bug#10466: Datatype "timestamp" displays "YYYYMMDDHHMMSS" irrespective of display sizes.
- Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width.
- Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.
mysql-test/include/ps_create.inc:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/alias.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_date_add.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_str.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_time.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/group_by.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/innodb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_1general.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_2myisam.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_3innodb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_4heap.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_5merge.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_6bdb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_7ndb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/select.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/type_timestamp.result:
When display width is used for a TIMESTAMP column a warning is printed that the display width will be ignored.
mysql-test/r/update.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/alias.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_date_add.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_str.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_time.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/group_by.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/innodb.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps_4heap.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps_5merge.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/select.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/update.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
sql/share/errmsg.txt:
Correct swedish error message
sql/sql_parse.cc:
Print warning if datatype is TIMESTAMP and display width is used.
2005-06-20 12:09:00 +02:00
ts timestamp,
2001-09-28 07:05:54 +02:00
PRIMARY KEY (place_id,ts)
);
INSERT INTO t1 (place_id,shows,ishows,ushows,clicks,iclicks,uclicks,ts)
VALUES (1,0,0,0,0,0,0,20000928174434);
UPDATE t1 SET shows=shows+1,ishows=ishows+1,ushows=ushows+1,clicks=clicks+1,iclicks=iclicks+1,uclicks=uclicks+1 WHERE place_id=1 AND ts>="2000-09-28 00:00:00";
select place_id,shows from t1;
2000-12-28 02:56:38 +01:00
place_id shows
1 1
2001-09-28 07:05:54 +02:00
drop table t1;
CREATE TABLE t1 (
lfdnr int(10) unsigned NOT NULL default '0',
ticket int(10) unsigned NOT NULL default '0',
client varchar(255) NOT NULL default '',
replyto varchar(255) NOT NULL default '',
subject varchar(100) NOT NULL default '',
timestamp int(10) unsigned NOT NULL default '0',
bug#10466: Datatype "timestamp" displays "YYYYMMDDHHMMSS" irrespective of display sizes.
- Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width.
- Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.
mysql-test/include/ps_create.inc:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/alias.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_date_add.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_str.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_time.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/group_by.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/innodb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_1general.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_2myisam.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_3innodb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_4heap.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_5merge.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_6bdb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_7ndb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/select.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/type_timestamp.result:
When display width is used for a TIMESTAMP column a warning is printed that the display width will be ignored.
mysql-test/r/update.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/alias.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_date_add.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_str.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_time.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/group_by.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/innodb.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps_4heap.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps_5merge.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/select.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/update.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
sql/share/errmsg.txt:
Correct swedish error message
sql/sql_parse.cc:
Print warning if datatype is TIMESTAMP and display width is used.
2005-06-20 12:09:00 +02:00
tstamp timestamp NOT NULL,
2001-09-28 07:05:54 +02:00
status int(3) NOT NULL default '0',
type varchar(15) NOT NULL default '',
assignment int(10) unsigned NOT NULL default '0',
fupcount int(4) unsigned NOT NULL default '0',
parent int(10) unsigned NOT NULL default '0',
activity int(10) unsigned NOT NULL default '0',
priority tinyint(1) unsigned NOT NULL default '1',
cc varchar(255) NOT NULL default '',
bcc varchar(255) NOT NULL default '',
body text NOT NULL,
comment text,
header text,
PRIMARY KEY (lfdnr),
KEY k1 (timestamp),
KEY k2 (type),
KEY k3 (parent),
KEY k4 (assignment),
KEY ticket (ticket)
2003-12-10 05:31:42 +01:00
) ENGINE=MyISAM;
2001-09-28 07:05:54 +02:00
INSERT INTO t1 VALUES (773,773,'','','',980257344,20010318180652,0,'Open',10,0,0,0,1,'','','','','');
2003-03-22 19:34:20 +01:00
alter table t1 change lfdnr lfdnr int(10) unsigned not null auto_increment;
2001-09-28 07:05:54 +02:00
update t1 set status=1 where type='Open';
select status from t1;
2001-03-23 19:38:42 +01:00
status
1
2001-09-28 07:05:54 +02:00
drop table t1;
2003-04-23 20:52:16 +02:00
create table t1 (a int not null, b int not null, key (a));
insert into t1 values (1,1),(1,2),(1,3),(3,1),(3,2),(3,3),(3,1),(3,2),(3,3),(2,1),(2,2),(2,3);
SET @tmp=0;
update t1 set b=(@tmp:=@tmp+1) order by a;
update t1 set b=99 where a=1 order by b asc limit 1;
select * from t1 order by a,b;
2001-11-08 21:30:27 +01:00
a b
1 2
2003-04-23 20:52:16 +02:00
1 3
1 99
2 4
2 5
2 6
3 7
3 8
3 9
3 10
3 11
3 12
update t1 set b=100 where a=1 order by b desc limit 2;
update t1 set a=a+10+b where a=1 order by b;
select * from t1 order by a,b;
a b
2 4
2 5
2 6
3 7
3 8
3 9
3 10
3 11
3 12
13 2
111 100
111 100
2003-05-21 20:39:58 +02:00
create table t2 (a int not null, b int not null);
insert into t2 values (1,1),(1,2),(1,3);
update t1 set b=(select distinct 1 from (select * from t2) a);
drop table t1,t2;
2003-05-13 19:07:43 +02:00
CREATE TABLE t1 (
`id_param` smallint(3) unsigned NOT NULL default '0',
`nom_option` char(40) NOT NULL default '',
`valid` tinyint(1) NOT NULL default '0',
KEY `id_param` (`id_param`,`nom_option`)
2003-12-10 05:31:42 +01:00
) ENGINE=MyISAM;
2003-05-13 19:07:43 +02:00
INSERT INTO t1 (id_param,nom_option,valid) VALUES (185,'600x1200',1);
UPDATE t1 SET nom_option='test' WHERE id_param=185 AND nom_option='600x1200' AND valid=1 LIMIT 1;
select * from t1;
id_param nom_option valid
185 test 1
drop table t1;
2003-05-14 00:27:26 +02:00
create table t1 (F1 VARCHAR(30), F2 VARCHAR(30), F3 VARCHAR(30), cnt int, groupid int, KEY groupid_index (groupid));
insert into t1 (F1,F2,F3,cnt,groupid) values ('0','0','0',1,6),
('0','1','2',1,5), ('0','2','0',1,3), ('1','0','1',1,2),
('1','2','1',1,1), ('1','2','2',1,1), ('2','0','1',2,4),
('2','2','0',1,7);
2004-01-20 18:16:18 +01:00
delete from m1 using t1 m1,t1 m2 where m1.groupid=m2.groupid and (m1.cnt < m2.cnt or m1.cnt=m2.cnt and m1.F3>m2.F3);
2003-05-14 00:27:26 +02:00
select * from t1;
F1 F2 F3 cnt groupid
0 0 0 1 6
0 1 2 1 5
0 2 0 1 3
1 0 1 1 2
1 2 1 1 1
2 0 1 2 4
2 2 0 1 7
drop table t1;
2004-09-17 13:07:59 +02:00
CREATE TABLE t1 (
`colA` int(10) unsigned NOT NULL auto_increment,
`colB` int(11) NOT NULL default '0',
PRIMARY KEY (`colA`)
);
INSERT INTO t1 VALUES (4433,5424);
CREATE TABLE t2 (
`colC` int(10) unsigned NOT NULL default '0',
`colA` int(10) unsigned NOT NULL default '0',
`colD` int(10) unsigned NOT NULL default '0',
`colE` int(10) unsigned NOT NULL default '0',
`colF` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`colC`,`colA`,`colD`,`colE`)
);
INSERT INTO t2 VALUES (3,4433,10005,495,500);
INSERT INTO t2 VALUES (3,4433,10005,496,500);
INSERT INTO t2 VALUES (3,4433,10009,494,500);
INSERT INTO t2 VALUES (3,4433,10011,494,500);
INSERT INTO t2 VALUES (3,4433,10005,497,500);
INSERT INTO t2 VALUES (3,4433,10013,489,500);
INSERT INTO t2 VALUES (3,4433,10005,494,500);
INSERT INTO t2 VALUES (3,4433,10005,493,500);
INSERT INTO t2 VALUES (3,4433,10005,492,500);
UPDATE IGNORE t2,t1 set t2.colE = t2.colE + 1,colF=0 WHERE t1.colA = t2.colA AND (t1.colB & 4096) > 0 AND (colE + 1) < colF;
SELECT * FROM t2;
colC colA colD colE colF
3 4433 10005 495 500
3 4433 10005 496 500
3 4433 10009 495 0
3 4433 10011 495 0
3 4433 10005 498 0
3 4433 10013 490 0
3 4433 10005 494 500
3 4433 10005 493 500
3 4433 10005 492 500
DROP TABLE t1;
DROP TABLE t2;
2004-12-16 17:46:38 +01:00
create table t1 (c1 int, c2 char(6), c3 int);
create table t2 (c1 int, c2 char(6));
insert into t1 values (1, "t1c2-1", 10), (2, "t1c2-2", 20);
update t1 left join t2 on t1.c1 = t2.c1 set t2.c2 = "t2c2-1";
update t1 left join t2 on t1.c1 = t2.c1 set t2.c2 = "t2c2-1" where t1.c3 = 10;
drop table t1, t2;
2005-02-03 22:11:12 +01:00
create table t1 (id int not null auto_increment primary key, id_str varchar(32));
insert into t1 (id_str) values ("test");
update t1 set id_str = concat(id_str, id) where id = last_insert_id();
select * from t1;
id id_str
1 test1
drop table t1;
2005-03-17 07:24:50 +01:00
create table t1 (a int, b char(255), key(a, b(20)));
insert into t1 values (0, '1');
update t1 set b = b + 1 where a = 0;
select * from t1;
a b
0 2
drop table t1;
2005-04-18 03:21:44 +02:00
create table t1 (a int, b varchar(10), key b(b(5))) engine=myisam;
create table t2 (a int, b varchar(10)) engine=myisam;
insert into t1 values ( 1, 'abcd1e');
insert into t1 values ( 2, 'abcd2e');
insert into t2 values ( 1, 'abcd1e');
insert into t2 values ( 2, 'abcd2e');
analyze table t1,t2;
Table Op Msg_type Msg_text
test.t1 analyze status OK
test.t2 analyze status OK
update t1, t2 set t1.a = t2.a where t2.b = t1.b;
show warnings;
Level Code Message
drop table t1, t2;
2005-07-16 03:31:16 +02:00
create table t1(f1 int, f2 int);
create table t2(f3 int, f4 int);
create index idx on t2(f3);
insert into t1 values(1,0),(2,0);
insert into t2 values(1,1),(2,2);
UPDATE t1 SET t1.f2=(SELECT MAX(t2.f4) FROM t2 WHERE t2.f3=t1.f1);
select * from t1;
f1 f2
1 1
2 2
drop table t1,t2;
2005-09-21 23:38:39 +02:00
create table t1(f1 int);
select DATABASE();
DATABASE()
test
update t1 set f1=1 where count(*)=1;
ERROR HY000: Invalid use of group function
select DATABASE();
DATABASE()
test
delete from t1 where count(*)=1;
ERROR HY000: Invalid use of group function
drop table t1;
2005-10-25 01:27:40 +02:00
create table t1 ( a int, b int default 0, index (a) );
insert into t1 (a) values (0),(0),(0),(0),(0),(0),(0),(0);
2005-09-30 13:21:37 +02:00
flush status;
select a from t1 order by a limit 1;
a
0
show status like 'handler_read%';
Variable_name Value
Handler_read_first 1
Handler_read_key 0
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2005-09-30 13:21:37 +02:00
Handler_read_next 0
Handler_read_prev 0
Handler_read_rnd 0
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 0
2005-09-30 13:21:37 +02:00
Handler_read_rnd_next 0
flush status;
2005-10-25 01:27:40 +02:00
update t1 set a=9999 order by a limit 1;
update t1 set b=9999 order by a limit 1;
2005-09-30 13:21:37 +02:00
show status like 'handler_read%';
Variable_name Value
Handler_read_first 1
Handler_read_key 0
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2005-09-30 13:21:37 +02:00
Handler_read_next 0
Handler_read_prev 0
2005-10-25 01:27:40 +02:00
Handler_read_rnd 2
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 0
2005-10-25 01:27:40 +02:00
Handler_read_rnd_next 9
2005-09-30 13:21:37 +02:00
flush status;
delete from t1 order by a limit 1;
show status like 'handler_read%';
Variable_name Value
Handler_read_first 1
Handler_read_key 0
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2005-09-30 13:21:37 +02:00
Handler_read_next 0
Handler_read_prev 0
Handler_read_rnd 0
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 0
2005-09-30 13:21:37 +02:00
Handler_read_rnd_next 0
flush status;
delete from t1 order by a desc limit 1;
show status like 'handler_read%';
Variable_name Value
Handler_read_first 0
Handler_read_key 0
2010-08-25 21:00:38 +02:00
Handler_read_last 1
2005-09-30 13:21:37 +02:00
Handler_read_next 0
Handler_read_prev 0
Bug #30584: delete with order by and limit clauses does not
use limit efficiently
Bug #36569: UPDATE ... WHERE ... ORDER BY... always does a
filesort even if not required
Also two bugs reported after QA review (before the commit
of bugs above to public trees, no documentation needed):
Bug #53737: Performance regressions after applying patch
for bug 36569
Bug #53742: UPDATEs have no effect after applying patch
for bug 36569
Execution of single-table UPDATE and DELETE statements did not use the
same optimizer as was used in the compilation of SELECT statements.
Instead, it had an optimizer of its own that did not take into account
that you can omit sorting by retrieving rows using an index.
Extra optimization has been added: when applicable, single-table
UPDATE/DELETE statements use an existing index instead of filesort. A
corresponding SELECT query would do the former.
Also handling of the DESC ordering expression has been added when
reverse index scan is applicable.
From now on most single table UPDATE and DELETE statements show the
same disk access patterns as the corresponding SELECT query. We verify
this by comparing the result of SHOW STATUS LIKE 'Sort%
Currently the get_index_for_order function
a) checks quick select index (if any) for compatibility with the
ORDER expression list or
b) chooses the cheapest available compatible index, but only if
the index scan is cheaper than filesort.
Second way is implemented by the new test_if_cheaper_ordering
function (extracted part the test_if_skip_sort_order()).
mysql-test/r/log_state.result:
Updated result for optimized query, bug #36569.
mysql-test/r/single_delete_update.result:
Test case for bug #30584, bug #36569 and bug #53742.
mysql-test/r/update.result:
Updated result for optimized query, bug #30584.
Note:
"Handler_read_last 1" omitted, see bug 52312:
lost Handler_read_last status variable.
mysql-test/t/single_delete_update.test:
Test case for bug #30584, bug #36569 and bug #53742.
sql/opt_range.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* get_index_for_order() has been rewritten entirely and moved
to sql_select.cc
New QUICK_RANGE_SELECT::make_reverse method has been added.
sql/opt_range.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* get_index_for_order() has been rewritten entirely and moved
to sql_select.cc
New functions:
* QUICK_SELECT_I::make_reverse()
* SQL_SELECT::set_quick()
sql/records.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* init_read_record_idx() has been modified to allow reverse index scan
New functions:
* rr_index_last()
* rr_index_desc()
sql/records.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
init_read_record_idx() has been modified to allow reverse index scan
sql/sql_delete.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
mysql_delete: an optimization has been added to skip
unnecessary sorting with ORDER BY clause where select
result ordering is acceptable.
sql/sql_select.cc:
Bug #30584, bug #36569, bug #53737, bug #53742:
UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort
even if not required
The const_expression_in_where function has been modified
to accept both Item and Field pointers.
New functions:
* get_index_for_order()
* test_if_cheaper_ordering() has been extracted from
test_if_skip_sort_order() to share with get_index_for_order()
* simple_remove_const()
sql/sql_select.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* test_if_cheaper_ordering()
* simple_remove_const()
* get_index_for_order()
sql/sql_update.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
mysql_update: an optimization has been added to skip
unnecessary sorting with ORDER BY clause where a select
result ordering is acceptable.
sql/table.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* TABLE::update_const_key_parts()
* is_simple_order()
sql/table.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* TABLE::update_const_key_parts()
* is_simple_order()
2010-06-22 22:32:29 +02:00
Handler_read_rnd 0
2012-02-15 18:08:08 +01:00
Handler_read_rnd_deleted 0
Bug #30584: delete with order by and limit clauses does not
use limit efficiently
Bug #36569: UPDATE ... WHERE ... ORDER BY... always does a
filesort even if not required
Also two bugs reported after QA review (before the commit
of bugs above to public trees, no documentation needed):
Bug #53737: Performance regressions after applying patch
for bug 36569
Bug #53742: UPDATEs have no effect after applying patch
for bug 36569
Execution of single-table UPDATE and DELETE statements did not use the
same optimizer as was used in the compilation of SELECT statements.
Instead, it had an optimizer of its own that did not take into account
that you can omit sorting by retrieving rows using an index.
Extra optimization has been added: when applicable, single-table
UPDATE/DELETE statements use an existing index instead of filesort. A
corresponding SELECT query would do the former.
Also handling of the DESC ordering expression has been added when
reverse index scan is applicable.
From now on most single table UPDATE and DELETE statements show the
same disk access patterns as the corresponding SELECT query. We verify
this by comparing the result of SHOW STATUS LIKE 'Sort%
Currently the get_index_for_order function
a) checks quick select index (if any) for compatibility with the
ORDER expression list or
b) chooses the cheapest available compatible index, but only if
the index scan is cheaper than filesort.
Second way is implemented by the new test_if_cheaper_ordering
function (extracted part the test_if_skip_sort_order()).
mysql-test/r/log_state.result:
Updated result for optimized query, bug #36569.
mysql-test/r/single_delete_update.result:
Test case for bug #30584, bug #36569 and bug #53742.
mysql-test/r/update.result:
Updated result for optimized query, bug #30584.
Note:
"Handler_read_last 1" omitted, see bug 52312:
lost Handler_read_last status variable.
mysql-test/t/single_delete_update.test:
Test case for bug #30584, bug #36569 and bug #53742.
sql/opt_range.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* get_index_for_order() has been rewritten entirely and moved
to sql_select.cc
New QUICK_RANGE_SELECT::make_reverse method has been added.
sql/opt_range.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* get_index_for_order() has been rewritten entirely and moved
to sql_select.cc
New functions:
* QUICK_SELECT_I::make_reverse()
* SQL_SELECT::set_quick()
sql/records.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* init_read_record_idx() has been modified to allow reverse index scan
New functions:
* rr_index_last()
* rr_index_desc()
sql/records.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
init_read_record_idx() has been modified to allow reverse index scan
sql/sql_delete.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
mysql_delete: an optimization has been added to skip
unnecessary sorting with ORDER BY clause where select
result ordering is acceptable.
sql/sql_select.cc:
Bug #30584, bug #36569, bug #53737, bug #53742:
UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort
even if not required
The const_expression_in_where function has been modified
to accept both Item and Field pointers.
New functions:
* get_index_for_order()
* test_if_cheaper_ordering() has been extracted from
test_if_skip_sort_order() to share with get_index_for_order()
* simple_remove_const()
sql/sql_select.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* test_if_cheaper_ordering()
* simple_remove_const()
* get_index_for_order()
sql/sql_update.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
mysql_update: an optimization has been added to skip
unnecessary sorting with ORDER BY clause where a select
result ordering is acceptable.
sql/table.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* TABLE::update_const_key_parts()
* is_simple_order()
sql/table.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* TABLE::update_const_key_parts()
* is_simple_order()
2010-06-22 22:32:29 +02:00
Handler_read_rnd_next 0
2005-09-30 13:21:37 +02:00
alter table t1 disable keys;
flush status;
delete from t1 order by a limit 1;
show status like 'handler_read%';
Variable_name Value
Handler_read_first 0
Handler_read_key 0
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2005-09-30 13:21:37 +02:00
Handler_read_next 0
Handler_read_prev 0
Handler_read_rnd 1
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 2
Handler_read_rnd_next 7
2005-10-25 01:27:40 +02:00
select * from t1;
a b
0 0
0 0
0 0
0 0
0 0
update t1 set a=a+10,b=1 order by a limit 3;
update t1 set a=a+11,b=2 order by a limit 3;
update t1 set a=a+12,b=3 order by a limit 3;
select * from t1 order by a;
a b
11 2
21 2
22 3
22 3
23 3
2005-09-30 13:21:37 +02:00
drop table t1;
2005-10-27 23:24:11 +02:00
create table t1 (f1 date not null);
insert into t1 values('2000-01-01'),('0000-00-00');
update t1 set f1='2002-02-02' where f1 is null;
select * from t1;
f1
2000-01-01
2002-02-02
drop table t1;
2005-12-01 21:22:20 +01:00
create table t1 (f1 int);
create table t2 (f2 int);
insert into t1 values(1),(2);
insert into t2 values(1),(1);
update t1,t2 set f1=3,f2=3 where f1=f2 and f1=1;
affected rows: 3
info: Rows matched: 3 Changed: 3 Warnings: 0
update t2 set f2=1;
update t1 set f1=1 where f1=3;
update t2,t1 set f1=3,f2=3 where f1=f2 and f1=1;
affected rows: 3
info: Rows matched: 3 Changed: 3 Warnings: 0
drop table t1,t2;
2006-01-25 21:25:23 +01:00
create table t1 (a int);
insert into t1 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
create table t2 (a int, filler1 char(200), filler2 char(200), key(a));
insert into t2 select A.a + 10*B.a, 'filler','filler' from t1 A, t1 B;
flush status;
update t2 set a=3 where a=2;
show status like 'handler_read%';
Variable_name Value
Handler_read_first 0
Handler_read_key 1
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2006-01-25 21:25:23 +01:00
Handler_read_next 1
Handler_read_prev 0
Handler_read_rnd 1
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 0
2006-01-25 21:25:23 +01:00
Handler_read_rnd_next 0
drop table t1, t2;
2006-01-23 19:51:32 +01:00
create table t1(f1 int, `*f2` int);
insert into t1 values (1,1);
update t1 set `*f2`=1;
drop table t1;
2007-03-03 22:47:42 +01:00
create table t1(f1 int);
update t1 set f2=1 order by f2;
ERROR 42S22: Unknown column 'f2' in 'order clause'
drop table t1;
2007-02-03 00:22:10 +01:00
CREATE TABLE t1 (
request_id int unsigned NOT NULL auto_increment,
user_id varchar(12) default NULL,
time_stamp datetime NOT NULL default '0000-00-00 00:00:00',
ip_address varchar(15) default NULL,
PRIMARY KEY (request_id),
KEY user_id_2 (user_id,time_stamp)
);
INSERT INTO t1 (user_id) VALUES ('user1');
INSERT INTO t1(user_id) SELECT user_id FROM t1;
INSERT INTO t1(user_id) SELECT user_id FROM t1;
INSERT INTO t1(user_id) SELECT user_id FROM t1;
INSERT INTO t1(user_id) SELECT user_id FROM t1;
INSERT INTO t1(user_id) SELECT user_id FROM t1;
INSERT INTO t1(user_id) SELECT user_id FROM t1;
INSERT INTO t1(user_id) SELECT user_id FROM t1;
INSERT INTO t1(user_id) SELECT user_id FROM t1;
flush status;
SELECT user_id FROM t1 WHERE request_id=9999999999999;
user_id
show status like '%Handler_read%';
Variable_name Value
Handler_read_first 0
Handler_read_key 1
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2007-02-03 00:22:10 +01:00
Handler_read_next 0
Handler_read_prev 0
Handler_read_rnd 0
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 0
2007-02-03 00:22:10 +01:00
Handler_read_rnd_next 0
SELECT user_id FROM t1 WHERE request_id=999999999999999999999999999999;
user_id
show status like '%Handler_read%';
Variable_name Value
Handler_read_first 0
Handler_read_key 2
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2007-02-03 00:22:10 +01:00
Handler_read_next 0
Handler_read_prev 0
Handler_read_rnd 0
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 0
2007-02-13 22:15:23 +01:00
Handler_read_rnd_next 0
2007-02-03 00:22:10 +01:00
UPDATE t1 SET user_id=null WHERE request_id=9999999999999;
show status like '%Handler_read%';
Variable_name Value
Handler_read_first 0
Handler_read_key 3
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2007-02-03 00:22:10 +01:00
Handler_read_next 0
Handler_read_prev 0
Handler_read_rnd 0
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 0
2007-02-13 22:15:23 +01:00
Handler_read_rnd_next 0
2007-02-03 00:22:10 +01:00
UPDATE t1 SET user_id=null WHERE request_id=999999999999999999999999999999;
show status like '%Handler_read%';
Variable_name Value
Handler_read_first 0
Handler_read_key 3
2010-08-25 21:00:38 +02:00
Handler_read_last 0
2007-02-03 00:22:10 +01:00
Handler_read_next 0
Handler_read_prev 0
Handler_read_rnd 0
2012-01-18 11:53:50 +01:00
Handler_read_rnd_deleted 0
2007-02-26 16:49:24 +01:00
Handler_read_rnd_next 0
2007-02-03 00:22:10 +01:00
DROP TABLE t1;
Bug #24010: INSERT INTO ... SELECT fails on unique constraint with data
it doesn't select.
This bug was fixed along with bug #16861: User defined variable can
have a wrong value if a tmp table was used.
There the fix consisted of Item_func_set_user_var overloading the method
Item::save_in_field. Consider the query from the test case:
INSERT INTO foo( bar, baz )
SELECT
bar,
@newBaz := 1 + baz
FROM
foo
WHERE
quux <= 0.1;
Here the assignment expression '@newBaz := 1 + baz' is represented by an
Item_func_set_user_var. Its member method save_in_field, which writes the
value of this assignment into the result field, writes the val_xxx() value,
which is not updated at this point. In the fix introduced by the patch,
the save_in_field method reads the actual variable value instead.
See also comment for
ChangeSet@1.2368.1.3, 2007-01-09 23:24:56+03:00, evgen@moonbone.local +4 -0
and comment for
Item_func_set_user_var::save_in_field (item_func.cc)
mysql-test/r/update.result:
BUG#24010
The correct, and expected, result
mysql-test/t/update.test:
BUG#24010
The test case for this bug. When the bug is active, the INSERT ... SELECT
statement will try to insert the values <1, 2> which gives an error
2007-02-22 14:11:01 +01:00
CREATE TABLE t1 (
a INT(11),
quux decimal( 31, 30 ),
UNIQUE KEY bar (a),
KEY quux (quux)
);
INSERT INTO
t1 ( a, quux )
VALUES
( 1, 1 ),
( 2, 0.1 );
INSERT INTO t1( a )
SELECT @newA := 1 + a FROM t1 WHERE quux <= 0.1;
SELECT * FROM t1;
a quux
1 1.000000000000000000000000000000
2 0.100000000000000000000000000000
3 NULL
2007-02-03 00:22:10 +01:00
DROP TABLE t1;
2007-04-23 16:22:33 +02:00
set tmp_table_size=1024;
create table t1 (id int, a int, key idx(a));
create table t2 (id int unsigned not null auto_increment primary key, a int);
insert into t2(a) values(1),(2),(3),(4),(5),(6),(7),(8);
insert into t2(a) select a from t2;
insert into t2(a) select a from t2;
insert into t2(a) select a from t2;
update t2 set a=id;
insert into t1 select * from t2;
select count(*) from t1 join t2 on (t1.a=t2.a);
count(*)
64
update t1 join t2 on (t1.a=t2.a) set t1.id=t2.id;
affected rows: 0
info: Rows matched: 64 Changed: 0 Warnings: 0
insert into t2(a) select a from t2;
update t2 set a=id;
truncate t1;
insert into t1 select * from t2;
select count(*) from t1 join t2 on (t1.a=t2.a);
count(*)
128
update t1 join t2 on (t1.a=t2.a) set t1.id=t2.id;
affected rows: 0
info: Rows matched: 128 Changed: 0 Warnings: 0
update t1 set a=1;
update t2 set a=1;
select count(*) from t1 join t2 on (t1.a=t2.a);
count(*)
16384
update t1 join t2 on (t1.a=t2.a) set t1.id=t2.id;
affected rows: 127
info: Rows matched: 128 Changed: 127 Warnings: 0
drop table t1,t2;
2008-11-28 17:36:07 +01:00
DROP TABLE IF EXISTS t1;
DROP FUNCTION IF EXISTS f1;
CREATE FUNCTION f1() RETURNS INT RETURN f1();
CREATE TABLE t1 (i INT);
INSERT INTO t1 VALUES (1);
UPDATE t1 SET i = 3 WHERE f1();
ERROR HY000: Recursive stored functions and triggers are not allowed.
UPDATE t1 SET i = f1();
ERROR HY000: Recursive stored functions and triggers are not allowed.
DROP TABLE t1;
DROP FUNCTION f1;
2007-04-23 16:22:33 +02:00
End of 5.0 tests
2009-10-23 15:09:14 +02:00
#
# Bug #47919 assert in open_table during ALTER temporary table
#
CREATE TABLE t1 (f1 INTEGER AUTO_INCREMENT, PRIMARY KEY (f1));
CREATE TEMPORARY TABLE t2 LIKE t1;
INSERT INTO t1 VALUES (1);
INSERT INTO t2 VALUES (1);
ALTER TABLE t2 COMMENT = 'ABC';
UPDATE t2, t1 SET t2.f1 = 2, t1.f1 = 9;
ALTER TABLE t2 COMMENT = 'DEF';
DROP TABLE t1, t2;
2010-03-10 17:10:05 +01:00
#
# Bug#50545: Single table UPDATE IGNORE crashes on join view in
# sql_safe_updates mode.
#
CREATE TABLE t1 ( a INT, KEY( a ) );
INSERT INTO t1 VALUES (0), (1);
CREATE VIEW v1 AS SELECT t11.a, t12.a AS b FROM t1 t11, t1 t12;
SET SESSION sql_safe_updates = 1;
UPDATE IGNORE v1 SET a = 1;
ERROR HY000: You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column
SET SESSION sql_safe_updates = DEFAULT;
DROP TABLE t1;
DROP VIEW v1;
2010-07-19 11:03:52 +02:00
#
# Bug#54734 assert in Diagnostics_area::set_ok_status
#
DROP TABLE IF EXISTS t1, not_exists;
DROP FUNCTION IF EXISTS f1;
DROP VIEW IF EXISTS v1;
CREATE TABLE t1 (PRIMARY KEY(pk)) AS SELECT 1 AS pk;
CREATE FUNCTION f1() RETURNS INTEGER RETURN (SELECT 1 FROM not_exists);
CREATE VIEW v1 AS SELECT pk FROM t1 WHERE f1() = 13;
UPDATE v1 SET pk = 7 WHERE pk > 0;
ERROR HY000: View 'test.v1' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
DROP VIEW v1;
DROP FUNCTION f1;
DROP TABLE t1;
2015-07-16 04:26:39 +02:00
# Bug #21143080: UPDATE ON VARCHAR AND TEXT COLUMNS PRODUCE INCORRECT
# RESULTS
CREATE TABLE t1 (a VARCHAR(50), b TEXT, c CHAR(50)) ENGINE=INNODB;
INSERT INTO t1 (a, b, c) VALUES ('start trail', '', 'even longer string');
UPDATE t1 SET b = a, a = 'inject';
SELECT a, b FROM t1;
a b
inject start trail
UPDATE t1 SET b = c, c = 'inject';
SELECT c, b FROM t1;
c b
inject even longer string
DROP TABLE t1;
2015-10-08 22:54:24 +02:00
#
# MDEV-3948 Assertion `records_are_comparable(table)' fails in compare_record(const TABLE*) on UPDATE with simple AND condition, index_merge+index_merge_intersection, InnoDB
Fix for MDEV-3948, and backport of the following collection of fixes and backports
from MariaDB 10.0.
The bug in mdev-3948 was an instance of the problem fixed by Sergey's patch
in 10.0 - namely that the range optimizer could change table->[read | write]_set,
and not restore it.
revno: 3471
committer: Sergey Petrunya <psergey@askmonty.org>
branch nick: 10.0-serg-fix-imerge
timestamp: Sat 2012-11-03 12:24:36 +0400
message:
# MDEV-3817: Wrong result with index_merge+index_merge_intersection, InnoDB table, join, AND and OR conditions
Reconcile the fixes from:
#
# guilhem.bichot@oracle.com-20110805143029-ywrzuz15uzgontr0
# Fix for BUG#12698916 - "JOIN QUERY GIVES WRONG RESULT AT 2ND EXEC. OR
# AFTER FLUSH TABLES [-INT VS NULL]"
#
# guilhem.bichot@oracle.com-20111209150650-tzx3ldzxe1yfwji6
# Fix for BUG#12912171 - ASSERTION FAILED: QUICK->HEAD->READ_SET == SAVE_READ_SET
# and
#
and related fixes from: BUG#1006164, MDEV-376:
Now, ROR-merged QUICK_RANGE_SELECT objects make no assumptions about the values
of table->read_set and table->write_set.
Each QUICK_ROR_SELECT has (and had before) its own column bitmap, but now, all
QUICK_ROR_SELECT's functions that care: reset(), init_ror_merged_scan(), and
get_next() will set table->read_set when invoked and restore it back to what
it was before the call before they return.
This allows to avoid the mess when somebody else modifies table->read_set for
some reason.
2013-01-28 14:13:39 +01:00
#
# Verify that UPDATE does the same number of handler_update
# operations, no matter if there is ORDER BY or not.
#
CREATE TABLE t1 (i INT) ENGINE=INNODB;
INSERT INTO t1 VALUES (10),(11),(12),(13),(14),(15),(16),(17),(18),(19),
(20),(21),(22),(23),(24),(25),(26),(27),(28),(29),
(30),(31),(32),(33),(34),(35);
CREATE TABLE t2 (a CHAR(2), b CHAR(2), c CHAR(2), d CHAR(2),
INDEX idx (a,b(1),c)) ENGINE=INNODB;
INSERT INTO t2 SELECT i, i, i, i FROM t1;
FLUSH STATUS;
START TRANSACTION;
UPDATE t2 SET d = 10 WHERE b = 10 LIMIT 5;
SHOW STATUS LIKE 'HANDLER_UPDATE';
Variable_name Value
Handler_update 1
ROLLBACK;
FLUSH STATUS;
START TRANSACTION;
UPDATE t2 SET d = 10 WHERE b = 10 ORDER BY a, c LIMIT 5;
SHOW STATUS LIKE 'HANDLER_UPDATE';
Variable_name Value
Handler_update 1
ROLLBACK;
Same test with a different UPDATE.
ALTER TABLE t2 DROP INDEX idx, ADD INDEX idx2 (a, b);
FLUSH STATUS;
START TRANSACTION;
UPDATE t2 SET c = 10 LIMIT 5;
SHOW STATUS LIKE 'HANDLER_UPDATE';
Variable_name Value
Handler_update 5
ROLLBACK;
FLUSH STATUS;
START TRANSACTION;
UPDATE t2 SET c = 10 ORDER BY a, b DESC LIMIT 5;
SHOW STATUS LIKE 'HANDLER_UPDATE';
Variable_name Value
Handler_update 5
ROLLBACK;
DROP TABLE t1, t2;
2015-11-06 17:56:56 +01:00
#
# MDEV-8938: Server Crash on Update with joins
#
CREATE TABLE `t1` (
`name` varchar(255) NOT NULL,
`value` varchar(4095) DEFAULT NULL,
PRIMARY KEY (`name`)
);
UPDATE `t1` SET value = CONCAT("*.",(SELECT `temptable`.`value` FROM (SELECT * FROM `t1` WHERE `name`="consoleproxy.url.domain") AS `temptable` WHERE `temptable`.`name`="consoleproxy.url.domain")) WHERE `name`="consoleproxy.url.domain";
drop table t1;
CREATE TABLE `t1` (
`name` varchar(255) NOT NULL,
`value` varchar(4095) DEFAULT NULL,
PRIMARY KEY (`name`)
);
create table t2 (
`name` varchar(255) NOT NULL,
`value` varchar(4095) DEFAULT NULL,
PRIMARY KEY (`name`)
);
UPDATE t1
SET value = (SELECT value FROM t2 WHERE `name`= t1.name)
WHERE value is null ;
drop table t1,t2;
#
#MDEV-8701: Crash on derived query
#
CREATE TABLE t1 (
data_exit_entry_id int(11) NOT NULL,
data_entry_id int(11) NOT NULL,
data_entry_exit_id int(11) NOT NULL,
data_exit_entry_quantity double NOT NULL
) DEFAULT CHARSET=utf8;
CREATE TABLE t2 (
data_entry_id int(11) NOT NULL,
data_entry_cost double NOT NULL,
data_entry_quantity double NOT NULL
) DEFAULT CHARSET=utf8;
create algorithm=temptable view v1 as SELECT data_entry_exit_id, data_exit_entry_quantity, data_entry_cost
FROM t1 INNER JOIN t2 as dt ON dt.data_entry_id = t1.data_entry_id;
UPDATE t2
SET data_entry_cost
= ( ( SELECT SUM(data_exit_entry_quantity * data_entry_cost)
FROM
v1 AS query
WHERE data_entry_exit_id = t2.data_entry_id
)
);
UPDATE t2
SET data_entry_cost
= ( ( SELECT SUM(data_exit_entry_quantity * data_entry_cost)
FROM
( SELECT data_entry_exit_id, data_exit_entry_quantity, data_entry_cost
FROM t1 INNER JOIN t2 as dt ON dt.data_entry_id = t1.data_entry_id) AS query
WHERE data_entry_exit_id = t2.data_entry_id
)
);
drop view v1;
drop table t1, t2;