Migrating from MySQL to PostgreSQL [closed]

问题:

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

We are currently using MySQL for a product we are building, and are keen to move to PostgreSQL as soon as possible, primarily for licensing reasons.

Has anyone else done such a move? Our database is the lifeblood of the application and will eventually be storing TBs of data, so I'm keen to hear about experiences of performance improvements/losses, major hurdles in converting SQL and stored procedures, etc.

Edit: Just to clarify to those who have asked why we don't like MySQL's licensing. We are developing a commercial product which (currently) depends on MySQL as a database back-end. Their license states we need to pay them a percentage of our list price per installation, and not a flat fee. As a startup, this is less than appealing.

回答1:

Steve, I had to migrate my old application the way around, that is PgSQL->MySQL. I must say, you should consider yourself lucky ;-) Common gotchas are:

• SQL is actually pretty close to language standard, so you may suffer from MySQL's dialect you already know
• MySQL quietly truncates varchars that exceed max length, whereas Pg complains - quick workaround is to have these columns as 'text' instead of 'varchar' and use triggers to truncate long lines
• double quotes are used instead of reverse apostrophes
• boolean fields are compared using IS and IS NOT operators, however MySQL-compatible INT(1) with = and <> is still possible
• there is no REPLACE, use DELETE/INSERT combo
• Pg is pretty strict on enforcing foreign keys integrity, so don't forget to use ON DELETE CASCADE on references
• if you use PHP with PDO, remember to pass a parameter to lastInsertId() method - it should be sequence name, which is created usually this way: [tablename]_[primarykeyname]_seq

I hope that helps at least a bit. Have lots of fun playing with Postgres!

回答2:

I have done a similar conversion, but for different reasons. It was because we needed better ACID support, and the ability to have web users see the same data they could via other DB tools (one ID for both).

Here are the things that bit us:

1. MySQL does not enforce constraints as strictly as PostgreSQL.
2. There are different date handling routines. These will need to be manually converted.
3. Any code that does not expect ACID compliance may be an issue.

That said, once it was in place and tested, it was much nicer. With correct locking for safety reasons and heavy concurrent use, PostgreSQL performed better than MySQL. On the things where locking was not needed (read only) the performance was not quite as good, but it was still faster than the network card, so it was not an issue.

Tips:

• The automated scripts in the contrib directory are a good starting point for your conversion, but will need to be touched a little usually.
• I would highly recommend that you use the serializable isolation level as a default.
• The pg_autodoc tool is good to really see your data structures and help find any relationships you forgot to define and enforce.

回答3:

We did a move from a MySQL3 to PostgreSQL 8.2 then 8.3. PostgreSQL has the basic of SQL and a lot more so if your MYSQL do not use fancy MySQL stuff you will be OK.

From my experience, our MySQL database (version 3) doesn't have Foreign Key... PostgreSQL lets you have them, so we had to change that... and it was a good thing and we found some mistake.

The other thing that we had to change was the coding (C#) connector that wasn't the same in MySQL. The MySQL one was more stable than the PostgreSQL one. We still have few problems with the PostgreSQL one.