Dotaz: MySQL auto_increment po restartu databaze

[Jirka]

Ahoj, mam takovy nepekny problem. Mam tabulku hotelu, kde kazdy hotel ma sve id, toto pole ma vlastnost auto_increment. Vsiml jsem si jedne veci: v tabulce mam jiz neco hotelu a zalozim dalsi, dostane treba id=60. Vymazu ho a pak zalozim dalsi, ten dostane id=61. Pokud bych zalozil dalsi hotel zjevne dostane id=62. Jenze pred tim restartuji databazi MySQL. A ted zalozim dalsi hotel a on ma id=60! To prece neni normalni! Viz stav tabulky nize:

mysql> SHOW TABLE STATUS LIKE 'hotel'\G
*************************** 1. row ***************************
           Name: hotel
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 36
 Avg_row_length: 455
    Data_length: 16384
Max_data_length: 0
   Index_length: 0
      Data_free: 11534336
 Auto_increment: 62
    Create_time: 2011-04-03 11:32:13
    Update_time: NULL
     Check_time: NULL
      Collation: utf8_czech_ci
       Checksum: NULL
 Create_options: 
        Comment: seznam hotelů
1 row in set (0.00 sec)

mysql> SHOW TABLE STATUS LIKE 'hotel'\G
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: test21

*************************** 1. row ***************************
           Name: hotel
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 36
 Avg_row_length: 455
    Data_length: 16384
Max_data_length: 0
   Index_length: 0
      Data_free: 11534336
 Auto_increment: 60
    Create_time: 2011-04-03 11:32:13
    Update_time: NULL
     Check_time: NULL
      Collation: utf8_czech_ci
       Checksum: NULL
 Create_options: 
        Comment: seznam hotelů
1 row in set (0.03 sec)

Prvni status ukazuje stav pred restartem a ma dle ocekavani Auto_increment: 62. Pak je videt ztratu spojeni po restartu databaze a vypis dalsiho statusu na stejne tabulce. Kupodivu je Auto_increment: 60.

Odpovědi

[Jirka]

Nutno jeste podotknout, ze struktura a data byly obnoveny ze zalohy (mysqldump) takto:

DROP TABLE IF EXISTS `hotel`;
CREATE TABLE `hotel` (
    `id_hotel` int(11) NOT NULL AUTO_INCREMENT COMMENT 'identifikátor hotelu',
    ...
    PRIMARY KEY (`id_hotel`)
) ENGINE=InnoDB AUTO_INCREMENT=60 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci COMMENT='seznam hotelů';

[Ash]

Ten AUTO_INCREMENT=60 by to vysvětloval :) Jestli jste data obnovil takto, tak následný záznam opravdu dostane 61, protože jako nejvyšší přidělený je v zálozen uvedeno 60.

[Jirka]

To je OK, me vadi ze po vlozeni a naslednem vymazani nekolika zaznamu se to po restartu databaze vrati na tech 60. Melo by to vesele pokracovat dal, stale kupredu.

[Filip Jirsák]

Potvrdíte (commit) před tím restartem transakci?

[Jirka]

Ne, to se opravdu musi pro pole s vlastnosti auto_increment?

[Filip Jirsák]

Každá transakce se musí potvrdit nebo zamítnout. Když transakci nepotvrdíte, neprovedou se žádné změny – tedy nejen autoinkrementy, ale ani INSERTy, UPDATy, DELETy atd.

[Heron]

V tomto případě bych ale očekával práci v autocommit režimu. I když, počkejme, co napiše tazatel.

[Jirka]

Tak jsem dotycny INSERT vlozil mezi:

START TRANSACTION;
INSERT INTO `hotel` ...
COMMIT;

a vysledek je stejny, tedy po vymazu naposledy vlozeneho hotelu a naslednem restartu databaze se to vrati na 60.

[Šangala]

Však Vám to tu píšu, že tabulky InnoDB mezi restarty serveru neuchovávají hodnotu autoincrement-u, ale nastaví si jej na minimální možné číslo.

[Jirka]

Takze kdyz tabulku prevedu na ISAM, bude to fungovat dle ocekavani? Toto je vlastnost pouze InnoDB?

[Šangala]

Definujte „očekávání“… :)
Ano (pokud se nepletu), tak MyISAM má uloženu hodnotu auto_increment-u u tabulky, tedy po restartu DB je hodnota na stejné hodnotě jako před restartem.
PS: Ale InnoDB a MyISAM se liší ve více věcech. Jinak nevím co je na tom ne-očekávané nebo čemu to vadí, že se auto_increment nastavuje na minimální možnou hodnotu (to bych čekal chybu někde v návrhu… ).

[Jirka]

Ocekavam, ze rada id pobezi stale kupredu, ze se po restartu nevrati zpet. Nerad bych. aby dva (ci vice) hotely mely stejne id (i kdyz samozrejme ne soucasne). ID musi jednoznacne identifikovat zaznam, od toho prece je.

[Heron]

V tom případě asi bude rozumnější si ten unikátní klíč hotelu počítat jinak a nespoléhat se na funkci autoincrement, která se chová jinak, než očekáváš.

Já osobně auto increment nepouživám, pokud už to chci číslovat postupně (což se ne vždy vyžaduje, sekvenční ID bývá nutné jen málokdy), tak mám v DB speciální tabulku (pro každé počítadlo jeden řádek) a v ní uchovávám poslední přidělenou hodnotu. Což je trochu podobné sekvencím v PostgreSQL.

[Jirka]

Tak jsem u tabulky zmenil engine

ALTER TABLE hotel ENGINE=MyISAM;

a znovu vyzkousel. Nyni se id prideluji dle meho ocekavani, tedy stale kupredu, bez ohledu na restarty databaze. A tak to ma byt. Nejsem si jist zda u engine InnoDB jde o vlastnost ci bug ...

[Kit]

Však už jsi tady dostal odpověď, že je to vlastnost. Bug by to byl až ve chvíli, kdy by vznikly v tabulce 2 záznamy se stejným ID.

[Heron]

A jak teď budeš zajišťovat referenční integritu a transakční zpracování? Přechod na MYISAM je krokem zpět.

[Jirka]

Je to jednoducha databaze, transakce jsem nepouzil. Nekde pouzivam fulltext hledani, proto cast tabulek stejne bezi na MyISAM. Na zbytek jsem pouzil InnoDB a ty prevedu. Ale udivuje me, ze se auto_increment pod ruznymi enginy chova jinak...

[Heron]

Tak na to je třeba si u MySQL zvyknout. A nebo si nezvykat a místo toho použít pořádnou DB.

[Jirka]

Vzdycky, kdyz jsem cetl podobny nazor, myslel jsem si, ze dotycny zbytecne machruje. A ted koukam, ze je to pravda!

[Šangala]

„Zbytečně machruje“ :), každá DB funguje nějak jinak a má něco a co ta druhá ne.
A zrovna v tomto případě je to o neznalosti, ne o limitech dané DB.
Zkuste se na to podívat i tak, že InnoDB je uložný systém od Oracle, ne že by to znamenalo, že je díky tomu super, ale je to od někoho kdo databázím rozumí a je to k nějakému účelu vhodné.

[Heron]

Ne, to není o machrování. Já jsem si podobným vývojem také prošel. MySQL a MYISAM a fází "referenční integrita a transakce, na co? vs. to přece můžu zaručit v app (nemůžu, nikdy nebudu tak dobrý jako těch několik desítek let všech těch špičkových programátorů SQL serverů)", přes přechodnou fázi InnoDB (a s tím spojeným problémem nevyladitelného výkonu MySQL) až k dnešnímu PostgreSQL (k čemuž jsem se dostal nejdřív jako technik u nového zaměstnavatele). A musím říct, že PostgreSQL je jednak jednodušší (než MySQL) na správu a konfiguraci serveru (plus pro technika), ale také (plus pro programátora) jednodušší po stránce použití (více datových tipů, funkcí, kvalitních rozšíření apod).

A právě proto, že jsem si tím prošel, tak vím, kolik zbytečného času jsem strávil nad stupiditami MySQL, třeba právě typu v MyISAM to jede a v InnoDB ne; nevhodných návyků atd. Kdybych poslechl všechny ty "machýrky" (taky jsem si to myslel), co doporučovali (už někdy na univerzitě před deseti lety) se vykašlat na MySQL, ušetřil bych si spoustu času, nervů a rozbitých dat.

[Šangala]

Jo když má člověk možnost volby, to je super. A nejlépe když u je to i nachystané, ale třeba mají někde nachystané M$SQL a to je (aspoň pro mě) teprve utrpení, zlaté MySQL :).
Ale stále je PostgreSQL dražším řešením (třeba u hostingů, pokud vůbec lze).
S tou jednoduchostí, to je hodně subjektivní, človíček, který zná základní insert, select a update, tak bojuje s neznalostí a třeba ani se nechce nikam dobojovat a stačí mu těch pět tabulek co má, a PostgreSQL by právě svou šířkou mohlo dorazit.
Třeba někomu vadí (nechce se přizpůsobit), že PostgreSQL nemá 'SHOW CREATE TABLE', nebo, že stejná data na disku jsou (někdy výrazně) větší než v MySQL, nebo výkon pročtení u MyISAM (jednou za rok zapíšu a pak jen čtu, integrita na co - jedu na výkon)
Neustále je to něco za něco.
Je pravdou, že s PostgreSQL skoro nedělám (protože většinou není PostgreSQL k dispozici), ale na takové to domácí žvýkání je MySql s InnoDB dostatečné, levné, přenositelné a bezúdržbové (nebijte mě) a většinou s výkonem problém není. Chcete-li budovat informační systém pro 200+ lidí, tak samozřejmě na začátku si zvolíte kudy a není problém použít cokoliv. Ale když pro 10, tak tam prdnu MySQL a na PostgreSql to pude migrovat vždy (když není člověk prase) - horší je když se do toho motá M$SQL.

[Kit]

Tyto metody se přece používají v NoSQL.

To by mě zajímalo, jak tímto způsobem založíš nový záznam v DB jedním SQL dotazem.

[Heron]

Proč by to muselo jít jedním dotazem? Stačí v jedné transakci. Stejně je tam těch dotazů typicky více. Ale toto byl jen příklad. Autoincrement ani sekvence příliš nepoužívám, insertovaná data většinou už mají stanovený nějaký svůj unikátní klíč.

[Kit]

Dobrá. Jak to tedy uděláš v jedné transakci? Používáš vnořené procedury?

[Šangala]

Tak, kéž bych k tomu dospěl a pohromu ve formě auto_increment-ů zapomněl :).
Auto_increment-y používám, ale charakterizoval bych to jako: „na začátku super, v budoucnu problém a práce navíc“ (koncept sekvencí bych bral…, v mysql se to dělá blbě s ohledem na transakce a update počitadla /nechci odeslat transakci toho co dělám, aleupdate počitadla jo/).

[Šangala]

ID musi jednoznacne identifikovat zaznam
Ano to primární identifikátor obvykle dělá, ale když záznam smažete, tak o něm neexistuje žádná další informace - to se obvykle říká mazaním „už to není“, pokud chcete uchovat historii, tak záznam „jen“ označíte za smazaný.
Ve „vesmíru“, který definujete databází přece nemohou být dva hotely ze stejným id to prostě nejde bez ohledu na to jak a co se děje s hodnotou auto_incrementu.
Možná Vás bude zajímat i informace, že tyto id mohou generovat i mezery, klidně můžete mít 60 a pak 62 aniž by jste kdy opravdu záznam 61 měl a smazal jej, stačí jen jeden rollback v momentě kdy běží už další transakce (transakce vznikají samy ikdyž je nestartujete, jen dle hodnoty auto_commit se buď samy odešlou, nebo to řídíte vy).
Takovéto ID identifikuje jedinečnost záznamu v DB. Pokud stavíte „vyšší“ logiku a mohla by Vám vadit, z pohledu okolí, nejednoznačnost či děravost musíte si to řešit sám.

O bug se nejedná, je to někdy pro „jednodušší“ systémy jen nepříjemné zjištění (je dobré znát vlastnosti toho co používáte :) ).
A někde jsem četl, že v nějaké verzi 5.xx třeba 5.99 :), budou modernizace v InnoDB a toto chování bude také změněno jak u MyISAM (berete to jako neověřenou informaci).

[Šangala]

InnoDB po restartu provedou něco jako SELECT MAX(auto_increment_column) FROM table a na to nastaví hodnotu. Jakože InnoDB si nedrží mezi restarty údaj o dosažené hodnotě auto_increment-u. Ale každopádně by vám neměly vzniknou dva záznamy ze stejnou hodnotou. Asi nebyl poslední záznam před restartem zapsán COMMIT-nut (nebo auto_commit-nut).

[VM]

Nastavení auto_increment na minimální ID co není v DB je rozumné - zbytečně nevznikají díry. Pokud to nechcete, krom zmíněných možností můžete záznamy nemazat, ale přidat sloupec ve kterém je označíte za neaktivní.