Миграция MySQL в PostgreSQL - какие функции, невидимые в коде SQL, будут важны?

Question

Мы переносим MySQL на PostgreSQL. Я легко могу проверить схему и операторы SQL, используемые в программе (REALbasic). Большая часть SQL состоит из строковых переменных.

Я уже знаю о необходимости заменить наше использование SELECT LAST_INSERT_ID() на столбец SERIAL с ограничением UNIQUE.

Что, , если есть , различия между двумя, которые не , очевидно, видимые в выражениях SQL, могут укусить нас? Я ищу (возможно, тонкие) предположения о поведении, такие как любые различия в автоматической фиксации, необходимо добавить ограничения, которых нет в MySQL и т.д.

Я пытаюсь подсказать какие-нибудь ошибки для пары достаточно умных, внимательных парней, которые не являются гуру ни в одной из баз данных.

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

Примечание: мы не используем какую-либо форму параметризованных запросов и, да, я указал на проблемы с атаками внедрения как обязательный аудит кода.

Да, для любопытных это решение было вызвано проблемами GPL, не потому, что мы не склонны платить за лицензии, но, к сожалению, единственным драйвером REALbasic для MySQL была GPL. По состоянию на май 2009 года Real Software выпустила новый драйвер сообщества, который является GPL, и правильно включает в себя источник. В ближайшем будущем они пообещали не корпоративный драйвер GPL.

Я готов поверить, что ответ может быть под кроватью нет невидимых монстров , но я решил попросить об этом.

Answer 1

• select count(*) from table;

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

• В последней версии (8.3) нет неявного приведения к тексту, что означает, например,

  select 234 like '2%';

  выдаст ошибку. Вам понадобится явное приведение типа:

  select 234::text like '2%';

• Обновление действительно удаление + вставка. Поскольку пространство, используемое удаленными строками, освобождается не сразу, то, если вы обновите всю таблицу за одну транзакцию, вам потребуется удвоить пространство.

Postgresql - очень хорошая база данных, вам она очень понравится. Он имеет несколько очень полезных функций, которые вы потом упустите в других, даже коммерческих базах данных. Например, язык определения транзакционных данных или точки сохранения.

Answer 2

Когда я перешел с MySQL на PostgreSQL, на моем пути встало несколько вещей:

1) Запись кода в базу данных MySQL была нарушена, и загрузка в базу данных мусора реальной базы данных с внешними ключами была бы невозможной. Будьте готовы найти «неожиданные» данные мусора после добавления в ссылочную целостность.

2) Индексы MySQL для строк нечувствительны к регистру! Если у вас есть первичный ключ для чего-то вроде имени пользователя, «Coryking» и «CORYKING» одинаковы для MySQL. На PostgreSQL они разные. Я не знал об этом, пока не начали появляться люди, которые регистрировали повторяющиеся имена пользователей, которые уже должны быть в базе данных.

3) MySQL любит автоматически добавлять бессмысленные значения по умолчанию в столбцы, которые вы указали как "NOT NULL". Например, если вы укажете VARCHAR (255) NOT NULL, он превратит определение этого столбца в «VARCHAR (255) NOT NULL DEFAULT» ».

4) PostgreSQL любит большие запросы, а MySQL нет. После миграции вам будет очень весело улучшать запросы к базе данных - не стесняйтесь и в этом.

Answer 3

http://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL

Answer 4

Я не знаю, используете ли вы PHP или нет, но я обнаружил, что аддлэш работает относительно хорошо для MySQL, но в Postgres быстро бомбит. Либо используйте pg_escape_string (), либо лучше подготовленный оператор.

Answer 5

Если вы не были SQL92-совместимым с типизацией столбцов, вы будете сталкиваться с различиями в именах типов между ними.

Изменение переменных в запросе не работает, например, в postgreSQL, это будет работать в MySQL, но не в postgreSQL (я не проверял это недавно, возможно, это работает сейчас.)

SET @a: = 1 SELECT ID, @ a: = @ a + 1 FROM some_table;

Я также лично считаю, что postgreSQL лучше обрабатывает сложные запросы, которые включают подвыборы и тому подобное (чего раньше избегало большинство пользователей MySQL).

Редактировать: О, и я почти забыл! PostgreSQL хранит таблицы совершенно иначе, чем MySQL. Это также может повлиять на ваши стратегии резервного копирования / восстановления.

Answer 6

На основании сравнения WikiVS Я только что обнаружил ряд интересных моментов, большинство из которых не совсем понятно, таких как: - подзапросы намного быстрее в Postgres, на самом деле это не уловка, но некоторые обходные пути могут быть удалены

Этот сайт привел меня к списку Postgres Gotchas , в котором было больше информации о скорости счета (*) и еще одной проблеме последовательного сканирования: Max и Min - это последовательные сканирования. Это гораздо более вероятно повредит нашей производительности, чем что-либо еще идентифицированное до сих пор. Однако эта статья содержит обходной путь Max (col):

SELECT col FROM table ORDER BY col DESC LIMIT 1

Answer 7

В зависимости от количества задействованных запросов (и если у вас есть кто-то, кто это делает), может быть целесообразно извлечь все запросы, адаптировать их по мере необходимости и запустить их на двух копиях существующей БД, одна из которых работает mysql и один бегущий посгресл. Просмотр полученных журналов и сравнение полученных данных может показать некоторые интересные подсказки. Первый шаг также может быть выполнен путем выполнения модульных тестов, ручного или скриптового тестирования приложения.