MySql update egyik gépen nagyon lassú

A két adatbázis ugyan az max a rekordok számában tér el pár tízererrel. 

Explain ahol lassú 20 47 282 rekord:

Server version: 5.7.32-0ubuntu0.18.04.1 (Ubuntu)

+----+-------------+-------+------------+-------+------------------------------+-----------------------+---------+-----------+--------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys                | key                   | key_len | ref       | rows   | filtered | Extra       |
+----+-------------+-------+------------+-------+------------------------------+-----------------------+---------+-----------+--------+----------+-------------+
|  1 | SIMPLE      | BF    | NULL       | index | PRIMARY,IDX_BIZONYLAT_FEJ_01 | IDX_BIZONYLAT_FEJ_01  | 302     | NULL      | 121392 |   100.00 | Using index |
|  1 | SIMPLE      | BTIP  | NULL       | ALL   | NULL                         | NULL                  | NULL    | NULL      |     11 |    10.00 | Using where |
|  1 | UPDATE      | BT    | NULL       | ref   | FK_BIZONYLAT_TETEL_01        | FK_BIZONYLAT_TETEL_01 | 4       | BDM.BF.ID |     16 |   100.00 | NULL        |
+----+-------------+-------+------------+-------+------------------------------+-----------------------+---------+-----------+--------+----------+-------------+

Explain ahol gyors 2 062 984 rekord:

Server version: 5.7.26-0ubuntu0.16.04.1 (Ubuntu)

+----+-------------+-------+------------+-------+------------------------------+-----------------------+---------+--------------------------+--------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys                | key                   | key_len | ref                      | rows   | filtered | Extra       |
+----+-------------+-------+------------+-------+------------------------------+-----------------------+---------+--------------------------+--------+----------+-------------+
|  1 | SIMPLE      | BF    | NULL       | index | PRIMARY,IDX_BIZONYLAT_FEJ_01 | IDX_BIZONYLAT_FEJ_01  | 302     | NULL                     | 122661 |   100.00 | Using index |
|  1 | SIMPLE      | BTIP  | NULL       | ALL   | NULL                         | NULL                  | NULL    | NULL                     |     11 |    10.00 | Using where |
|  1 | UPDATE      | BT    | NULL       | ref   | FK_BIZONYLAT_TETEL_01        | FK_BIZONYLAT_TETEL_01 | 4       | TESZT.BF.ID              |     17 |   100.00 | NULL        |
+----+-------------+-------+------------+-------+------------------------------+-----------------------+---------+--------------------------+--------+----------+-------------+

Mindkettő default telepítés semmi nem lett rajtuk konfigurálva.

Annyi "érdekesség" még, hogy maga a fejlesztői gép is érezhetően lassabb lesz a update kilövése után is és le sem tudott állni szabályosan a rendszer. Reset után elég sok iő kellet, hogy magához térjen. egy select count(*) from bizonylat_tetel 10-20 s-ig tartott a szokásos x ms helyett, és kellett egy OPTIMIZE TABLE (kb negyed óráig futott a >2 mill. rekordos táblán) és utána megint jó lett a lekérdezés sebessége.

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  2
Core(s) per socket:  2
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               60
Model name:          Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz
Stepping:            3
CPU MHz:             973.556
CPU max MHz:         3300,0000
CPU min MHz:         800,0000
BogoMIPS:            5188.17
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            3072K
NUMA node0 CPU(s):   0-3
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts md_clear flush_l1d

InnoDB mindenhol.

Ha "lebutítom" az updatet, hogy csak az az egy tábla szerepel benne aminek az értékét kell updatelni, kiveszem a másik két táblát akkor az pár perc alatt lefut.

Több hasonló updatet kell most írni egy jövőbeni funkció miatt, ami ezt a táblát érint. Van ami gyorsan lefutott a fejlesztői gépen van ami nem. Ami lassan ment az újonnan megírt updatek közül a fejlesztőin, ott az indexekkel játszadozva (a meglévő indexek közül nem az optimálisat használta így meg kellett adni neki egy hint-el hogy mit használjon) sikerült a fejlesztőin is lefuttatni. De ettől függetlenül érdekes, hogy mi okozza ezt a nagy különbséget főleg az első update-nél amivel előjött ez a hiba. Ott az indexekkel már nem nagyon lehet bűvészkedni. 3 tábla vesz részt a játékban egy "fej" és egy "tétel" tábla, ott adottak a primary és foreign key "indexek",  a harmadik táblában meg csak 11 rekord van. Éppenséggel megpróbálhatom majd azt is indexelni, de ha az a 11 rekord okozza ezt a problémát, akkor ... morcos leszek.

Meg kellene próbálni több gépen is megfuttatni ugyanezzel az adatbázissal az updatet ha több másik gépen is megfelelő sebességgel fut akkor legalább már be van határolva hogy nálam van valami gond ...