Skryté vlastnosti MySQL

Protože jsi vypsal odměnu, podělím se o svá těžce vybojovaná tajemství...

Obecně platí, že všechny SQL, které jsem dnes vyladil, vyžadovaly použití dílčích dotazů. Protože jsem přišel z databázového světa Oracle, věci, které jsem považoval za samozřejmé, nefungovaly stejně s MySQL. A moje čtení o ladění MySQL mě vede k závěru, že MySQL je za Oraclem, pokud jde o optimalizaci dotazů.

Zatímco jednoduché dotazy vyžadované pro většinu aplikací B2C mohou dobře fungovat pro MySQL, zdá se, že většina dotazů typu souhrnných sestav potřebných pro zpravodajské sestavy vyžaduje trochu plánování a reorganizace dotazů SQL, aby vedly MySQL k jejich rychlejšímu provádění.

Administrace:

max_connections je počet souběžných připojení. Výchozí hodnota je 100 připojení (151 od verze 5.0) – velmi malé.

Poznámka:

připojení zabírají paměť a váš operační systém nemusí být schopen zvládnout mnoho připojení.

Binární soubory MySQL pro Linux/x86 vám umožňují mít až 4096 souběžných připojení, ale samostatně kompilované binární soubory mají často menší limit.

Nastavte table_cache tak, aby odpovídal počtu vašich otevřených tabulek a souběžných připojení. Sledujte hodnotu open_tables a pokud rychle roste, budete muset zvětšit její velikost.

Poznámka:

2 předchozí parametry mohou vyžadovat hodně otevřených souborů. 20+max_connections+table_cache*2 je dobrý odhad toho, co potřebujete. MySQL na Linuxu má možnost open_file_limit, nastavte tento limit.

Pokud máte složité dotazy sort_buffer_size a tmp_table_size, budou pravděpodobně velmi důležité. Hodnoty budou záviset na složitosti dotazu a dostupných zdrojích, ale doporučenými výchozími body jsou 4 Mb a 32 Mb.

Poznámka:Toto jsou hodnoty "na připojení", mezi read_buffer_size, read_rnd_buffer_size a některé další, což znamená, že tato hodnota může být potřebná pro každé připojení. Při nastavování těchto parametrů tedy zvažte své zatížení a dostupné zdroje. Například sort_buffer_size se alokuje pouze v případě, že MySQL potřebuje provést řazení. Poznámka:Dávejte pozor, aby vám nedošla paměť.

Pokud máte vytvořeno mnoho připojení (tj. web bez trvalých připojení), můžete zlepšit výkon nastavením thread_cache_size na nenulovou hodnotu. 16 je dobrá hodnota pro začátek. Zvyšte hodnotu, dokud vaše threads_created neporoste příliš rychle.

PRIMÁRNÍ KLÍČ:

V tabulce může být pouze jeden sloupec AUTO_INCREMENT, musí být indexován a nesmí mít hodnotu DEFAULT

KEY je obvykle synonymem pro INDEX. Atribut klíče PRIMARY KEY lze také zadat jako pouhý KEY, pokud je uveden v definici sloupce. Toto bylo implementováno pro kompatibilitu s jinými databázovými systémy.

PRIMÁRNÍ KLÍČ je jedinečný index, kde všechny sloupce klíče musí být definovány jako NOT NULL

Pokud se PRIMARY KEY nebo UNIQUE index skládá pouze z jednoho sloupce, který má typ celé číslo, můžete tento sloupec v příkazech SELECT také označit jako "_rowid".

V MySQL je název PRIMÁRNÍHO KLÍČE PRIMARY

V současné době podporují cizí klíče pouze tabulky InnoDB (v5.1?).

Obvykle vytváříte všechny indexy, které potřebujete, když vytváříte tabulky. Indexován bude každý sloupec deklarovaný jako PRIMARY KEY, KEY, UNIQUE nebo INDEX.

NULL znamená „nemá hodnotu“. Chcete-li otestovat hodnotu NULL, nemůžete použijte aritmetické porovnávací operátory, jako je =, . Místo toho použijte operátory IS NULL a IS NOT NULL:

NO_AUTO_VALUE_ON_ZERO potlačí automatické zvýšení o 0, takže další pořadové číslo vygeneruje pouze NULL. Tento režim může být užitečný, pokud byla ve sloupci AUTO_INCREMENT tabulky uložena 0. (Mimochodem, ukládání 0 se nedoporučuje.)

Chcete-li změnit hodnotu počítadla AUTO_INCREMENT, která se má použít pro nové řádky:

ALTER TABLE mytable AUTO_INCREMENT = value; 

orSET INSERT_ID =hodnota;

Pokud není uvedeno jinak, hodnota bude začínat:1000000 nebo ji specifikujte takto:

...) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1

ČASOVÁ ZNÁMKA:

Hodnoty pro sloupce TIMESTAMP jsou převedeny z aktuálního časového pásma na UTC pro uložení a z UTC do aktuálního časového pásma pro načtení.

http://dev.mysql.com/doc/refman/5.1 /en/timestamp.html Pro jeden sloupec TIMESTAMP v tabulce můžete přiřadit aktuální časové razítko jako výchozí hodnotu a hodnotu automatické aktualizace.

jedna věc, na kterou je třeba dávat pozor při použití jednoho z těchto typů v klauzuli WHERE, je nejlepší udělatWHERE datecolumn =FROM_UNIXTIME(1057941242) a neWHERE UNIX_TIMESTAMP(datecolumn) =1057941242. sloupec.

http://dev.mysql.com /doc/refman/5.1/en/date-and-time-functions.html

 UNIX_TIMESTAMP() 
 FROM_UNIXTIME() 
 UTC_DATE()
 UTC_TIME()
 UTC_TIMESTAMP()

pokud v MySQL převedete datum a čas na unixové časové razítko:
A pak k tomu přidejte 24 hodin:
A pak to převeďte zpět na datum a čas, magicky to ztratí hodinu!

Tady je to, co se děje. Při převodu unixového časového razítka zpět na datum a čas se bere v úvahu časové pásmo a stane se, že mezi 28. a 29. říjnem 2006 jsme přešli na letní čas a ztratili jsme hodinu.

Počínaje MySQL 4.1.3 vracejí funkce CURRENT_TIMESTAMP(), CURRENT_TIME(), CURRENT_DATE() a FROM_UNIXTIME() hodnoty v aktuálním časovém pásmu připojení , která je dostupná jako hodnota systémové proměnné time_zone. Navíc UNIX_TIMESTAMP() předpokládá, že její argument je hodnota datetime v aktuálním časovém pásmu.

Aktuální nastavení časového pásma neovlivňuje hodnoty zobrazené funkcemi, jako je UTC_TIMESTAMP() nebo hodnoty ve sloupcích DATE, TIME nebo DATETIME.

POZNÁMKA:PŘI AKTUALIZACI POUZE aktualizuje datum a čas, pokud se pole změní. Pokud AKTUALIZACE nevede ke změně žádného pole, pak se datum a čas NEaktualizuje!

Navíc je First TIMESTAMP ve výchozím nastavení vždy AUTOUPDATE, i když není specifikováno

Když pracuji s Datem, téměř vždy konverzuji na Julian Date, protože datová matematika je pak jednoduchá záležitost sčítání nebo odečítání celých čísel a sekund od půlnoci ze stejného důvodu. Je vzácné, že potřebuji časové rozlišení s jemnější zrnitostí než sekundy.

Obojí lze uložit jako 4bajtové celé číslo, a pokud je místa opravdu málo, lze je zkombinovat do času UNIX (sekundy od epochy 1.1.1970) jako celé číslo bez znaménka, které bude dobré až do roku 2106 jako:

' s za 24 hodin =86 400

' Maximální hodnota podepsaného celého čísla =2 147 483 647 – pojme 68 let sekund

' Unsigned Integer max val =4,294,967,295 – pojme 136 let sekund

Binární protokol:

MySQL 4.1 představil binární protokol, který umožňuje odesílání a vracení neřetězcových datových hodnot v nativním formátu bez převodu do a z formátu řetězce. (Velmi užitečné)

Kromě toho, mysql_real_query() je rychlejší než mysql_query(), protože nevolá strlen() k operaci s řetězcem příkazu.

http://dev.mysql.com/tech-resources /articles/4.1/prepared-statements.html Binární protokol podporuje příkazy připravené na straně serveru a umožňuje přenos datových hodnot v nativním formátu. Binární protokol prošel během dřívějších verzí MySQL 4.1 poměrně velkou revizí.

Pomocí makra IS_NUM() můžete otestovat, zda má pole číselný typ. Předejte hodnotu typu do IS_NUM() a vyhodnotí se jako TRUE, pokud je pole číselné:

Jedna věc, kterou je třeba poznamenat, je, že binární data UMÍ být odeslány v rámci běžného dotazu, pokud jej escapujete a pamatujete si, že MySQL vyžaduje pouze zpětné lomítko a znak uvozovky musí být escapovány. Je to tedy opravdu snadný způsob, jak VLOŽIT kratší binární řetězce, jako jsou například šifrovaná/slaná hesla.

Hlavní server:

http://www.experts-exchange.com/Database/MySQL/Q_22967482 .html

http://www.databasejournal.com/features/mysql/article.php /10897_3355201_2

GRANT REPLICATION SLAVE NA . slave_user IDENTIFIKOVANÝ BY 'slave_password'

#Master Binary Logging Config  STATEMENT causes replication 
              to be statement-based -  default

log-bin=Mike
binlog-format=STATEMENT
server-id=1            
max_binlog_size = 10M
expire_logs_days = 120    


#Slave Config
master-host=master-hostname
master-user=slave-user
master-password=slave-password
server-id=2

Binární soubor protokolu musí číst:

http://dev.mysql.com/doc/refman /5.0/cs/binary-log.html

http://www.mydigitallife.info/2007/10/06/how-to-read-mysql-binary-log-files-binlog-with-mysqlbinlog/

http://dev.mysql.com/doc/refman/5.1 /cs/mysqlbinlog.html

http://dev.mysql.com/doc/refman /5.0/cs/binary-log.html

http://dev.mysql.com/doc /refman/5.1/cs/binary-log-setting.html

Všechny binární soubory protokolu můžete smazat pomocí příkazu RESET MASTER nebo jejich podmnožinu pomocí PURGE MASTER

--result-file=binlog.txt TrustedFriend-bin.000030

Normalizace:

http://dev.mysql.com/tech-resources /articles/intro-to-normalization.html

Funkce UDF

http://www.koders.com/cpp/fidDFas10666637932ACDa8001DDFas04801DEBas0432

http://souptonuts.sourceforge.net/readme_mysql.htm

Datové typy:

http://dev.mysql.com/doc/refman /5.1/cs/storage-requirements.html

http://www.informit.com/articles/article.aspx ?p=1238838&seqNum=2

http://bitfilm. net/2008/03/24/saving-bytes-efficient-data-storage-mysql-part-1/

Jedna věc, kterou je třeba poznamenat, je, že na smíšené tabulce s CHAR i VARCHAR, mySQL změní CHAR na VARCHAR

RecNum integer_type UNSIGNED NOT NULL AUTO_INCREMENT, PRIMÁRNÍ KLÍČ (RecNum)

MySQL vždy představuje data s rokem jako první, v souladu se standardními specifikacemi SQL a ISO 8601

Různé:

Vypnutí některých funkcí MySQl povede k menším datovým souborům a rychlejšímu přístupu. Například:

--datadir určí datový adresář a

--skip-innodb vypne možnost inno a ušetří vám 10-20 milionů

Více zdehttp://dev.mysql.com/tech -resources/articles/mysql-c-api.html

Stáhněte si kapitolu 7 – zdarma

InnoDB je transakční, ale s tím je spojena režie výkonu. Zjistil jsem, že tabulky MyISAM jsou dostatečné pro 90 % mých projektů. Tabulky, které nejsou bezpečné pro transakce (MyISAM) mají několik vlastních výhod, z nichž všechny se vyskytují, protože:

neexistuje žádná režie transakce:

Mnohem rychleji

Nižší požadavky na místo na disku

K provádění aktualizací je potřeba méně paměti

Každá tabulka MyISAM je uložena na disku ve třech souborech. Soubory mají názvy, které začínají názvem tabulky a mají příponu označující typ souboru. Soubor .frm ukládá formát tabulky. Datový soubor má příponu .MYD (MYData). Indexový soubor má příponu .MYI (MYIndex).

Tyto soubory mohou být zkopírován do neporušeného úložiště bez použití funkce MySQL Administrators Backup, což je časově náročné (stejně jako obnovení)

Trik je vytvořit kopii těchto souborů a pak tabulku DROP. Když vložíte soubory zpět, MySQl je rozpozná a aktualizuje sledování tabulky.

Pokud musíte zálohovat/obnovit,

Obnova zálohy nebo import z existujícího souboru výpisu může trvat dlouho v závislosti na počtu indexů a primárních klíčů, které máte v každé tabulce. Tento proces můžete výrazně urychlit úpravou původního souboru výpisu tak, že jej obklopíte následujícím:

SET AUTOCOMMIT = 0;
SET FOREIGN_KEY_CHECKS=0;

.. your dump file ..

SET FOREIGN_KEY_CHECKS = 1;
COMMIT;
SET AUTOCOMMIT = 1;

Chcete-li výrazně zvýšit rychlost opětovného načítání, přidejte příkaz SQL SET AUTOCOMMIT =0; na začátek souboru výpisu a přidejte COMMIT; příkaz do konce.

Ve výchozím nastavení je automatické potvrzení zapnuto, což znamená, že každý příkaz vložení do souboru výpisu bude považován za samostatnou transakci a zapsán na disk před spuštěním dalšího. Pokud tyto příkazy nepřidáte, opětovné načtení velké databáze do InnoDB může trvat mnoho hodin...

Maximální velikost řádku v tabulce MySQL je 65 535 bajtů

Efektivní maximální délka VARCHAR v MySQL 5.0.3 a dále =maximální velikost řádku (65 535 bajtů)

Hodnoty VARCHAR nejsou při ukládání doplněny. Koncové mezery jsou zachovány při ukládání a načítání hodnot v souladu se standardním SQL.

Hodnoty CHAR a VARCHAR v MySQL se porovnávají bez ohledu na koncové mezery.

Použití CHAR urychlí váš přístup pouze v případě, že má celý záznam pevnou velikost. To znamená, že pokud použijete jakýkoli objekt s proměnnou velikostí, můžete je také nastavit jako proměnnou velikost. Použitím CHAR v tabulce, která také obsahuje VARCHAR, nezískáte žádnou rychlost.

Limit VARCHAR 255 znaků byl od MySQL 5.0.3 zvýšen na 65535 znaků

Fulltextové vyhledávání je podporováno pouze u tabulek MyISAM.

http://dev.mysql.com/doc/refman /5.0/cs/fulltext-search.html

Sloupce BLOB nemají žádnou znakovou sadu a řazení a porovnání jsou založeny na číselných hodnotách bajtů v hodnotách sloupců

Pokud není povolen přísný režim SQL a sloupci BLOB nebo TEXT přiřadíte hodnotu, která přesahuje maximální délku sloupce, hodnota se zkrátí, aby se vešla, a vygeneruje se varování.

Užitečné příkazy:

zkontrolujte přísný režim:SELECT @@global.sql_mode;

vypnout přísný režim:

SET @@global.sql_mode='';

SET @@global.sql_mode='MYSQL40'

nebo remove:sql-mode="STRICT_TRANS_TABLES,...

ZOBRAZIT SLOUPCE Z mytable

SELECT max(namecount) AS virtualcolumn Z mytable ORDER BY virtualcolumn

http://dev.mysql.com /doc/refman/5.0/en/group-by-hidden-fields.html

http://dev.mysql .com/doc/refman/5.1/en/information-functions.html#function_last-insert-id last_insert_id()

získá PK posledního řádku vloženého do aktuálního vlákna max(pkcolname) získá celkově poslední PK.

Poznámka:pokud je tabulka prázdná, max(pkcolname) vrátí 1 mysql_insert_id() převede návratový typ nativní funkce MySQL C API mysql_insert_id() na typ oflong (v PHP pojmenovaný int).

Pokud má váš sloupec AUTO_INCREMENT typ sloupce BIGINT, hodnota vrácená mysql_insert_id() bude nesprávná. Místo toho použijte v dotazu SQL interní funkci MySQL SQL LAST_INSERT_ID().

http://dev.mysql .com/doc/refman/5.0/en/information-functions.html#function_last-insert-id

Jen poznamenejte, že když se pokoušíte vložit data do tabulky, zobrazí se chyba:

Unknown column ‘the first bit of data what you want to put into the table‘ in ‘field list’

pomocí něčeho jako

INSERT INTO table (this, that) VALUES ($this, $that)

je to proto, že kolem hodnot, které se snažíte vložit do tabulky, nemáte žádné apostrofy. Měli byste tedy změnit svůj kód na:

INSERT INTO table (this, that) VALUES ('$this', '$that') 

připomíná, že `` se používají k definování polí MySQL, databází nebo tabulek, nikoli hodnot;)

Ztracené připojení k serveru během dotazu:

http://dev.mysql.com/doc/refman /5.1/en/gone-away.html

http://dev.mysql.com/doc /refman/5.1/cs/packet-too-large.html

http://dev.mysql.com/doc/refman /5.0/en/server-parameters.html

http://dev.mysql.com/doc/refman /5.1/cs/show-variables.html

http://dev.mysql.com/doc/refman /5.1/cs/option-files.html

http://dev.mysql.com/doc/refman /5.1/cs/error-log.html

Dotazy na ladění

http://www.artfulsoftware.com/infotree/queries.php?&bw =1313

Myslím, že by to mělo stačit k získání bonusu... Plody mnoha hodin a mnoha projektů se skvělým zdarma databáze. Vyvíjím aplikační datové servery na platformách Windows převážně s MySQL. Nejhorší nepořádek, který jsem musel narovnat, byl

Nejlepší noční můra starší databáze MySQL

To vyžadovalo řadu aplikací ke zpracování tabulek do něčeho užitečného pomocí mnoha zde zmíněných triků.

Pokud to považujete za úžasně užitečné, vyjádřete své díky hlasováním.

Podívejte se také na mé další články a bílé knihy na:www.coastrd.com