MySQL игнорира Force Index за заявка за изтриване, но не и за еквивалентна заявка за избор

Изключително съм объркан и разочарован тук -

Имам маса (table1), която е огромна.

Опитвам се да направя заявка за изтриване въз основа на друга таблица. Оптимизаторът на заявки не използва подходящия индекс, така че се опитвам да го принудя

delete table1 
FROM table1
FORCE INDEX FOR JOIN (index1)  
inner JOIN table2  
where
table1.field1=table2.field1
and
table1.field2=table2.field2
and
date(table1.startdatetime)=table2.reportdate;

Еквивалентният избор изглежда по следния начин:

SELECT * 
FROM table1
FORCE INDEX FOR JOIN (index1)  
inner JOIN table2  
where
table1.field1=table2.field1
and
table1.field2=table2.field2
and
date(table1.startdatetime)=table2.reportdate;

Това, което не разбирам е, че заявката за изтриване не използва индекса, но заявката за избор го прави

„Обяснението“ от избраното е:

1   SIMPLE  table2 index    idx1    idx1    55      1456    Using where; Using index
1   SIMPLE  table1 ref  index1 index1 51    table2.field1,table2.field2 508 **Using index condition**

Но обяснението за изтриването е следното:

# id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra
1, SIMPLE, table2, index, idx1, idx1, 55, , 1456, Using where; Using index
1, SIMPLE, table1, ref, index1, index1, 51, table2.field1,table2.field2, 508, Using where

Защо командата select има Using index условие, а еквивалентното delete има using where?

Как мога да принудя изтриването да използва и индекса?

Благодаря ти!


person Stumbling Through Data Science    schedule 25.01.2019    source източник
comment
Често е по-бързо да създадете нова таблица, запазвайки само желаните данни, след това да премахнете изходната таблица и след това да преименувате новата таблица   -  person Strawberry    schedule 26.01.2019
comment
Това не е много практично, когато въпросната таблица е 1TB и изтритата сума е по-малко от 1% от това.. Благодаря за идеята   -  person Stumbling Through Data Science    schedule 26.01.2019
comment
Е, практично е, ако е по-бързо   -  person Strawberry    schedule 26.01.2019
comment
Трудно е да ви помогна без SHOW CREATE TABLE за двете таблици и версията на MySQL, която използвате.   -  person Rick James    schedule 27.01.2019


Отговори (2)


Ако разбрах проблема правилно, щях просто да създам трансформация на перспектива с обърнато y и с координати, съответстващи на размера на екрана, като (D с gl3n): mat4.orthographic(0, width, height, 0, -1, 1 ). OpenGL математическите библиотеки използват същия принцип като напр. opengl.org/sdk/docs/man2/xhtml/glOrtho.xml - редактиране: пиша този отговор, в случай че ви помогне...
person Uueerdo    schedule 25.01.2019
comment
Благодаря... какъв забележително глупав и случаен начин за прилагане на функционалност. - person Stumbling Through Data Science; 26.01.2019
comment
По-новите версии направиха оптимизатора общ за SELECT и DML операторите. - person Rick James; 27.01.2019

Може да има неефективност

date(table1.startdatetime)=table2.reportdate

Не може да се използва индекс на startdatetime, защото се крие в извикване на функция. Обикновено по-добре е да направите:

    table1.startdatetime >= table2.reportdate
AND table1.startdatetime  < table2.reportdate + INTERVAL 1 DAY
person Rick James    schedule 27.01.2019