|
Много от програмистите използват грешни типове на полетата при създаване на таблици в MySQL, което в последствие се отразява на бързината на заявките. За да се предотвратят следни ситуации, съм събрал няколко съвета, които са изпробвани и работят добре.
1. SIGNED или UNSIGNED? За хора, които не знаят каква е разликата между двете, ето едно кратко обяснение: За числа използващи SIGNED, се запазва един Bit за да може числата да се представят като отрицателни. Чрез UNSIGNED, числата могат да бъдат единствено положителни и по този начин се спрестява този Bit. Ако например сте избрали SIGNED INT, то тогава може да запаметявате числа от -2,147,483,648 до 2,147,483,647, но ако използвате UNSIGNED, то обхвата на числата, които може да запаметявате е от 0 до 4,294,967,295. Сами трябва да си направите сметка дали ще имате отрицателни числа, ако не - използваите винаги UNSIGNED. За поле, което ще е auto_increment, използвайте винаги UNSIGNED! 2. Колко голямо да бъде полето? Много програмисти поставят големината на числата произволно без да си задават въпроса, дали толкова голям обхват е необходим. Ако имаме примерно една малка страничка и сме си направили таблицата MEMBER с primary key UNSIGNED INT, то тогава веднага трябва да си зададем въпроса - "Ще имам ли някога 4,294,967,295 потребителя?". Винаги трявба да си задавате въпроса, дали ще достигнете изобщо до числата, които сте задали като обхват, преди да изберете произволна стойност. Но защо изобщо да се съобразяваме с това? Нека разгледаме следния пример: В таблицата по долу виждате Байтовете, които се заемат от всеки ред за запаметяване на подаденото от вас число. Ако вие сте избрали UNSIGNED INT, то вие резервирате 4 Byte на ред. Ако да кажем след определено време вие имате няколко милиона реда, умножени по тези Байтове, то вие получавате една прилична големина на таблицата. Представете си, че вие никога няма да достигнете тези 4,294,967,295 и поради тази причина променим типа на полето на UNSIGNED MEDIUMINT, вие моментално спестявате по 1 Byte от всеки ред, което има огромно значение в таблици от рода на GB-тове. Това ще намали веднага големината на самата таблица и на нейния индекс.  3. CHAR или VARCHAR В полета с типове CHAR и VARCHAR се запаметяват не много дълги низове. Но кое от тях да изберем, ако искаме да запаметим примерно Email-а на нашия потребител. Правилният избор тук е VARCHAR, защото този тип поле е динамично и тъй като всеки Email има различна дължина, то ние за всеки ред ще имаме различен на брой заети Байтове. Ако зададем примерно CHAR, с някаква дължина, примерно 200, то тогава резервираме моментално 200 Байта на ред и дори Email-а да е само 50 знака, то ние сме резервирали 200, което носи загуба от 150 Байта. Умножено по няколко хиляди реда, се превръща в един огромен излишък на запазено пространство. Кога да използваме CHAR? Тогава, когато имаме винаги еднаква дължина на низа, примерно при запаметяване на MD5 низове, ако искаме да си кодираме паролата или да запаметим дадена сесия, която също винаги има еднаква дължина. 4. Запаметяване на IP адреси. Много хора запаметяват IP адресите в полета от тип VARCHAR. Това разбира се става, но не е най-добрият и пестелив начин. Ако решите да претърсвате едно такова поле или евентуално да го сортирате, то ще ви коства много ресурси и време. Да не говорим, ако искате да сложите индекс върху това поле, то тогава ще ви отнеме много пространство. Какво можем да направим? Ще запаметяваме адреса в поле от тип UNSIGNED INT. MySQL предлага функциите INET_ATON() и INET_NTOA(), които преобразуват един IP адрес в цяло число и обратно. Ако използвате PHP, то тогава може да използвате също тези функции ip2long() и long2ip(). Каво спестяваме в случая? Спестяваме около 10-тина Байта от всеки ред и имаме възможноста да претърсваме и сортираме бързо. 5. Избор на правилния тип за дата Съществуват няколко типа за дата:
но кой точно да използваме в нашата таблица? Ето един много важен съвет - може би малко хора го знаят: Ако трябва да запаметявате дати след 1.1.1970, то тогава използвайте типа TIMESTAMP, без опцията ON UPDATE CURRENT_TIMESTAMP, тъй като той изразходва само 4 Байта, като за същото нещо DATETIME изразходва 8 Байта! Сами виждате, че изразходеното пространство е двойно, само защото не се внимава! Другите типове говорят сами за себеси. Ако ви трявба само датата, без часа, тогава използвайте винаги DATE, тъй като този тип извазходва само 3 Байта. Като заключение мога да кажа, че е много важно да се планира и обмисля всяко поле в една таблица. Казвам го защото аз лично съм свидетел на подобни ситуации, при които, след като една таблица стигне то определена големина, говорим за GB-тове, то тогава дори една елементарна заявка не е възможна. След инвестиране на малко време се вижда, че при по-добро планиране, същата таблица би била 4-5 пъти по-малка.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||
