Verschiedene key_len Ergebnisse in der gleichen Datenbank (verschiedene Umgebungen)

Question

Ich habe eine Produktionsdatenbank in AWS, aber die gleiche Datenbank in localhost ist viel schneller (25s VS 7s), einige Nachforschungen habe ich eine Diskrepanz in der gleichen SQL gefunden:

In AWS =====> key_len = 8 und Extra = Verwenden wo.
In localhost ==> key_len = 5 und Extra = Indexbedingung verwenden.

lief ich in beiden Standorten vor:

OPTIMIZE TABLE invoice; 

Wahrscheinlich ist es ein Konfigurationsproblem, aber ich bin verloren.

---

Weitere Informationen:
Mysql Version in AWS: 5.5.46
Mysql Version in Localhost: 5.6.24

in AWS erklären:

*************************** 1. row *************************** 
      id: 1 
    select_type: SIMPLE 
     table: i 
     type: range 
possible_keys: PRIMARY,IDX_5FD82ED84DD79520 
      key: IDX_5FD82ED84DD79520 
     key_len: 8 
      ref: NULL 
     rows: 847 
    filtered: 100.00 
     Extra: Using where 
*************************** 2. row *************************** 
      id: 1 
    select_type: SIMPLE 
     table: p 
     type: ref 
possible_keys: UNIQ_848ABB8F2989F1FD 
      key: UNIQ_848ABB8F2989F1FD 
     key_len: 5 
      ref: ontrocrm.i.id 
     rows: 1 
    filtered: 100.00 
     Extra: Using where 

erklären in localhost:

*************************** 1. row *************************** 
      id: 1 
    select_type: SIMPLE 
     table: i 
     type: range 
possible_keys: PRIMARY,IDX_5FD82ED84DD79520 
      key: IDX_5FD82ED84DD79520 
     key_len: 5 
      ref: NULL 
     rows: 847 
    filtered: 100.00 
     Extra: Using index condition 
*************************** 2. row *************************** 
      id: 1 
    select_type: SIMPLE 
     table: p 
     type: ref 
possible_keys: UNIQ_848ABB8F2989F1FD 
      key: UNIQ_848ABB8F2989F1FD 
     key_len: 5 
      ref: ontrocrm.i.id 
     rows: 1 
    filtered: 100.00 
     Extra: NULL 

Tabelle erstellen ist das gleiche in beiden, ist man ein Backup von der anderen:

CREATE TABLE `invoice` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `number` int(11) NOT NULL, 
    `whenCreated` datetime NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `unique_number` (`number`), 
    KEY `IDX_5FD82ED84DD79520` (`whenCreated`) 
) 

Answer 1

key_len diff

Sie entdeckt die Änderung zu erklären, dass mit DATETIME und TIMESTAMP in 5.6.4 geschah . Vorher waren sie 8 Bytes (gepackt dezimal) bzw. 4 Bytes (nur INT). Danach sind sie beide 5 + Bytes, einschließlich der Fähigkeit, bis zu 6 Dezimalstellen Mikrosekunden aufzunehmen.

"Verwenden wo" bedeutet nicht viel. "Verwendung der Indexbedingung" bezieht sich auf "ICP" oder "Index Condition Pushdown", was eine Optimierung ist, die in der Regel beschleunigt Abfragen, die nicht einen optimalen zusammengesetzten Index haben. [An dieser Stelle muss ich sehen SHOW CREATE TABLE; Ich werde erraten, dass Sie InnoDB verwenden.] Statt jede Zeile von der Engine (InnoDB) zurück "nach oben" der "Handler" für weitere Analyse zu übergeben, wird die "Bedingung" (WHERE ...) auf die Engine "down" gedrückt , wo es schneller verarbeitet werden kann.

In Ihre Fall erhalten Sie 3x-4x Beschleunigung; nett. (Meine Faustregel. 2x)

Andere

Machst du wirklich SELECT *? Wenn Sie nicht alle Spalten benötigen, sollten Sie die gewünschten Spalten buchstabieren; Ihnen fehlt möglicherweise ein Optimierungspotenzial.

Ist UNIQ_848ABB8F2989F1FD "einzigartig" oder wird es falsch benannt?

Wenn invoice.numberUNIQUE ist, warum nicht als PRIMARY KEY verwenden und id vollständig loswerden? Dies würde einige Operationen beschleunigen (obwohl wahrscheinlich nicht die aktuelle SELECT).

Sie haben wahrscheinlich bemerkt, dass OPTIMIZE TABLE wenig oder keinen Einfluss hatte?

Statt WHERE i.whenCreated BETWEEN "2017-01-01 00:00:00" AND "2017-01-31 00:00:00", die eine zusätzliche zweite und erfordert die Berechnung der End-of-Monats-beinhaltet, wie ich sage:

WHERE i.whenCreated >= "2017-01-01" 
    AND i.whenCreated < "2017-01-01" + INTERVAL 1 MONTH