Avatar of Chuck Brown
Chuck BrownFlag for United States of America asked on

Joining tables in different mySQL databases on same server, different instances

We have an application that uses two instances of mysql, running on two different ports on the same server, say 4510 and 4511.  Table "A" has transaction details and a user number, Table "B" (on 4511) has user details.  I need to simply join the two tables to provide all of the transaction details and the associated user name.  Apparently if these two databases were on the same mysql port, this would be pretty simple.  However, I'm not sure how to make it work in this case.

The only thing I've found so far relates to using a federated storage engine and federated table.  Is this the correct (only?) way to do what I need to do?
MySQL ServerWindows Server 2008

Avatar of undefined
Last Comment

8/22/2022 - Mon
Chuck Brown

Sorry, joining two tables isn't the real problem.  Joining two tables in two different databases residing in two different databases that run under two different ports on the same server is the issue.  Thanks for trying!

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question

The only downside to the scripted approach is that the final, joined data exists within the scope of the application that did the joining, so that might be good or bad depending on your goals.
Chuck Brown

Is there a downside to using the Federated Storage Engine?
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
Chuck Brown


Thanks.  That may be closer, I'm not sure.  The end result of that solution is (apparently) to grant access between the databases, but doesn't say how that is to be done, nor how to actually do a query between the two once permission is granted.

@virastar - that article uses the intermediate programming/scripting language approach that I mentioned, but pushing the data back into temp tables is likely slower than just using the in-memory data.

@clbrownjr - Aside from initial setup, no, there's no real downside. On the backend, it's technically doing the same thing - it's just using the MySQL client as the intermediate piece instead of a separate application. If you're good with enabling the federated storage, then it should be a fine solution.

Just to set expectations, remember that no matter what you do, you're dealing with two different, separately-optimized tables, so the solution will always be slower than using a single instance containing both tables.