Performanze Problem bei Updates

Hallo,
ich hoffe meine Frage ist nicht al zu FAQig. Ich habe eine Ruby on Rails =

Anwendung, die furchbar langsam ist. Laut den Logfiles verbringt die=20
Anwendung ~50% der Zeit mit der Datenbank. Auffällig ist, das die Zeite=
n=20
für select-statements durchgängig nicht messbar sind, für updates a=
ber=20
sehr häufig ~50ms benötigt werden. Table Type ist InnoDb und soll auc=
h=20
so sein, da an der einen oder anderen Stelle Redundanzen gepflegt=20
werden, die auch im Fehlerfall korrekt bleiben sollen.

Beispiel:

mysql> UPDATE stored_products SET amount =3D 8597, market_amount =3D 0,=20
average_price =3D 29.91 WHERE store_location =3D 1 AND store_owner =3D 14=
AND=20
product =3D 1;
Query OK, 1 row affected (0.06 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> desc stored_products;
+----------------+------------------+------+-----+---------+ -------+
| Field | Type | Null | Key | Default | Extra |
+----------------+------------------+------+-----+---------+ -------+
| store_location | int(10) unsigned | NO | PRI | NULL | |
| store_owner | int(10) unsigned | NO | PRI | NULL | |
| product | int(10) unsigned | NO | PRI | NULL | |
| amount | int(10) unsigned | NO | | NULL | |
| market_amount | int(10) unsigned | NO | | NULL | |
| average_price | decimal(20,2) | NO | | NULL | |
+----------------+------------------+------+-----+---------+ -------+
6 rows in set (0.00 sec)

Mit Explain kann ich scheinbar nur ergründen wie die Datenbank ein=20
Select umsetzt (welche nicht mein Problem sind). Wie kann ich ergründen=
,=20
warum die DB so lange für das update braucht?

Für jeden Hinweis dankbar,
Torsten

Re: Performanze Problem bei Updates

Torsten Robitzki schrieb:
> Hallo,
> ich hoffe meine Frage ist nicht al zu FAQig. Ich habe eine Ruby on Rails
> Anwendung, die furchbar langsam ist. Laut den Logfiles verbringt die
> Anwendung ~50% der Zeit mit der Datenbank. Auffällig ist, das die Zeiten
> für select-statements durchgängig nicht messbar sind, für updates aber
> sehr häufig ~50ms benötigt werden. Table Type ist InnoDb und soll auch
> so sein, da an der einen oder anderen Stelle Redundanzen gepflegt
> werden, die auch im Fehlerfall korrekt bleiben sollen.
>
> Beispiel:
>
> mysql> UPDATE stored_products SET amount = 8597, market_amount = 0,
> average_price = 29.91 WHERE store_location = 1 AND store_owner = 14 AND
> product = 1;
> Query OK, 1 row affected (0.06 sec)
> Rows matched: 1 Changed: 1 Warnings: 0
>
> mysql> desc stored_products;
> +----------------+------------------+------+-----+---------+ -------+
> | Field | Type | Null | Key | Default | Extra |
> +----------------+------------------+------+-----+---------+ -------+
> | store_location | int(10) unsigned | NO | PRI | NULL | |
> | store_owner | int(10) unsigned | NO | PRI | NULL | |
> | product | int(10) unsigned | NO | PRI | NULL | |
> | amount | int(10) unsigned | NO | | NULL | |
> | market_amount | int(10) unsigned | NO | | NULL | |
> | average_price | decimal(20,2) | NO | | NULL | |
> +----------------+------------------+------+-----+---------+ -------+
> 6 rows in set (0.00 sec)
>
> Mit Explain kann ich scheinbar nur ergründen wie die Datenbank ein
> Select umsetzt (welche nicht mein Problem sind). Wie kann ich ergründen,
> warum die DB so lange für das update braucht?
>
> Für jeden Hinweis dankbar,
> Torsten
>


Die erste Frage die ich mir gestellt habe: Gibt es einen Index auf
dieser Kombination der WHERE-Bedingung? Teste ob MySQL den nutzt durch
ein äquivalentes SELECT.

Desweiteren würde ich aus dem Bauchgefühl und aus ästetischen Gründen
auf einen zusammengesetzten PK verzichten, lieber einen synthetischen PK
einführen und evtl. eine Unique-Constraint. Wird aber wahrscheinlich
nicht schneller sein.

Greetings.

Dirk

Re: Performanze Problem bei Updates

Hallo Dirk,

Dirk Brosowski wrote:

> Die erste Frage die ich mir gestellt habe: Gibt es einen Index auf=20
> dieser Kombination der WHERE-Bedingung? Teste ob MySQL den nutzt durch =

> ein äquivalentes SELECT.

mysql> explain select * from stored_products where store_location =3D 1=20
AND store_owner =3D 14 AND product =3D 1;
+----+-------------+-----------------+-------+-------------- -------------=
--------------------------------+---------+----
-----+-------------------+------+-------+
| id | select_type | table | type | possible_keys=20
| key | key
_len | ref | rows | Extra |
+----+-------------+-----------------+-------+-------------- -------------=
--------------------------------+---------+----
-----+-------------------+------+-------+
| 1 | SIMPLE | stored_products | const |=20
PRIMARY,stored_products_FKIndex1,stored_products_FKIndex2 | PRIMARY | 12
| const,const,const | 1 | |
+----+-------------+-----------------+-------+-------------- -------------=
--------------------------------+---------+----
-----+-------------------+------+-------+
1 row in set (0.02 sec)

Die Indexe sehen wie folgt aus:
PRIMARY KEY(store_location, store_owner, product),
INDEX stored_products_FKIndex1(store_owner, store_location),
INDEX stored_products_FKIndex2(product)

Was ich noch nicht erwähnt habe: die Tabellen sind alle sehr schwach=20
besetzt.

mfg Torsten

Re: Performanze Problem bei Updates

Torsten Robitzki wrote:

> Beispiel:
>=20
> mysql> UPDATE stored_products SET amount =3D 8597, market_amount =3D 0,=
=20
> average_price =3D 29.91 WHERE store_location =3D 1 AND store_owner =3D =
14 AND=20
> product =3D 1;
> Query OK, 1 row affected (0.06 sec)
> Rows matched: 1 Changed: 1 Warnings: 0
>=20

mysql> UPDATE stored_products SET amount =3D 8597, market_amount =3D 0,=20
average_price =3D 29.1 WHERE store_location =3D 1 AND s
tore_owner =3D 14 AND product =3D 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

Ich habe den Wert innodb_flush_log_at_trx_commit auf 0 gesetzt, damit=20
werden die transaction logs nicht mit jeder Transaktion auf die Platte=20
geschrieben, sondern nur ca. alle Sekunde. Dadurch würden dann einige=20
Transaktionen verloren gehen, bei einem Stromausfall, damit kann ich=20
aber bei einem Spiel leben ;-)

mfg Torsten