Изпечатай

[Naka]

В една от таблиците имам поле description_short което е char(144), но е малко и трябва да го увеличавам на 320.

CREATE TABLE `snimki` (
  `id` int(10) unsigned NOT NULL auto_increment,
...
  `description_short` char(144) NOT NULL default '',
...
) ENGINE=MyISAM

Но в цялата тази таблица всички полета са с фиксирана големина. char(144) също е фиксирано поле - незвисимо колко записваш винаги заделя 144 символа Т.е. всеки ред в таблицата е с точно определена големина.

Mysql вътрешно прави два вида таблици - DYNAMIC или FIXED
https://dev.mysql.com/doc/refman/5.6/en/static-format.html
https://dev.mysql.com/doc/refman/5.6/en/dynamic-format.html

Статичната таблица има предимства, че е по бърза - по лесно енджина достъпва до реда, не се дефрагментира и по устойчива на разваляне и евентуално възтановяване.
В случая mysql е направил статична таблица на snimki.
Какъв вид таблица е направил може да се види с командата show table status;

Проблема е, че char() e до 255 а на мен ми трябва 320. Но ако го променя на varchar(320), тогава mysql-a като види varchar() автоматично прави динамична таблица.

ALTER TABLE snimki MODIFY description_short varchar(320) NOT NULL default '';

Има и друг вариан. Може твърдо да се укаже, каква таблица да направи с ROW_FORMAT = FIXED даже и при varchar(). Заети, не заети, всички символи до 320 вътрешно ги пад-ва с паузи до 320. Ще има малко излишък на ненужни байтове. таблицата като файл ще стане по-голяма, но затова пък ще е статична.

ALTER TABLE snimki MODIFY description_short ROW_FORMAT = FIXED, varchar(320) NOT NULL default '';

Кой от двата варянта да избера. Така както е по-default с динамична таблица и varchar(320) и много, много да не са замислям как енджина ще записва данните
или
малко да го поизнасиля с ROW_FORMAT = FIXED и varchar(320)? От друга страна това не е хакерски подход ами си е описано в документацията като възможност.


 

[4096bits]

Не съм се занимавал с SQL обаче покрай едно приятелче, дето му бяха взели здравето в училище с това, малко понаучих.

Защо не използваш две свързани таблици? Едната да си е статична, другата динамична

[Naka]

Защо не използваш две свързани таблици? Едната да си е статична, другата динамична

Това е така, но системата отдавна е изградена. Промяна в структурата на таблиците, ще означава и промяна в програмата.

[spec1a]

   Защо не направиш нова таблица ,примерно snimki2 ,със същата
структура като snimki ,само полето description_short да е
голямо колкото искаш.
   Наливаш данните от snimki във snimki2,после изтриваш snimki,
преименуваш snimki2 на snimki (RENAME TABLE ...) и си на шест.



П.С.
Защо:

ENGINE=MyISAM

?

[go_fire]

П.С.
Защо:

ENGINE=MyISAM

?

Бързина? Бързина?! Бързина??? Бързина ?!?

Логично, а?

[Naka]

   Защо не направиш нова таблица ,примерно snimki2 ,със същата
структура като snimki ,само полето description_short да е
голямо колкото искаш.
   Наливаш данните от snimki във snimki2,после изтриваш snimki,
преименуваш snimki2 на snimki (RENAME TABLE ...) и си на шест.

ALTER TABLE snimki MODIFY description_short ....
Точно това прави вътрешно. Казваш му да модифицира само едно поле, но mysql-а вътрешно прави нова tmp таблица, като копира всички данни от старата с модифицираните полета, след това преименува тмп таблицата и изтрива старата.

Нямам проблем никакъв с промяната на полето на varchar().

[spec1a]

/// ъъъ,офтопик

П.С.
Защо:

ENGINE=MyISAM

?

Бързина? Бързина?! Бързина??? Бързина ?!?

Логично, а?

   Май си станал с гъза нагоре ...

[Naka]

Защо:
ENGINE=MyISAM

makeme преди време разправяше, че InnoDB таблиците много лесно се чупят, па и трудно се поправят след това.
Докато аз лично също не съм виждал MyISAM таблица да прави проблеми.
Е не MyISAM релационна база ама с подходящо програмиране и заключвания, може да се постигне почти същия ефект.

[go_fire]

Май-исами не може да се репликира и няма второстепенен ключ (foreign key). Ама иначе е убиец. Цепи мрака по скорост, а, както казваш, няма оплаквания от стабилност и скалируемост.

[spec1a]

Защо:
ENGINE=MyISAM

makeme преди време разправяше, че InnoDB таблиците много лесно се чупят, па и трудно се поправят след това.
Докато аз лично също не съм виждал MyISAM таблица да прави проблеми.
Е не MyISAM релационна база ама с подходящо програмиране и заключвания, може да се постигне почти същия ефект.

   Дoсега не съм виждал "счупена" таблица в MySql.
Разбира се,може понякога и да има някакви проблеми със InnoDB,
но предимствата на този тип таблици са по-големи.
   Аз лично джиткам със master/slave replication и досега не съм имал проблеми.
Дори и нещо да се прецака,винаги имам актуален бекъп...
Отделно всеки ден пускам и ръчно бекъпи (mysqldump ...).

[makeme]

Че се чупят, чупят се, но инструмента на mysqla си ги оправя. Това за което ставаше въпрос в една друга тема е при миграцията на целия сървър. InnoDB не е по бавен, дори на теория трябва да е по-бърз заради кешовете и другите шитни дето предлага. Именно и те се чупят при миграцията Аз лично съветвам хората да ползват MyISam понеже е по прост, но ако си някакъв MySql гуру и после можеш да си оправиш нещата, а не да пищиш че нещо не работи, go for it.
До колкото помня човека накрая си плати на някое гуру и той му оправи базите.

[remotexx]

Ако е малка таблицата хич не се замисляй ами го слагай направо varchar (освен ако не счупи нещо там по някой много дърт  GUI контрол), то вече и ако е голяма пак бих го сложил - ще натовари малко повече CPU при изчисляване на плана на заявката но какво от това (това последното при положение че достъпът е последователен макар и при големи обеми обеми на данни - при малко данни няма обсолютно никакво значение, има значение само при голяма БД (ГБ, ТБ) и четене на много (или малко) случайни редове

Ако се чете последователно също няма значение - то ще направи няколко опита да намери началната страница и оттам чете последователно - ако не ги чете/търси по реда на записване (или по някой индекс) и ако таблицата е големичка тогава вече трябва да с направи проба

Хубаво е то време на време да се пуща OPTIMIZE TABLE - особ. за динамични таблици
https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html

https://www.thegeekstuff.com/2016/04/mysql-optimize-table/

П.П. И много внимавай че някой много дърти контроли наистина може да са ограничени до 255 символа 

[spec1a]

Че се чупят, чупят се, но инструмента на mysqla си ги оправя. Това за което ставаше въпрос в една друга тема е при миграцията на целия сървър. InnoDB не е по бавен, дори на теория трябва да е по-бърз заради кешовете и другите шитни дето предлага. Именно и те се чупят при миграцията Аз лично съветвам хората да ползват MyISam понеже е по прост, но ако си някакъв MySql гуру и после можеш да си оправиш нещата, а не да пищиш че нещо не работи, go for it.
До колкото помня човека накрая си плати на някое гуру и той му оправи базите.

   Е то излиза,че и аз съм MySQL гуру.
Какви ли не миграции съм правил,но досега нищо не се е чупило.
Или - чист късмет ...
Праскам mysqldump база по база,и после ги ресторвам.
Гледам да съвпадат MySQL версиите,или по-ниска на малко по-висока.
Избягвам да смесвам MySQL и MariaDB ,има много мотики за настъпване ...

[Naka]

Ако е малка таблицата хич не се замисляй ами го слагай направо varchar

При всички случаи слагам varchar(320). Въпросът беше че в единият случай слагам varchar(320) с динамична таблица (по-default)
а в другият случай слагам varchar(320) с ROW_FORMAT = FIXED - т.е таблицата по малко ще се дефрагментира, за сметка на излишни байтове.....

Но малка е таблицата и най-вероятно ще го направя с varchar(320) и с ROW_FORMAT = FIXED
Голям праз ще ще има празни байтове Евентуално, може да се получи проблем при много големи таблици, защото така файла ще нарастне твърде много (в сравнение е динамичния)...Четенето на голям файл, може вече да има негативен ефект....Ама не се се знае.

Праскам mysqldump база по база,и после ги ресторвам.

С mysqldump няма какво да се обърка. Това не е копиране на бинарните таблици ами си е чист експорт в текстов SQL.  Би трябвало да е устойчиво и при смяна на версиите на mysql-a. Но досега не съм се пробвал.

И аз го правя с mysqldump. Само че имам скрипт -веб интерфейс.

[jet]

Че се чупят, чупят се, но инструмента на mysqla си ги оправя. Това за което ставаше въпрос в една друга тема е при миграцията на целия сървър. InnoDB не е по бавен, дори на теория трябва да е по-бърз заради кешовете и другите шитни дето предлага. Именно и те се чупят при миграцията Аз лично съветвам хората да ползват MyISam понеже е по прост, но ако си някакъв MySql гуру и после можеш да си оправиш нещата, а не да пищиш че нещо не работи, go for it.
До колкото помня човека накрая си плати на някое гуру и той му оправи базите.

   Е то излиза,че и аз съм MySQL гуру.
Какви ли не миграции съм правил,но досега нищо не се е чупило.
Или - чист късмет ...
Праскам mysqldump база по база,и после ги ресторвам.
Гледам да съвпадат MySQL версиите,или по-ниска на малко по-висока.
Избягвам да смесвам MySQL и MariaDB ,има много мотики за настъпване ...

InnoDB може да се счупи ако "миграторите" копират базите като файлове (както правят "админите" при MSSQL- паднах от коня като го видях това). Ако си използваш mysqldump нещата са си нативни и няма какво да се счупи (освен ако не ти е счупен хардуера).