MySQL statements to update overlapping database entries and insert new data into various tables
up vote
3
down vote
favorite
As I've mentioned in previous questions, I am writing MySQL statements to update overlapping database entries and insert new data into various tables. My database design looks something like this, where there's one parent table (hash
is the primary key and id
is indexed):
+---------------+
| hashes |
+---------------+
| hash | id |
+---------------+
| hash1 | id1 |
| hash2 | id1 |
| hash3 | id1 |
| hash4 | id2 |
+---------------+
And many child tables (id
is indexed, there are no primary or unique keys):
+-------------------------+
| other_table |
+-------------------------+
| id | group_id | value |
+-------------------------+
| id1 | groupid1 | val1 |
| id1 | groupid1 | val2 |
| id2 | groupid2 | val3 |
| id2 | groupid3 | val4 |
+-------------------------+
There are foreign key constraints on the child table id
columns, so that if any id
s in the hashes
table are updated, all child tables update with the new information. The id
s change when any inserted hashes are overlapped somewhere in the hashes
table.
To achieve all this, I wrote the following statement:
START TRANSACTION;
/* Generated with PHP */
SET @id = '610de097-26d0-41b2-839b-1bd8c0d05dea';
SET @group_id = '54c41b95-5897-4984-961c-cc8fc97fc586';
/* Insert new data */
INSERT INTO hashes
(id, hash)
VALUES
(@id, 'hash1'), (@id, 'hash2')
ON DUPLICATE KEY UPDATE
repeat_count = repeat_count + 1;
INSERT IGNORE INTO categories
(id, group_id, value)
VALUES
(@id, @group_id, 'some value');
COMMIT;
And a collection of update
s to run after everything is inserted:
/* Update all parent table ids for any overlapping hashes */
UPDATE hashes
SET id=@id
WHERE id IN (
SELECT id
FROM (SELECT id, hash FROM hashes ORDER BY id) as temp
WHERE hash IN ('hash1', 'hash2')
ORDER BY id ASC
);
This works, and with around 950 entries to insert, it takes around 25 seconds to run. The slowest part, by far, is the many update
statements since it needs to search over the entire hash
table and update rows accordingly.
Consequently, if I want to see any speed improvements, I need to modify those update
statements. Any ideas?
performance sql mysql
|
show 1 more comment
up vote
3
down vote
favorite
As I've mentioned in previous questions, I am writing MySQL statements to update overlapping database entries and insert new data into various tables. My database design looks something like this, where there's one parent table (hash
is the primary key and id
is indexed):
+---------------+
| hashes |
+---------------+
| hash | id |
+---------------+
| hash1 | id1 |
| hash2 | id1 |
| hash3 | id1 |
| hash4 | id2 |
+---------------+
And many child tables (id
is indexed, there are no primary or unique keys):
+-------------------------+
| other_table |
+-------------------------+
| id | group_id | value |
+-------------------------+
| id1 | groupid1 | val1 |
| id1 | groupid1 | val2 |
| id2 | groupid2 | val3 |
| id2 | groupid3 | val4 |
+-------------------------+
There are foreign key constraints on the child table id
columns, so that if any id
s in the hashes
table are updated, all child tables update with the new information. The id
s change when any inserted hashes are overlapped somewhere in the hashes
table.
To achieve all this, I wrote the following statement:
START TRANSACTION;
/* Generated with PHP */
SET @id = '610de097-26d0-41b2-839b-1bd8c0d05dea';
SET @group_id = '54c41b95-5897-4984-961c-cc8fc97fc586';
/* Insert new data */
INSERT INTO hashes
(id, hash)
VALUES
(@id, 'hash1'), (@id, 'hash2')
ON DUPLICATE KEY UPDATE
repeat_count = repeat_count + 1;
INSERT IGNORE INTO categories
(id, group_id, value)
VALUES
(@id, @group_id, 'some value');
COMMIT;
And a collection of update
s to run after everything is inserted:
/* Update all parent table ids for any overlapping hashes */
UPDATE hashes
SET id=@id
WHERE id IN (
SELECT id
FROM (SELECT id, hash FROM hashes ORDER BY id) as temp
WHERE hash IN ('hash1', 'hash2')
ORDER BY id ASC
);
This works, and with around 950 entries to insert, it takes around 25 seconds to run. The slowest part, by far, is the many update
statements since it needs to search over the entire hash
table and update rows accordingly.
Consequently, if I want to see any speed improvements, I need to modify those update
statements. Any ideas?
performance sql mysql
I don't know if MySQL recognizes that your ORDER BY's are not needed, but you can see if it makes any noticeable difference removing them from your SELECTs. Maybe I'm missing something but I wouldn't think an UPDATE would need to be dependent on the data order
– dbmitch
Jul 7 '16 at 19:34
@dbmitch Just checked, difference is negligible.
– Charlie
Jul 7 '16 at 19:43
Hello! Please don't make changes to the original post once it has been reviewed, as that invalidates the current answers. Please see our meta side on performing iterative reviews for more information!
– syb0rg
Jul 7 '16 at 20:56
@syb0rg No problem. However, my last edit that was rolled back by Vogel didn't change any code, it just provided an example for what I already posted. Am I incorrect about that?
– Charlie
Jul 7 '16 at 21:19
According to what you are saying, hash is the primary key. Do you have an actual unique index specified using this table I ran into some circumstances where MySQL wanted the indices specifically stated instead of implied by the primary key clause. In addition, using INSERT IGNORE ( dev.mysql.com/doc/refman/5.5/en/insert.html ) seems questionable. Are you saying that you are deliberately allowing primary key violations?
– Bradley Ross
Jul 7 '16 at 22:17
|
show 1 more comment
up vote
3
down vote
favorite
up vote
3
down vote
favorite
As I've mentioned in previous questions, I am writing MySQL statements to update overlapping database entries and insert new data into various tables. My database design looks something like this, where there's one parent table (hash
is the primary key and id
is indexed):
+---------------+
| hashes |
+---------------+
| hash | id |
+---------------+
| hash1 | id1 |
| hash2 | id1 |
| hash3 | id1 |
| hash4 | id2 |
+---------------+
And many child tables (id
is indexed, there are no primary or unique keys):
+-------------------------+
| other_table |
+-------------------------+
| id | group_id | value |
+-------------------------+
| id1 | groupid1 | val1 |
| id1 | groupid1 | val2 |
| id2 | groupid2 | val3 |
| id2 | groupid3 | val4 |
+-------------------------+
There are foreign key constraints on the child table id
columns, so that if any id
s in the hashes
table are updated, all child tables update with the new information. The id
s change when any inserted hashes are overlapped somewhere in the hashes
table.
To achieve all this, I wrote the following statement:
START TRANSACTION;
/* Generated with PHP */
SET @id = '610de097-26d0-41b2-839b-1bd8c0d05dea';
SET @group_id = '54c41b95-5897-4984-961c-cc8fc97fc586';
/* Insert new data */
INSERT INTO hashes
(id, hash)
VALUES
(@id, 'hash1'), (@id, 'hash2')
ON DUPLICATE KEY UPDATE
repeat_count = repeat_count + 1;
INSERT IGNORE INTO categories
(id, group_id, value)
VALUES
(@id, @group_id, 'some value');
COMMIT;
And a collection of update
s to run after everything is inserted:
/* Update all parent table ids for any overlapping hashes */
UPDATE hashes
SET id=@id
WHERE id IN (
SELECT id
FROM (SELECT id, hash FROM hashes ORDER BY id) as temp
WHERE hash IN ('hash1', 'hash2')
ORDER BY id ASC
);
This works, and with around 950 entries to insert, it takes around 25 seconds to run. The slowest part, by far, is the many update
statements since it needs to search over the entire hash
table and update rows accordingly.
Consequently, if I want to see any speed improvements, I need to modify those update
statements. Any ideas?
performance sql mysql
As I've mentioned in previous questions, I am writing MySQL statements to update overlapping database entries and insert new data into various tables. My database design looks something like this, where there's one parent table (hash
is the primary key and id
is indexed):
+---------------+
| hashes |
+---------------+
| hash | id |
+---------------+
| hash1 | id1 |
| hash2 | id1 |
| hash3 | id1 |
| hash4 | id2 |
+---------------+
And many child tables (id
is indexed, there are no primary or unique keys):
+-------------------------+
| other_table |
+-------------------------+
| id | group_id | value |
+-------------------------+
| id1 | groupid1 | val1 |
| id1 | groupid1 | val2 |
| id2 | groupid2 | val3 |
| id2 | groupid3 | val4 |
+-------------------------+
There are foreign key constraints on the child table id
columns, so that if any id
s in the hashes
table are updated, all child tables update with the new information. The id
s change when any inserted hashes are overlapped somewhere in the hashes
table.
To achieve all this, I wrote the following statement:
START TRANSACTION;
/* Generated with PHP */
SET @id = '610de097-26d0-41b2-839b-1bd8c0d05dea';
SET @group_id = '54c41b95-5897-4984-961c-cc8fc97fc586';
/* Insert new data */
INSERT INTO hashes
(id, hash)
VALUES
(@id, 'hash1'), (@id, 'hash2')
ON DUPLICATE KEY UPDATE
repeat_count = repeat_count + 1;
INSERT IGNORE INTO categories
(id, group_id, value)
VALUES
(@id, @group_id, 'some value');
COMMIT;
And a collection of update
s to run after everything is inserted:
/* Update all parent table ids for any overlapping hashes */
UPDATE hashes
SET id=@id
WHERE id IN (
SELECT id
FROM (SELECT id, hash FROM hashes ORDER BY id) as temp
WHERE hash IN ('hash1', 'hash2')
ORDER BY id ASC
);
This works, and with around 950 entries to insert, it takes around 25 seconds to run. The slowest part, by far, is the many update
statements since it needs to search over the entire hash
table and update rows accordingly.
Consequently, if I want to see any speed improvements, I need to modify those update
statements. Any ideas?
performance sql mysql
performance sql mysql
edited Apr 13 '17 at 12:43
Community♦
1
1
asked Jul 7 '16 at 15:43
Charlie
371316
371316
I don't know if MySQL recognizes that your ORDER BY's are not needed, but you can see if it makes any noticeable difference removing them from your SELECTs. Maybe I'm missing something but I wouldn't think an UPDATE would need to be dependent on the data order
– dbmitch
Jul 7 '16 at 19:34
@dbmitch Just checked, difference is negligible.
– Charlie
Jul 7 '16 at 19:43
Hello! Please don't make changes to the original post once it has been reviewed, as that invalidates the current answers. Please see our meta side on performing iterative reviews for more information!
– syb0rg
Jul 7 '16 at 20:56
@syb0rg No problem. However, my last edit that was rolled back by Vogel didn't change any code, it just provided an example for what I already posted. Am I incorrect about that?
– Charlie
Jul 7 '16 at 21:19
According to what you are saying, hash is the primary key. Do you have an actual unique index specified using this table I ran into some circumstances where MySQL wanted the indices specifically stated instead of implied by the primary key clause. In addition, using INSERT IGNORE ( dev.mysql.com/doc/refman/5.5/en/insert.html ) seems questionable. Are you saying that you are deliberately allowing primary key violations?
– Bradley Ross
Jul 7 '16 at 22:17
|
show 1 more comment
I don't know if MySQL recognizes that your ORDER BY's are not needed, but you can see if it makes any noticeable difference removing them from your SELECTs. Maybe I'm missing something but I wouldn't think an UPDATE would need to be dependent on the data order
– dbmitch
Jul 7 '16 at 19:34
@dbmitch Just checked, difference is negligible.
– Charlie
Jul 7 '16 at 19:43
Hello! Please don't make changes to the original post once it has been reviewed, as that invalidates the current answers. Please see our meta side on performing iterative reviews for more information!
– syb0rg
Jul 7 '16 at 20:56
@syb0rg No problem. However, my last edit that was rolled back by Vogel didn't change any code, it just provided an example for what I already posted. Am I incorrect about that?
– Charlie
Jul 7 '16 at 21:19
According to what you are saying, hash is the primary key. Do you have an actual unique index specified using this table I ran into some circumstances where MySQL wanted the indices specifically stated instead of implied by the primary key clause. In addition, using INSERT IGNORE ( dev.mysql.com/doc/refman/5.5/en/insert.html ) seems questionable. Are you saying that you are deliberately allowing primary key violations?
– Bradley Ross
Jul 7 '16 at 22:17
I don't know if MySQL recognizes that your ORDER BY's are not needed, but you can see if it makes any noticeable difference removing them from your SELECTs. Maybe I'm missing something but I wouldn't think an UPDATE would need to be dependent on the data order
– dbmitch
Jul 7 '16 at 19:34
I don't know if MySQL recognizes that your ORDER BY's are not needed, but you can see if it makes any noticeable difference removing them from your SELECTs. Maybe I'm missing something but I wouldn't think an UPDATE would need to be dependent on the data order
– dbmitch
Jul 7 '16 at 19:34
@dbmitch Just checked, difference is negligible.
– Charlie
Jul 7 '16 at 19:43
@dbmitch Just checked, difference is negligible.
– Charlie
Jul 7 '16 at 19:43
Hello! Please don't make changes to the original post once it has been reviewed, as that invalidates the current answers. Please see our meta side on performing iterative reviews for more information!
– syb0rg
Jul 7 '16 at 20:56
Hello! Please don't make changes to the original post once it has been reviewed, as that invalidates the current answers. Please see our meta side on performing iterative reviews for more information!
– syb0rg
Jul 7 '16 at 20:56
@syb0rg No problem. However, my last edit that was rolled back by Vogel didn't change any code, it just provided an example for what I already posted. Am I incorrect about that?
– Charlie
Jul 7 '16 at 21:19
@syb0rg No problem. However, my last edit that was rolled back by Vogel didn't change any code, it just provided an example for what I already posted. Am I incorrect about that?
– Charlie
Jul 7 '16 at 21:19
According to what you are saying, hash is the primary key. Do you have an actual unique index specified using this table I ran into some circumstances where MySQL wanted the indices specifically stated instead of implied by the primary key clause. In addition, using INSERT IGNORE ( dev.mysql.com/doc/refman/5.5/en/insert.html ) seems questionable. Are you saying that you are deliberately allowing primary key violations?
– Bradley Ross
Jul 7 '16 at 22:17
According to what you are saying, hash is the primary key. Do you have an actual unique index specified using this table I ran into some circumstances where MySQL wanted the indices specifically stated instead of implied by the primary key clause. In addition, using INSERT IGNORE ( dev.mysql.com/doc/refman/5.5/en/insert.html ) seems questionable. Are you saying that you are deliberately allowing primary key violations?
– Bradley Ross
Jul 7 '16 at 22:17
|
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
0
down vote
I was going in circles looking at your query and then I thought
... it looks like you're just updating the one table form the same table
Why can't you just use
UPDATE hashes
SET id=@id
WHERE hash IN ('hash1', 'hash2');
Or is this a typo?
UPDATE hashes
Because that only updates theid
of the row(s) where thehash
overlaps. I need to update all rows with the returnedid
s. For instance, in my example, ifhash1
andhash4
are added to the table again, I don't want to only update the row 1 and 4. Instead I need to select all rows that match those ids and update everything to the new value.
– Charlie
Jul 7 '16 at 20:06
Perhaps you should share your "collection of updates to run after everything is inserted:" If I just look at the query in the context of being a query I don't see why you shouldn;t use it. Can you show the context of the update query?
– dbmitch
Jul 7 '16 at 20:13
Now I'm really confused - you've changed the table and the contents for hash field from a text to a number - still incremental I guess, then you've also changed the update query. Why wouldn't you include '3' in your query if you want it updated? You didn't include 'hash3' or 'hash4' in your original example.
– dbmitch
Jul 7 '16 at 21:13
The type change was inadvertent, just quicker to type but doesn't really change anything either. And because I don't know if hash3 (3) exists. All I know is that hash1 (1) and hash2 (2) exist. However, there might be other rows that share the id's of hash1/hash2 which I want to update as well (should they exist, which is what my query takes care of).
– Charlie
Jul 7 '16 at 21:15
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
I was going in circles looking at your query and then I thought
... it looks like you're just updating the one table form the same table
Why can't you just use
UPDATE hashes
SET id=@id
WHERE hash IN ('hash1', 'hash2');
Or is this a typo?
UPDATE hashes
Because that only updates theid
of the row(s) where thehash
overlaps. I need to update all rows with the returnedid
s. For instance, in my example, ifhash1
andhash4
are added to the table again, I don't want to only update the row 1 and 4. Instead I need to select all rows that match those ids and update everything to the new value.
– Charlie
Jul 7 '16 at 20:06
Perhaps you should share your "collection of updates to run after everything is inserted:" If I just look at the query in the context of being a query I don't see why you shouldn;t use it. Can you show the context of the update query?
– dbmitch
Jul 7 '16 at 20:13
Now I'm really confused - you've changed the table and the contents for hash field from a text to a number - still incremental I guess, then you've also changed the update query. Why wouldn't you include '3' in your query if you want it updated? You didn't include 'hash3' or 'hash4' in your original example.
– dbmitch
Jul 7 '16 at 21:13
The type change was inadvertent, just quicker to type but doesn't really change anything either. And because I don't know if hash3 (3) exists. All I know is that hash1 (1) and hash2 (2) exist. However, there might be other rows that share the id's of hash1/hash2 which I want to update as well (should they exist, which is what my query takes care of).
– Charlie
Jul 7 '16 at 21:15
add a comment |
up vote
0
down vote
I was going in circles looking at your query and then I thought
... it looks like you're just updating the one table form the same table
Why can't you just use
UPDATE hashes
SET id=@id
WHERE hash IN ('hash1', 'hash2');
Or is this a typo?
UPDATE hashes
Because that only updates theid
of the row(s) where thehash
overlaps. I need to update all rows with the returnedid
s. For instance, in my example, ifhash1
andhash4
are added to the table again, I don't want to only update the row 1 and 4. Instead I need to select all rows that match those ids and update everything to the new value.
– Charlie
Jul 7 '16 at 20:06
Perhaps you should share your "collection of updates to run after everything is inserted:" If I just look at the query in the context of being a query I don't see why you shouldn;t use it. Can you show the context of the update query?
– dbmitch
Jul 7 '16 at 20:13
Now I'm really confused - you've changed the table and the contents for hash field from a text to a number - still incremental I guess, then you've also changed the update query. Why wouldn't you include '3' in your query if you want it updated? You didn't include 'hash3' or 'hash4' in your original example.
– dbmitch
Jul 7 '16 at 21:13
The type change was inadvertent, just quicker to type but doesn't really change anything either. And because I don't know if hash3 (3) exists. All I know is that hash1 (1) and hash2 (2) exist. However, there might be other rows that share the id's of hash1/hash2 which I want to update as well (should they exist, which is what my query takes care of).
– Charlie
Jul 7 '16 at 21:15
add a comment |
up vote
0
down vote
up vote
0
down vote
I was going in circles looking at your query and then I thought
... it looks like you're just updating the one table form the same table
Why can't you just use
UPDATE hashes
SET id=@id
WHERE hash IN ('hash1', 'hash2');
Or is this a typo?
UPDATE hashes
I was going in circles looking at your query and then I thought
... it looks like you're just updating the one table form the same table
Why can't you just use
UPDATE hashes
SET id=@id
WHERE hash IN ('hash1', 'hash2');
Or is this a typo?
UPDATE hashes
answered Jul 7 '16 at 19:54
dbmitch
250212
250212
Because that only updates theid
of the row(s) where thehash
overlaps. I need to update all rows with the returnedid
s. For instance, in my example, ifhash1
andhash4
are added to the table again, I don't want to only update the row 1 and 4. Instead I need to select all rows that match those ids and update everything to the new value.
– Charlie
Jul 7 '16 at 20:06
Perhaps you should share your "collection of updates to run after everything is inserted:" If I just look at the query in the context of being a query I don't see why you shouldn;t use it. Can you show the context of the update query?
– dbmitch
Jul 7 '16 at 20:13
Now I'm really confused - you've changed the table and the contents for hash field from a text to a number - still incremental I guess, then you've also changed the update query. Why wouldn't you include '3' in your query if you want it updated? You didn't include 'hash3' or 'hash4' in your original example.
– dbmitch
Jul 7 '16 at 21:13
The type change was inadvertent, just quicker to type but doesn't really change anything either. And because I don't know if hash3 (3) exists. All I know is that hash1 (1) and hash2 (2) exist. However, there might be other rows that share the id's of hash1/hash2 which I want to update as well (should they exist, which is what my query takes care of).
– Charlie
Jul 7 '16 at 21:15
add a comment |
Because that only updates theid
of the row(s) where thehash
overlaps. I need to update all rows with the returnedid
s. For instance, in my example, ifhash1
andhash4
are added to the table again, I don't want to only update the row 1 and 4. Instead I need to select all rows that match those ids and update everything to the new value.
– Charlie
Jul 7 '16 at 20:06
Perhaps you should share your "collection of updates to run after everything is inserted:" If I just look at the query in the context of being a query I don't see why you shouldn;t use it. Can you show the context of the update query?
– dbmitch
Jul 7 '16 at 20:13
Now I'm really confused - you've changed the table and the contents for hash field from a text to a number - still incremental I guess, then you've also changed the update query. Why wouldn't you include '3' in your query if you want it updated? You didn't include 'hash3' or 'hash4' in your original example.
– dbmitch
Jul 7 '16 at 21:13
The type change was inadvertent, just quicker to type but doesn't really change anything either. And because I don't know if hash3 (3) exists. All I know is that hash1 (1) and hash2 (2) exist. However, there might be other rows that share the id's of hash1/hash2 which I want to update as well (should they exist, which is what my query takes care of).
– Charlie
Jul 7 '16 at 21:15
Because that only updates the
id
of the row(s) where the hash
overlaps. I need to update all rows with the returned id
s. For instance, in my example, if hash1
and hash4
are added to the table again, I don't want to only update the row 1 and 4. Instead I need to select all rows that match those ids and update everything to the new value.– Charlie
Jul 7 '16 at 20:06
Because that only updates the
id
of the row(s) where the hash
overlaps. I need to update all rows with the returned id
s. For instance, in my example, if hash1
and hash4
are added to the table again, I don't want to only update the row 1 and 4. Instead I need to select all rows that match those ids and update everything to the new value.– Charlie
Jul 7 '16 at 20:06
Perhaps you should share your "collection of updates to run after everything is inserted:" If I just look at the query in the context of being a query I don't see why you shouldn;t use it. Can you show the context of the update query?
– dbmitch
Jul 7 '16 at 20:13
Perhaps you should share your "collection of updates to run after everything is inserted:" If I just look at the query in the context of being a query I don't see why you shouldn;t use it. Can you show the context of the update query?
– dbmitch
Jul 7 '16 at 20:13
Now I'm really confused - you've changed the table and the contents for hash field from a text to a number - still incremental I guess, then you've also changed the update query. Why wouldn't you include '3' in your query if you want it updated? You didn't include 'hash3' or 'hash4' in your original example.
– dbmitch
Jul 7 '16 at 21:13
Now I'm really confused - you've changed the table and the contents for hash field from a text to a number - still incremental I guess, then you've also changed the update query. Why wouldn't you include '3' in your query if you want it updated? You didn't include 'hash3' or 'hash4' in your original example.
– dbmitch
Jul 7 '16 at 21:13
The type change was inadvertent, just quicker to type but doesn't really change anything either. And because I don't know if hash3 (3) exists. All I know is that hash1 (1) and hash2 (2) exist. However, there might be other rows that share the id's of hash1/hash2 which I want to update as well (should they exist, which is what my query takes care of).
– Charlie
Jul 7 '16 at 21:15
The type change was inadvertent, just quicker to type but doesn't really change anything either. And because I don't know if hash3 (3) exists. All I know is that hash1 (1) and hash2 (2) exist. However, there might be other rows that share the id's of hash1/hash2 which I want to update as well (should they exist, which is what my query takes care of).
– Charlie
Jul 7 '16 at 21:15
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f134181%2fmysql-statements-to-update-overlapping-database-entries-and-insert-new-data-into%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I don't know if MySQL recognizes that your ORDER BY's are not needed, but you can see if it makes any noticeable difference removing them from your SELECTs. Maybe I'm missing something but I wouldn't think an UPDATE would need to be dependent on the data order
– dbmitch
Jul 7 '16 at 19:34
@dbmitch Just checked, difference is negligible.
– Charlie
Jul 7 '16 at 19:43
Hello! Please don't make changes to the original post once it has been reviewed, as that invalidates the current answers. Please see our meta side on performing iterative reviews for more information!
– syb0rg
Jul 7 '16 at 20:56
@syb0rg No problem. However, my last edit that was rolled back by Vogel didn't change any code, it just provided an example for what I already posted. Am I incorrect about that?
– Charlie
Jul 7 '16 at 21:19
According to what you are saying, hash is the primary key. Do you have an actual unique index specified using this table I ran into some circumstances where MySQL wanted the indices specifically stated instead of implied by the primary key clause. In addition, using INSERT IGNORE ( dev.mysql.com/doc/refman/5.5/en/insert.html ) seems questionable. Are you saying that you are deliberately allowing primary key violations?
– Bradley Ross
Jul 7 '16 at 22:17