См. также - Mysql - обзор базы данных , основы,

Это окончание невероятной информации про mysql.

...

shell> replace " --" " #" -- text-file-with-funny-comments.sql

Замените их обратно этой командой:

shell> replace " #" " --" -- text-file-with-funny-comments.sql

1.2.5 Каким стандартам соответствует MySQL?

Entry level SQL92. ODBC levels 0-2.

1.2.6 Как обойтись без COMMIT/ROLLBACK

Следующее обычно применяется только для таблиц ISAM, MyISAM и HEAP. Если Вы используете только транзакционно-безопасные таблицы (BDB или InnoDB) в модификации, Вы можете также делать COMMIT и ROLLBACK в MySQL. Подробности в разделе "9.2.1 Синтаксис BEGIN/COMMIT/ROLLBACK".

Проблема с эффективной обработкой COMMIT-ROLLBACK с вышеупомянутыми типами таблиц требует полностью иного размещения таблицы, чем используемое MySQL сегодня. Тип таблицы также нуждался бы в дополнительных потоках, которые вели бы автоматические очистки на таблицах, да и использование дисков было бы намного выше. Это сделало бы эти типы таблицы приблизительно в 2-4 медленнее, чем они есть сейчас.

Текущей проблемой является ROLLBACK. Без ROLLBACK Вы можете делать любой вид COMMIT с помощью LOCK TABLES. Для поддержки ROLLBACK с вышеупомянутыми типами таблицы MySQL должен быть изменен так, чтобы сохранять все старые записи, которые модифицировались, и иметь возможность быстро вернуться к отправной точке, если была выдана команда ROLLBACK. Для простых случаев это довольно просто (можно приспособить сюда isamlog), но будет намного трудней выполнить ROLLBACK для ALTER/DROP/CREATE TABLE.

Чтобы избежать использования ROLLBACK, Вы можете использовать следующую стратегию действий:

1. Примените LOCK TABLES ..., чтобы блокировать все таблицы, к которым Вы хотите обращаться.
2. Проверьте все условия.
3. Модифицируйте, если все в порядке.
4. Вызовите команду UNLOCK TABLES, чтобы снять блокировки.

Это обычно намного более быстрый метод, чем использование транзакций с возможностью ROLLBACK, хотя и не всегда. Единственная ситуация, которую это решение не обрабатывает, состоит в том, что кто-то уничтожает поток в середине модификации. В этом случае все блокировки будут сняты, но некоторые из модификаций, возможно, не будут выполнены.

Вы можете также использовать функции, чтобы модифицировать записи в одиночной операции. Вы можете получать очень эффективную прикладную программу, применяя следующие методы:

• Измените поля относительно их текущего значения.
• Модифицируйте только те поля, которые фактически изменились.

Например, когда мы делаем модификации некоторой информации заказчика, мы модифицируем только данные заказчика, которые изменились, и проверяем, что ни один из измененных данных или других данных, которые зависят от измененных данных, не изменился по сравнению с первоначальной строкой. Тест для измененных данных выполнен с предложением WHERE в инструкции UPDATE. Если запись не модифицировалась, мы даем пользователю сообщение о том, что некоторые из данных, которые Вы изменили, были изменены другим пользователем. Затем мы показываем старую строку против новой строки в окне, так что пользователь может решать, которую версию записи заказчика он должен будет использовать.

Это дает нам нечто, что является подобным блокировке столбца, но фактически это даже лучше потому, что мы модифицируем только некоторые из столбцов, используя значения, которые вычислены относительно их текущих значений. Это означает, что типичные инструкции UPDATE выглядят примерно таким образом:

UPDATE tablename SET pay_back=pay_back+'relative change';
UPDATE customer SET customer_date='current_date',
                    address='new address', phone='new phone',
                    money_he_owes_us=money_he_owes_us+'new_money'
       WHERE customer_id=id AND address='old address' AND phone='old phone';

Как Вы можете видеть, это очень эффективно и работает, даже если другой пользователь изменил значения столбцов pay_back или money_he_owes_us.

Во многих случаях пользователи хотели использовать ROLLBACK и/или LOCK TABLES с целью управления уникальными идентификаторами для некоторых таблиц. Это может быть обработано намного более эффективно, используя столбец AUTO_INCREMENT и функцию SQL LAST_INSERT_ID() или функцию C API mysql_insert_id().

В MySQL AB авторы пакета никогда не имели никакой потребности в блокировке уровня строки потому, что всегда могли ее обойти. Некоторые случаи и в самом деле нуждаются в блокировке строки, но они очень немногочисленны. Если Вы хотите иметь блокировку уровня строки, Вы можете использовать столбец флажка в таблице и делать нечто вроде:

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

MySQL вернет для числа обработанных строк, если строка была найдена, и row_flag не был 1 в первоначальной строке.

1.2.7 Известные ошибки и проблемы

Перечисленные ниже проблемы известны авторам пакета, и их устранение имеет очень высокий приоритет.

• ANALYZE TABLE на таблицах BDB может в некоторых случаях делать таблицу непригодной, пока Вы не перезапустите mysqld. Когда это выполнено, Вы будете видеть ошибки подобные следующим в файле регистрации ошибок MySQL:

  001207 22:07:56 bdb: log_flush: LSN past current end-of-log
  

• Не выполняйте ALTER TABLE на таблице BDB, на которой Вы управляете незавершенными многооператорными транзакциями. Транзакция будет, вероятно, игнорироваться.
• ANALYZE TABLE, OPTIMIZE TABLE и REPAIR TABLE могут вызывать проблемы на таблицах, для которых Вы используете вызов INSERT DELAYED.
• Выполнение LOCK TABLE ... и FLUSH TABLES ... еще не гарантирует, что не имеется наполовину выполненной транзакции.
• Таблицы BDB не спешат открываться. Если Вы имеете много BDB-таблиц в базе данных, потребуется длительное время, чтобы использовать клиент mysql на этой базе данных, если Вы не используете опцию -A или применяете rehash. Это особенно важно, когда Вы имеете большой кэш таблицы.
• Текущий протокол репликации не может иметь дело с LOAD DATA INFILE и выравнивать символы признака конца строки, которые сами занимают больше, чем 1 символ.

Следующие проблемы известны и будут устранены в назначенное время:

• MATCH работает только с инструкциями SELECT.
• При использовании SET CHARACTER SET не могут быть применены транслируемые символы в базе данных, таблице и столбцах.
• DELETE FROM merge_table, используемый без WHERE, только очистит отображение для таблицы, не удаляя ничего в самих отображенных таблицах.
• Вы не можете формировать пакет в другом каталоге при использовании MIT-pthreads, поскольку это требует правки кода MIT-pthreads, мы вряд ли это свойство будем исправлять.
• Значения BLOB не могут надежно использоваться в GROUP BY, ORDER BY или DISTINCT. Только первые max_sort_length байт (по умолчанию 1024) используются при сравнении BLOB в этих случаях. Это может быть изменено с помощью опции -O max_sort_length при запуске mysqld. Обход для большинства случаев должен использовать подстроку: SELECT DISTINCT LEFT(blob,2048) FROM tbl_name.
• Вычисление выполнено с BIGINT или DOUBLE (оба обычно длиной в 64 бита). Это зависит от функции, которую обрабатывает пакет. Общее правило: битовые функции выполнены с точностью BIGINT, IF и ELT() с BIGINT или DOUBLE, а все прочие с DOUBLE. Нужно пробовать избегать использовать большие длинные значения без знака (9223372036854775807)!
• Все строковые столбцы, кроме BLOB и TEXT, автоматически удаляют все конечные пробелы, когда сохраняются. Для типа CHAR это разрешено и может быть расценено как свойство согласно ANSI SQL92. Ошибка в том, что в MySQL столбцы VARCHAR обрабатываются тем же самым путем.
• Вы можете иметь только до 255 столбцов типа ENUM и SET для каждой таблицы.
• safe_mysqld переназначает все сообщения mysqld в файл регистрации mysqld. Одна проблема с этим состоит в том, что, если Вы выполняете mysqladmin refresh, чтобы закрыть и вновь открыть файл регистрации, stdout и stderr все еще переназначаются к старому файлу регистрации. Если Вы используете опцию --log, Вы должны редактировать safe_mysqld, чтобы регистрировать данные в файле 'hostname'.err вместо 'hostname'.log, чтобы у Вас не было крупных проблем с запуском и работой с mysqladmin refresh.
• В инструкции UPDATE столбцы модифицируются слева направо. Если Вы обращаетесь к модифицируемому столбцу, Вы получите модифицируемое значение вместо первоначального значения. Например:

  mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;
  

  Это модифицирует KEY с 2 вместо 1.
• Вы не можете использовать временные таблицы больше, чем однажды в том же самом запросе. Например, следующее не будет работать:

  select * from temporary_table, temporary_table as t2;
  

• RENAME не работает с таблицами TEMPORARY.
• Оптимизатор может обрабатывать DISTINCT по-разному, если Вы используете скрытые столбцы в объединении или нет. В объединении скрытые столбцы рассчитаны как часть результата (даже если они не показаны) в то время, как в нормальном запросе они не участвуют в сравнении DISTINCT. Мы, вероятно, изменим это в будущем, чтобы никогда не сравнить скрытые столбцы при выполнении DISTINCT. Например:

  SELECT DISTINCT mp3id FROM band_downloads WHERE userid=9 ORDER BY id DESC;
  

  и

  SELECT DISTINCT band_downloads.mp3id, FROM band_downloads,band_mp3
         WHERE band_downloads.userid=9 AND band_mp3.id=band_downloads.mp3id
         ORDER BY band_downloads.id DESC;
  

  Во втором случае Вы можете в MySQL 3.23.x получить две идентичных строки в наборе результатов (потому, что скрытый столбец 'id' может отличаться). Обратите внимание, что это случается только для запросов, где Вы не имеете ORDER BY в результате, что вообще-то неправильно с точки зрения стандарта ANSI SQL.
• Поскольку MySQL позволяет Вам работать с типами таблиц, которые не поддерживают транзакции (и таким образом не могут выполнить rollback), некоторые вещи ведут себя немного иначе, чем в других серверах SQL. Это только должно гарантировать, что MySQL никогда не должен делать обратную перемотку для команд SQL. Это может быть иногда немного неуклюже, поскольку значения столбца должны проверяться прикладной программой, но это фактически даст Вам хорошее увеличение быстродействия, поскольку это позволяет MySQL делать некоторые оптимизации, которые иначе были бы невозможны или очень трудны. Если Вы устанавливаете столбец к неправильному значению, MySQL будет, вместо того, чтобы делать обратную перемотку, сохранять самое лучшее возможное значение в столбце.
  • Если Вы пробуете сохранять значение вне диапазона в числовом столбце, MySQL взамен сохранит самое маленькое или самое большое возможное значение.
  • Если Вы пробуете сохранять строку, которая не начинается с числа, в числовой столбец, MySQL сохранит 0 в нем.
  • Если Вы пробуете сохранять NULL, который не берет значения NULL, MySQL сохранит 0 или '' (пустую строку). Это поведение может, однако, быть изменено с опцией компиляции -DDONT_USE_DEFAULT_FIELDS.
  • MySQL позволяет Вам сохранять некоторые неправильные значения даты в столбцы DATE и DATETIME. Например, 2000-02-31 или 2000-02-00. Если дата полностью неправильна, MySQL сохранит в столбце специальное значение даты 0000-00-00.
  • Если Вы устанавливаете enum к неподдерживаемому значению, это будет установлено к значению ошибки 'empty string' с числовым значением 0.
• Если Вы выполняете PROCEDURE на запросе, который возвращает пустой набор, в некоторых случаях PROCEDURE не будет трансформировать столбцы.
• Создание таблицы типа MERGE не проверяет, имеют ли основные таблицы совместимые типы.
• MySQL не может все же обрабатывать значения NaN, -Inf и Inf в double. Использование их вызовет проблемы при попытке экспортировать и импортировать данные. Вы должны как промежуточное решение изменить NaN на NULL (если возможно), а -Inf и Inf соответственно к минимальному и максимальному возможным значениям double.
• LIMIT на отрицательных числах превращается в очень большие положительные числа, что ошибочно.
• Если Вы используете ALTER TABLE, чтобы сначала добавить индекс UNIQUE к таблице, используемой в таблице типа MERGE, и затем использовать ALTER TABLE, чтобы добавить нормальный индекс уже на таблице MERGE, порядок ключей будет иным для таблиц, если имелся старый не уникальный ключ в таблице. Это потому, что ALTER TABLE помещает ключи UNIQUE перед нормальными ключами, чтобы обнаружить двойные ключи как можно раньше.

Следующее представляет известные ошибки в более ранних версиях MySQL:

• Вы можете получать зависающий поток, если Вы делаете DROP TABLE на таблице, которая является одной среди многих таблиц, которые блокированы с помощью LOCK TABLES.
• В следующих случаях Вы можете получать дамп ядра:
  • Отсроченный драйвер вставки имеет ждущие обработки вставки к таблице.
  • LOCK table с WRITE
  • FLUSH TABLES
• До MySQL Version 3.23.2 UPDATE, который модифицировал ключ с помощью WHERE на том же самом ключе, возможно, потерпел неудачу потому, что та же самая строка использовалась для поиска:

  UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;
  

  Обойти это можно так:

  mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;
  

  Это будет работать потому, что MySQL не будет использовать индекс на выражениях в предложении WHERE.
• До MySQL Version 3.23 все числовые типы обрабатываются как поля с фиксированной точкой. Это означает, что Вы должны были определить, сколько десятичных чисел должно быть после запятой. Все результаты были возвращены с правильным количеством десятичных чисел.

Для изучения ошибок, специфических для конкретной платформы, изучите разделы по компиляции и портированию.

Сводная таблица основных реляционных баз данных

Вау!! 😲 Ты еще не читал? Это зря!

• СУБД
• SQL язык реляционных баз данных sql язык sql основные возможности ,
• NoSQL nosql ,
• MSSQL
• Oracle
• postgresql ,
• MariaDB
• phpMyAdmin
• MySQL Workbench
• Firebird

Данная статья про mysql подтверждают значимость применения современных методик для изучения данных проблем. Надеюсь, что теперь ты понял что такое mysql и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL

Продолжение:

Часть 1 Mysql - обзор базы данных , основы, назначение и возможности
Часть 2 1.2 MySQL и стандарты - Mysql - обзор базы данных
Часть 3 Вау!! 😲 Ты еще не читал? Это зря! - Mysql - обзор базы данных , основы,