MYSQL+InnoDB+Rarticionálás
Sziasztok!
Van -e valakinek tapasztalata partíciónálással kapcsolatban?
Most próbálkozom vele (mysql 5.6), és igen érdekeseket tapasztalok.
1.
Ha van egy próbatáblám amit 4 részre partíciónálok, és teszek bele egyetlen egy adatot. Ekkor a information_schema.PARTITIONS táblában nyomom követhetem, hogy az az egy rekord melyik partícióra kerül.
Kipróbáltam, hogy változtatok a partíción, és azt tapasztalom, hogy ekkor information_schema.PARTITIONS táblában a tábla méretet jelző számláló minden partíción kinullázódik.
Ettől a pillanattól csak az új rekordok jelennek meg itt, illetve ha valamelyik rekord egy módosítás miatt egy másik partícióra kerül.
Szerencsére a rekord nem veszik el, de nem tudom, hogy ez normális működés -e. Nem tudom, hogy nagy elemszám esetén nem járna -e esetleg adatvesztéssel.
2.
Van egy nagy elemszámú próbatáblám. 3 mező van van benne véletlen adatokkal. A táblán mind a 3 mezőre külön-külön van egy-egy index.
Szerettem volna az adatokat átmásolni egy másik táblába, mely szerkezete ugyanúgy néz ki, csak két különbség van:
- került rá egy plusz index (egy két mezős)
- 15+1 partícióra van bontva az egyik mező alapján az új táblaszerkezet.
Kiadtam a INSERT INTO SELECT parancsot és már órák óta tölti át az adatokat. Mi miatt lehet ez? Lehet ez a partíciónálás hibája, hogy a nagy mennyiségű írással nem boldogul? Vagy a plusz index?
Közben azt látom, hogy az eredeti index számosságok helyett a phpmyadminban az össze index számossága annyi amennyi az éppen már átmásolt elemek száma.
Mintha semmi értelme nem lenne az indexnek.
Valamint ha a tábla méretét nézem, akkor már most jóval nagyobb mint az amiből másolom az adatokat.
Mitől lehet ez?
3.
Ilyen a táblám:
CREATE TABLE `table` (
`id` bigint(20) NOT NULL,
`a` varchar(30) NOT NULL,
`b` int(11) NOT NULL,
KEY `fk_id` (`id`),
KEY `fk_a` (`a`),
KEY `fk_b` (`b`),
KEY `ab` (`a`,`b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
PARTITION BY LIST COLUMNS (`a`)(
PARTITION pRegion_1 VALUES IN('aaa'),
PARTITION pRegion_2 VALUES IN('bbb'),
PARTITION pRegion_3 VALUES IN('ccc'),
.
.
.
PARTITION pRegion_16 VALUES IN(NULL)
)
Ebbe másolom az adatokat.
PARTITION BY LIST COLUMNS esetén nem tudtam létrehozni olyan partíciót amibe azok a rekordok kerülnének, amik nem felelnek meg a többi partíciónak.
Így viszont szükség lehet a partíciók bővítésére.
Sajnos nem sikerült ALTER TABLE paranccsal megoldanom, hogy mondjuk a 'www'-nak is tudjak utólag felvenni egy új partíciót.
Azért csináltam egy NULL partíciót, mert egy partíciót módosítani (pl szétszedni) azt sikerült.
ALTER TABLE table REORGANIZE PARTITION `pRegion_16` INTO (
PARTITION `pRegion_16` VALUES IN('www'),
PARTITION `pRegion_17` VALUES IN(NULL)
);
Hogy lehet beszúrni új partíció szeleteket LIST COLUMNS estén?
Alfa
■ Van -e valakinek tapasztalata partíciónálással kapcsolatban?
Most próbálkozom vele (mysql 5.6), és igen érdekeseket tapasztalok.
1.
Ha van egy próbatáblám amit 4 részre partíciónálok, és teszek bele egyetlen egy adatot. Ekkor a information_schema.PARTITIONS táblában nyomom követhetem, hogy az az egy rekord melyik partícióra kerül.
Kipróbáltam, hogy változtatok a partíción, és azt tapasztalom, hogy ekkor information_schema.PARTITIONS táblában a tábla méretet jelző számláló minden partíción kinullázódik.
Ettől a pillanattól csak az új rekordok jelennek meg itt, illetve ha valamelyik rekord egy módosítás miatt egy másik partícióra kerül.
Szerencsére a rekord nem veszik el, de nem tudom, hogy ez normális működés -e. Nem tudom, hogy nagy elemszám esetén nem járna -e esetleg adatvesztéssel.
2.
Van egy nagy elemszámú próbatáblám. 3 mező van van benne véletlen adatokkal. A táblán mind a 3 mezőre külön-külön van egy-egy index.
Szerettem volna az adatokat átmásolni egy másik táblába, mely szerkezete ugyanúgy néz ki, csak két különbség van:
- került rá egy plusz index (egy két mezős)
- 15+1 partícióra van bontva az egyik mező alapján az új táblaszerkezet.
Kiadtam a INSERT INTO SELECT parancsot és már órák óta tölti át az adatokat. Mi miatt lehet ez? Lehet ez a partíciónálás hibája, hogy a nagy mennyiségű írással nem boldogul? Vagy a plusz index?
Közben azt látom, hogy az eredeti index számosságok helyett a phpmyadminban az össze index számossága annyi amennyi az éppen már átmásolt elemek száma.
Mintha semmi értelme nem lenne az indexnek.
Valamint ha a tábla méretét nézem, akkor már most jóval nagyobb mint az amiből másolom az adatokat.
Mitől lehet ez?
3.
Ilyen a táblám:
CREATE TABLE `table` (
`id` bigint(20) NOT NULL,
`a` varchar(30) NOT NULL,
`b` int(11) NOT NULL,
KEY `fk_id` (`id`),
KEY `fk_a` (`a`),
KEY `fk_b` (`b`),
KEY `ab` (`a`,`b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
PARTITION BY LIST COLUMNS (`a`)(
PARTITION pRegion_1 VALUES IN('aaa'),
PARTITION pRegion_2 VALUES IN('bbb'),
PARTITION pRegion_3 VALUES IN('ccc'),
.
.
.
PARTITION pRegion_16 VALUES IN(NULL)
)
Ebbe másolom az adatokat.
PARTITION BY LIST COLUMNS esetén nem tudtam létrehozni olyan partíciót amibe azok a rekordok kerülnének, amik nem felelnek meg a többi partíciónak.
Így viszont szükség lehet a partíciók bővítésére.
Sajnos nem sikerült ALTER TABLE paranccsal megoldanom, hogy mondjuk a 'www'-nak is tudjak utólag felvenni egy új partíciót.
Azért csináltam egy NULL partíciót, mert egy partíciót módosítani (pl szétszedni) azt sikerült.
ALTER TABLE table REORGANIZE PARTITION `pRegion_16` INTO (
PARTITION `pRegion_16` VALUES IN('www'),
PARTITION `pRegion_17` VALUES IN(NULL)
);
Hogy lehet beszúrni új partíció szeleteket LIST COLUMNS estén?
Alfa
Indexelés