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.

 
Go Back  dBforums > Database Server Software > MySQL > mysql copy table issues with query retrieval

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 02-02-12, 13:36
seen seen is offline
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.
Reply With Quote
  #2 (permalink)  
Old 02-02-12, 13:45
r937 r937 is offline
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
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
  #3 (permalink)  
Old 02-02-12, 13:57
seen seen is offline
Registered User
 
Join Date: Feb 2012
Posts: 4
Quote:
Originally Posted by r937 View Post
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.
Reply With Quote
  #4 (permalink)  
Old 02-02-12, 14:11
r937 r937 is offline
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
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
  #5 (permalink)  
Old 02-02-12, 14:36
seen seen is offline
Registered User
 
Join Date: Feb 2012
Posts: 4
Quote:
Originally Posted by r937 View Post
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
Reply With Quote
  #6 (permalink)  
Old 02-02-12, 14:45
r937 r937 is offline
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
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
  #7 (permalink)  
Old 02-02-12, 15:14
it-iss.com it-iss.com is offline
Registered User
 
Join Date: Sep 2009
Location: San Sebastian, Spain
Posts: 620
Rudy that was 34 mins!!! You still breathing?
__________________
Ronan Cashell
Senior Oracle/MySQL DBA
http://www.it-iss.com
Reply With Quote
  #8 (permalink)  
Old 02-02-12, 15:21
seen seen is offline
Registered User
 
Join Date: Feb 2012
Posts: 4
Quote:
Originally Posted by r937 View Post
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!!
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On