Тъй като сте поставили награда, ще споделя моите трудно спечелени тайни...
Като цяло, всички SQLs, които настроих днес, изискваха използване на подзаявки. След като идвам от света на базата данни на Oracle, нещата, които приемах за даденост, не работеха по същия начин с MySQL. И моето четене за настройката на MySQL ме кара да заключа, че MySQL стои зад Oracle по отношение на оптимизирането на заявките.
Докато простите заявки, необходими за повечето B2C приложения, могат да работят добре за MySQL, повечето от обобщените заявки за отчитане, необходими за Intelligence Reporting, изглежда изискват малко планиране и реорганизиране на SQL заявките, за да насочат MySQL да ги изпълнява по-бързо.
Администриране:
max_connections е броят на едновременните връзки. Стойността по подразбиране е 100 връзки (151 от 5.0) - много малко.
Забележка:
връзките отнемат памет и вашата ОС може да не е в състояние да се справи с много връзки.
MySQL двоични файлове за Linux/x86 ви позволяват да имате до 4096 едновременни връзки, но самокомпилираните двоични файлове често имат по-малко ограничение.
Задайте table_cache, за да съответства на броя на вашите отворени таблици и едновременни връзки. Гледайте стойността на open_tables и ако расте бързо, ще трябва да увеличите размера му.
Забележка:
Предходните 2 параметъра може да изискват много отворени файлове. 20+max_connections+table_cache*2 е добра оценка за това, от което се нуждаете. MySQL на Linux има опция open_file_limit, задайте това ограничение.
Ако имате сложни заявки sort_buffer_size и tmp_table_size вероятно ще бъдат много важни. Стойностите ще зависят от сложността на заявката и наличните ресурси, но 4Mb и 32Mb съответно са препоръчителни отправни точки.
Забележка:Това са стойности "на връзка", сред read_buffer_size, read_rnd_buffer_size и някои други, което означава, че тази стойност може да е необходима за всяка връзка. Така че, имайте предвид натоварването и наличния ресурс, когато задавате тези параметри. Например sort_buffer_size се разпределя само ако MySQL трябва да извърши сортиране. Забележка:внимавайте да не останете без памет.
Ако имате установени много връзки (т.е. уеб сайт без постоянни връзки), можете да подобрите производителността, като зададете thread_cache_size на стойност, различна от нула. 16 е добра стойност за начало. Увеличете стойността, докато вашите threads_created не нарастват много бързо.
ПЪРВИЧЕН КЛЮЧ:
Може да има само една колона AUTO_INCREMENT на таблица, тя трябва да бъде индексирана и не може да има стойност ПО ПОДРАЗБИРАНЕ
KEY обикновено е синоним на INDEX. Ключовият атрибут PRIMARY KEY може също да бъде определен като просто KEY, когато е даден в дефиниция на колона. Това беше внедрено за съвместимост с други системи за бази данни.
ПЪРВИЧНИЯ КЛЮЧ е уникален индекс, където всички ключови колони трябва да бъдат дефинирани като НЕ NULL
Ако индекс на PRIMARY KEY или UNIQUE се състои само от една колона, която има целочислен тип, можете също да се обърнете към колоната като „_rowid“ в изразите SELECT.
В MySQL името на ПЪРВИЧЕН КЛЮЧ е PRIMARY
Понастоящем само таблици InnoDB (v5.1?) поддържат външни ключове.
Обикновено създавате всички индекси, от които се нуждаете, когато създавате таблици. Всяка колона, декларирана като PRIMARY KEY, KEY, UNIQUE или INDEX, ще бъде индексирана.
NULL означава "няма стойност". За да тествате за NULL, не можете използвайте операторите за аритметично сравнение като =, <или <>. Вместо това използвайте операторите IS NULL и IS NOT NULL:
NO_AUTO_VALUE_ON_ZERO потиска автоматичното увеличение за 0, така че само NULL генерира следващия пореден номер. Този режим може да бъде полезен, ако 0 е съхранено в колоната AUTO_INCREMENT на таблицата. (Между другото, съхраняването на 0 не е препоръчителна практика.)
За да промените стойността на брояча AUTO_INCREMENT, който да се използва за нови редове:
ALTER TABLE mytable AUTO_INCREMENT = value;
или SET INSERT_ID =стойност;
Освен ако не е посочено друго, стойността ще започва с:1000000 или ще я укажете по следния начин:
...) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1
ПЕЧЕТИ ВРЕМЕ:
Стойностите за колоните TIMESTAMP се преобразуват от текущата часова зона в UTC за съхранение и от UTC в текущата часова зона за извличане.
http://dev.mysql.com/doc/refman/5.1 /bg/timestamp.html За една колона TIMESTAMP в таблица можете да зададете текущото времеви печат като стойност по подразбиране и стойността за автоматично актуализиране.
едно нещо, за което трябва да внимавате, когато използвате един от тези типове в клауза WHERE, най-добре е да направите WHERE datecolumn =FROM_UNIXTIME(1057941242) и notWHERE UNIX_TIMESTAMP(datecolumn) =1057941242. извършването на последното няма да се възползва от това предимство на индекса колона.
http://dev.mysql.com /doc/refman/5.1/en/date-and-time-functions.html
UNIX_TIMESTAMP()
FROM_UNIXTIME()
UTC_DATE()
UTC_TIME()
UTC_TIMESTAMP()
ако конвертирате дата и час в unix timestamp в MySQL:
И след това добавите 24 часа към него:
И след това го преобразувате обратно в дата и час, той магически губи един час!
Ето какво се случва. Когато преобразуваме unix timestamp обратно в дата и час, часовата зона се взема предвид и се случва така, че между 28-ми и 29-ти октомври 2006 г. сме излезли от лятното часово време и загубихме един час.
Започвайки с MySQL 4.1.3, функциите CURRENT_TIMESTAMP(), CURRENT_TIME(), CURRENT_DATE() и FROM_UNIXTIME() връщат стойности в текущата часова зона на връзката , което е налично като стойност на системната променлива time_zone. Освен това UNIX_TIMESTAMP() приема, че неговият аргумент е стойност за дата и час в текущата часова зона.
Текущата настройка на часовата зона не засяга стойностите, показвани от функции като UTC_TIMESTAMP() или стойности в колони DATE, TIME или DATETIME.
ЗАБЕЛЕЖКА:ПРИ АКТУАЛИЗИРАНЕ САМО актуализира DateTime, ако полето е променено Ако UPDATE не води до промяна на полета, тогава DateTime НЕ се актуализира!
Освен това първият TIMESTAMP винаги е AUTOUPDATE по подразбиране, дори ако не е посочен
Когато работя с дати, почти винаги се придържам към Julian Date, тъй като математиката на данните е прост въпрос на добавяне или изваждане на цели числа и секунди от полунощ по същата причина. Рядко се случва да имам нужда от времево разрешение с по-фина детайлност от секунди.
И двете могат да се съхраняват като цяло число от 4 байта и ако пространството е наистина ограничено, могат да се комбинират във времето на UNIX (секунди от епохата 1/1/1970) като цяло число без знак, което ще бъде добро до около 2106 като:
' секунди за 24 часа =86400
' Цело число със знак max val =2,147,483,647 - може да задържи 68 години секунди
' Unsigned Integer max val =4,294,967,295 - може да съдържа 136 години секунди
Двоичен протокол:
MySQL 4.1 въведе двоичен протокол, който позволява стойности на данни, които не са низови, да бъдат изпращани и връщани в естествен формат без преобразуване към и от низов формат. (Много полезно)
Освен това mysql_real_query() е по-бърз от mysql_query(), защото не извиква strlen() за работа с низа на инструкцията.
http://dev.mysql.com/tech-resources /articles/4.1/prepared-statements.html Двоичният протокол поддържа подготвени оператори от страна на сървъра и позволява предаване на стойности на данни в естествен формат. Двоичният протокол претърпя доста ревизия по време на по-ранните версии на MySQL 4.1.
Можете да използвате макроса IS_NUM(), за да тествате дали полето има числов тип. Предайте стойността на типа на IS_NUM() и тя се оценява на TRUE, ако полето е числово:
Едно нещо, което трябва да се отбележи, е, че двоичните данни МОЖАТ да бъде изпратен в обикновена заявка, ако я избягате и не забравяйте, че MySQL изисква само тази обратна наклонена черта и символът за кавички да бъдат екранирани. Така че това е наистина лесен начин за ВМЕСВАНЕ на по-къси двоични низове, като например криптирани/солени пароли.
Главен сървър:
http://www.experts-exchange.com/Database/MySQL/Q_22967482 .html
http://www.databasejournal.com/features/mysql/article.php /10897_3355201_2
ПРЕДОСТАВЯНЕ НА РЕПЛИКАЦИЯ НА . до slave_user ИДЕНТИФИЦИРАН ОТ '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
Двоичният регистрационен файл трябва да чете:
http://dev.mysql.com/doc/refman /5.0/bg/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 /bg/mysqlbinlog.html
http://dev.mysql.com/doc/refman /5.0/bg/binary-log.html
http://dev.mysql.com/doc /refman/5.1/en/binary-log-setting.html
Можете да изтриете всички двоични регистрационни файлове с оператора RESET MASTER или подмножество от тях с PURGE MASTER
--result-file=binlog.txt TrustedFriend-bin.000030
Нормализация:
http://dev.mysql.com/tech-resources /articles/intro-to-normalization.html
UDF функции
http://www.koders.com/cpp/fid106218C03DDF106218C000000000000000.
http://souptonuts.sourceforge.net/readme_mysql.htm
Типове данни:
http://dev.mysql.com/doc/refman /5.1/bg/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/
Едно нещо, което трябва да се отбележи е, че на смесена таблица с CHAR и VARCHAR, mySQL ще промени CHAR на VARCHAR
RecNum integer_type UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (RecNum)
MySQL винаги представлява дати с годината първа, в съответствие със стандартните SQL и ISO 8601 спецификации
Разни:
Изключването на някои функции на MySQl ще доведе до по-малки файлове с данни и по-бърз достъп. Например:
--datadir ще посочи директорията с данни и
--skip-innodb ще изключи опцията inno и ще ви спести 10-20 милиона
Повече тукhttp://dev.mysql.com/tech -resources/articles/mysql-c-api.html
Изтеглете глава 7 - безплатно
InnoDB е транзакционен, но има допълнителни разходи за производителност, които идват с него. Открих, че MyISAM таблиците са достатъчни за 90% от моите проекти. Таблиците, които не са безопасни за транзакции (MyISAM) имат няколко собствени предимства, всички от които възникват, защото:
няма режийни разходи за транзакции:
Много по-бързо
По-ниски изисквания за дисково пространство
По-малко памет е необходима за извършване на актуализации
Всяка таблица MyISAM се съхранява на диск в три файла. Файловете имат имена, които започват с името на таблицата и имат разширение, за да посочат типа на файла. .frm файл съхранява формата на таблицата. Файлът с данни има разширение .MYD (MYData). Индексният файл има разширение .MYI (MYIndex).
Тези файлове могат да бъде копиран на място за съхранение непокътнато, без да се използва функцията за архивиране на MySQL администратори, която отнема много време (както и възстановяването)
Номерът е да направите копие на тези файлове и след това да ПУСКАТЕ таблицата. Когато поставите файловете обратно, MySQl ще ги разпознае и ще актуализира проследяването на таблицата.
Ако трябва да архивирате/възстановявате,
Възстановяването на резервно копие или импортирането от съществуващ дъмп файл може да отнеме много време в зависимост от броя на индексите и първичните ключове, които имате във всяка таблица. Можете да ускорите този процес драстично, като модифицирате оригиналния си дъмп файл, като го обградите със следното:
SET AUTOCOMMIT = 0;
SET FOREIGN_KEY_CHECKS=0;
.. your dump file ..
SET FOREIGN_KEY_CHECKS = 1;
COMMIT;
SET AUTOCOMMIT = 1;
За да увеличите значително скоростта на презареждане, добавете SQL командата SET AUTOCOMMIT =0; в началото на дъмп файла и добавете COMMIT; команда до края.
По подразбиране autocommit е включен, което означава, че всяка команда за вмъкване в дъмп файла ще бъде третирана като отделна транзакция и записана на диск, преди да бъде стартирана следващата. Ако не добавите тези команди, презареждането на голяма база данни в InnoDB може да отнеме много часове...
Максималният размер на ред в MySQL таблица е 65 535 байта
Ефективната максимална дължина на VARCHAR в MySQL 5.0.3 и on =максимален размер на реда (65 535 байта)
Стойностите VARCHAR не се допълват, когато се съхраняват. Крайните интервали се запазват, когато стойностите се съхраняват и извличат, в съответствие със стандартния SQL.
Стойностите CHAR и VARCHAR в MySQL се сравняват без оглед на крайните интервали.
Използването на CHAR ще ускори достъпа ви само ако целият запис е с фиксиран размер. Тоест, ако използвате обект с променлив размер, можете също да направите всички от тях с променлив размер. Вие не печелите скорост, като използвате CHAR в таблица, която също съдържа VARCHAR.
Ограничението VARCHAR от 255 знака беше повишено до 65535 знака от MySQL 5.0.3
Търсенето в пълен текст се поддържа само за MyISAM таблици.
http://dev.mysql.com/doc/refman /5.0/bg/fulltext-search.html
BLOB колоните нямат набор от знаци, а сортирането и сравнението се основават на числовите стойности на байтовете в стойностите на колоните
Ако стриктният SQL режим не е активиран и присвоите стойност на колона BLOB или TEXT, която надвишава максималната дължина на колоната, стойността се съкращава, за да пасне и се генерира предупреждение.
Полезни команди:
проверете строг режим:SELECT @@global.sql_mode;
изключете строг режим:
SET @@global.sql_mode='';
SET @@global.sql_mode='MYSQL40'
или премахнете:sql-mode="STRICT_TRANS_TABLES,...
ПОКАЖЕТЕ КОЛОНИ ОТ mytable
SELECT max(namecount) AS virtualcolumn ОТ mytable ORDER BY виртуална колона
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()
ви получава PK на последния ред, вмъкнат в текущата нишка max(pkcolname) получава ви последния PK като цяло.
Забележка:ако таблицата е празна, max(pkcolname) връща 1 mysql_insert_id() преобразува типа на връщане на собствената MySQL C API функция mysql_insert_id() в тип long (с име int в PHP).
Ако вашата колона AUTO_INCREMENT има тип колона BIGINT, стойността, върната от mysql_insert_id(), ще бъде неправилна. Вместо това използвайте вътрешната MySQL SQL функция LAST_INSERT_ID() в SQL заявка.
http://dev.mysql .com/doc/refman/5.0/en/information-functions.html#function_last-insert-id
Само имайте предвид, че когато се опитвате да вмъкнете данни в таблица и получавате грешката:
Unknown column ‘the first bit of data what you want to put into the table‘ in ‘field list’
използвайки нещо като
INSERT INTO table (this, that) VALUES ($this, $that)
това е, защото нямате апострофи около стойностите, които се опитвате да залепите в таблицата. Така че трябва да промените кода си на:
INSERT INTO table (this, that) VALUES ('$this', '$that')
напомняне, че `` се използват за дефиниране на MySQL полета, бази данни или таблици, а не стойности;)
Загубена връзка със сървъра по време на заявка:
http://dev.mysql.com/doc/refman /5.1/bg/gone-away.html
http://dev.mysql.com/doc /refman/5.1/en/packet-too-large.html
http://dev.mysql.com/doc/refman /5.0/bg/server-parameters.html
http://dev.mysql.com/doc/refman /5.1/bg/show-variables.html
http://dev.mysql.com/doc/refman /5.1/bg/option-files.html
http://dev.mysql.com/doc/refman /5.1/bg/error-log.html
Заявки за настройка
http://www.artfulsoftware.com/infotree/queries.php?&bw =1313
Е, това трябва да е достатъчно, за да спечелите бонуса, мисля... Плодовете на много часове и много проекти със страхотно безплатно база данни. Разработвам сървъри за данни на приложения на платформи на Windows предимно с MySQL. Най-лошата бъркотия, която трябваше да оправя, беше
Най-добрият кошмар за наследена база данни на MySQL
Това изисква серия от приложения за обработка на таблиците в нещо полезно, като се използват много от триковете, споменати тук.
Ако сте намерили това удивително полезно, изразете благодарността си, като гласувате за него.
Разгледайте и другите ми статии и бели книги на:www.coastrd.com
