W poprzednim poście pisałem o algorytmie Index Merge, który w pewnych, szczególnych wpadkach umożliwia skorzystanie z kilku indeksów jednocześnie. Jak wygląda wydajność tego algorytmu? Czy jest sens stosować go zamiast indeksów na wiele kolumn? Aby to sprawdzić przygotowałem środowisko testowe. Tabela ma następującą strukturę:
mysql> SHOW CREATE TABE tab1\G
*************************** 1. row ***************************
Table: tab1
Create Table: CREATE TABLE `tab1` (
`a` int(10) NOT NULL AUTO_INCREMENT,
`b` int(10) DEFAULT NULL,
`c` int(10) DEFAULT NULL,
`d` int(10) DEFAULT NULL,
`e` int(10) DEFAULT NULL,
PRIMARY KEY (`a`)
) ENGINE=MyISAM AUTO_INCREMENT=2000001 DEFAULT CHARSET=latin2
1 row in set (0.00 sec)
*************************** 1. row ***************************
Table: tab1
Create Table: CREATE TABLE `tab1` (
`a` int(10) NOT NULL AUTO_INCREMENT,
`b` int(10) DEFAULT NULL,
`c` int(10) DEFAULT NULL,
`d` int(10) DEFAULT NULL,
`e` int(10) DEFAULT NULL,
PRIMARY KEY (`a`)
) ENGINE=MyISAM AUTO_INCREMENT=2000001 DEFAULT CHARSET=latin2
1 row in set (0.00 sec)
Jak widać, jest w niej 2 miliony niewielkich rekordów. Kolumny `b`, `c`, `d` i `e` przyjmują pseudolosowo generowane wartości z zakresu 0 – 100.
Tabela w takiej postaci zajmuje: dane – 41016K, klucz główny – 20045K.
czytaj dalej…
