Ik ben bezig met het ontwerp van een aantal tables dat geoptimaliseerd dient te zijn voor Updates/Inserts/Deletes en selects. Waarbij het overgrote deel van de querys Inserts/Updates of Selects zal bedragen; 90%. De overig 10% zal deletes omvatten. Van de 90% is het aantal selects en inserts ongeveer 50/50 verdeeld. Het graat hier om middelgrote tables waar naar schatting 750.000 rows in zullen gaan.
Alle querys zijn van het type SIMPLE query, er worden geen joins uit gevoerd op de table of transactions.
Op basis van deze gegevens (grote hoeveelheid inserts en updates en MyIsam is ontworpen rond het gegeven dat 90% van de querys inserts zouden zijn [bron: mysql.org]) heb ik gekozen voor InnoDB, alleen ben ik mezelf niet zeker van de keuze omdat veel can de advance features niet gebruikt zijn. Was MyIsam dan toch geen betere keuze?
Alle querys hebben een WHERE cause op de `owner` column welke helaas niet unique en dus niet als primarykey kan dienen in de table, Elke table heeft ook nog een een colunm `slot` welke opzich zelf alleen unique is per owner en ook niet als primarykey kan dienen. De combinatie van `owner` en `slot` is wel altijd unique, dit is dan ook op dit moment de primarykey. Om mysql the helpen is er een index op de `owner` column aangemaakt.
Een explain query [EXPLAIN SELECT * FROM `p_items` WHERE `owner` = 6] geeft het volgen resultaat:
Mysql kiest voor de primarykey (voorspelbaar) maar is dit nu ook echt sneller? Had ik niet beter FORCE INDEX (owner) aan de query toe kunnen voegen, deze index is tenslotte alleen op de `owner` column.
Alle querys zijn van het type SIMPLE query, er worden geen joins uit gevoerd op de table of transactions.
Op basis van deze gegevens (grote hoeveelheid inserts en updates en MyIsam is ontworpen rond het gegeven dat 90% van de querys inserts zouden zijn [bron: mysql.org]) heb ik gekozen voor InnoDB, alleen ben ik mezelf niet zeker van de keuze omdat veel can de advance features niet gebruikt zijn. Was MyIsam dan toch geen betere keuze?
Alle querys hebben een WHERE cause op de `owner` column welke helaas niet unique en dus niet als primarykey kan dienen in de table, Elke table heeft ook nog een een colunm `slot` welke opzich zelf alleen unique is per owner en ook niet als primarykey kan dienen. De combinatie van `owner` en `slot` is wel altijd unique, dit is dan ook op dit moment de primarykey. Om mysql the helpen is er een index op de `owner` column aangemaakt.
Een explain query [EXPLAIN SELECT * FROM `p_items` WHERE `owner` = 6] geeft het volgen resultaat:
code:
1
2
3
4
5
6
7
8
9
10
11
12
| mysql> EXPLAIN SELECT * FROM `p_items` WHERE `owner` = 6 \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: p_items
type: ref
possible_keys: PRIMARY,owner
key: PRIMARY
key_len: 8
ref: const
rows: 42
1 row in set (0.03 sec) |
Mysql kiest voor de primarykey (voorspelbaar) maar is dit nu ook echt sneller? Had ik niet beter FORCE INDEX (owner) aan de query toe kunnen voegen, deze index is tenslotte alleen op de `owner` column.
http://www.tweakers.net/gallery/119170/sys