| |
|
If this is your first visit, be sure to check out the FAQ by clicking the link above.
You may have to register before you can post: click the register link above to proceed.
To start viewing messages, select the forum that you want to visit from the selection below.
|
 |

02-02-12, 13:36
|
|
Registered User
|
|
Join Date: Feb 2012
Posts: 4
|
|
|
mysql copy table issues with query retrieval
|
|
Hi gurus,
I recently made a mistake with my database and as a result had to restore from backup. However, I only needed to restore 1 table, so I created a new db and imported the backup, then went:
DROP TABLE liveDB.old_table;
CREATE TABLE liveDB.old_table SELECT * FROM tempDB.old_table;
Here is my problem. If I run a query such as:
SELECT * FROM liveDB.some_other_table
LEFT JOIN liveDB.old_table
ON some_other_table.ID=old_table.ID;
Before the restore of old_table it ran very quickly and smooth. Now with the restore it runs terribly slow. It often takes atleast half a minute to pull that 1 query. Can anyone point me in the right direction as to what to do to fix this? Thanks.
|
|

02-02-12, 13:45
|
|
SQL Consultant
|
|
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,525
|
|
when you dropped the old table, you destroyed its indexes, and you didn't re-create them
|
|

02-02-12, 13:57
|
|
Registered User
|
|
Join Date: Feb 2012
Posts: 4
|
|
|
|
Quote:
Originally Posted by r937
when you dropped the old table, you destroyed its indexes, and you didn't re-create them
|
I appreciate the response, I saw that solution on another site right after I made the post..
Fixed with:
CREATE TABLE liveDB.old_table (ID INT(3) auto_increment primary key) SELECT * FROM tempDB.old_table;
Curious though, why does destroying the indexes cause the runtime to sky rocket? What is causing the delay? If I didn't include the auto_increment portion, the values still held from old to new so the join should still be the same, no? Thanks in advance.
|
|

02-02-12, 14:11
|
|
SQL Consultant
|
|
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,525
|
|
i'm gonna wait longer than 9 minutes before replying this time, as i'm sure you will get the answer from another site
|
|

02-02-12, 14:36
|
|
Registered User
|
|
Join Date: Feb 2012
Posts: 4
|
|
Quote:
Originally Posted by r937
i'm gonna wait longer than 9 minutes before replying this time, as i'm sure you will get the answer from another site
|
I didn't mean to offend, I'm appreciative of any help I can get.
This is the site I was referring to that provided me with the fix I was looking for:
SQL COPY MySQL TABLE with structure and records
It however doesn't mention anywhere the consequences of not re-creating indexes, or why the delay at runtime. Thanks much 
|
|

02-02-12, 14:45
|
|
SQL Consultant
|
|
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,525
|
|
when you declared the auto_increment, you also specified PRIMARY KEY
this creates an index by default
in your query, you join the (new) old table to some_other_table using the id
this allows for an indexed search, rather than a table scan
without the index, every row from some_other_table requires a table scan of the (new) old table to see if there's a matching id
|
|

02-02-12, 15:14
|
|
Registered User
|
|
Join Date: Sep 2009
Location: San Sebastian, Spain
Posts: 620
|
|
Rudy that was 34 mins!!! You still breathing?
|
|

02-02-12, 15:21
|
|
Registered User
|
|
Join Date: Feb 2012
Posts: 4
|
|
Quote:
Originally Posted by r937
when you declared the auto_increment, you also specified PRIMARY KEY
this creates an index by default
in your query, you join the (new) old table to some_other_table using the id
this allows for an indexed search, rather than a table scan
without the index, every row from some_other_table requires a table scan of the (new) old table to see if there's a matching id
|
Thank you!!
|
|
| Thread Tools |
Search this Thread |
|
|
|
| Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|