My live site's database prefix is different than my local
In our WordPress classes, we are using the standard "wp_" prefix for our database. But what if your host uses a custom prefix like "wp_n8z2xa5h_"? If you try to import tables with one prefix into a database using another prefix, your imported tables will not overwrite what is currently there. You will end up with double the tables and double the headaches and/or conflicts.
How do we fix this?
First, you should backup the database and wp-config files of your live and local sites. Always make a backup before touching the database. We mean it!
Got your backup? Ok good!
If you are moving from local to live...
Drop all the original database tables on your live site. Once that is done, you can import all of your local tables, including the users and usermeta tables.
We don't usually recommend that you import the users and usermeta tables because they will overwrite the live site's login credentials with your local login information. But in this case, given that there is a prefix issue to fix and we dropped all the tables, we will need those two tables to come along for the ride!
If you can't import the users and usermeta tables (perhaps there are multiple users set up on the live site already that you don't have locally), we will need to go about this a bit differently. Instead of dropping all the tables from the live site, drop all the tables except the users and usermeta tables. Then import all the other tables from your local site and manually edit the custom prefix for the live users and usermeta tables. You'll also need to manually edit any meta keys in those tables that are referencing the custom prefix. Then you would be able to log in using the live user login. Take your time with this change, you will want to be sure that you don't miss a single reference to the custom prefix!
Phew! Once your live tables are all set, there's one more thing to do. In your live site's wp-config.php file, change the table prefix value to match the prefix that your live database is now using, so that it syncs up with the new database information.
If you are importing from live to local...
If you know the live host is using a custom prefix, the easiest solution is to enter that prefix when you are setting up your local installation. Yay! Now when you import, you've got a prefix match and can avoid all those headaches.