http://www.mysqlab.net/knowledge/kb/detail/topic/merge/id/5123
MySQL知识库 :: merge
What are the advantages and disadvantages of MERGE tables?
Discussion
MERGE tables can help you solve the following problems:
Easily manage a set of log tables. For example, you can put data from different months into separate tables, compress some of them with myisampack, and then create a MERGE table to use them as one.
Obtain more speed. You can split a big read-only table based on some criteria, and then put individual tables on different disks. A MERGE table on this could be much faster than using the big table. You can also use a RAID table to get the same kind of benefits.
Do more efficient searches. If you know exactly what you are looking for, you can search in just one of the split tables for some queries and use a MERGE table for others. You can even have many different MERGE tables that use overlapping sets of tables.
Do more efficient repairs. It's easier to repair the individual tables that are mapped to a MERGE table than to repair a single really big table.
Instantly map many tables as one. A MERGE table need not maintain an index of its own because it uses the indexes of the individual tables. As a result, MERGE table collections are very fast to create or remap. (Note that you must still specify the index definitions when you create a MERGE table, even though no indexes are created.)
If you have a set of tables that you join as a big table on demand or batch, you should instead create a MERGE table on them on demand. This is much faster and will save a lot of disk space.
Exceed the file size limit for the operating system. Each MyISAM table is bound by this limit, but a collection of MyISAM tables is not.
You can create an alias or synonym for a MyISAM table by defining a MERGE table that maps to that single table. There should be no really notable performance impact of doing this (only a couple of indirect calls and memcpy() calls for each read).
The disadvantages of MERGE tables are:
You can use only identical MyISAM tables for a MERGE table.
MERGE tables use more file descriptors. If 10 clients are using a MERGE table that maps to 10 tables, the server uses (10*10) + 10 file descriptors. (10 data file descriptors for each of the 10 clients, and 10 index file descriptors shared among the clients.)
Key reads are slower. When you read a key, the MERGE storage engine needs to issue a read on all underlying tables to check which one most closely matches the given key. If you then do a ``read-next,'' the MERGE storage engine needs to search the read buffers to find the next key. Only when one key buffer is used up, the storage engine will need to read the next key block. This makes MERGE keys much slower on eq_ref searches, but not much slower on ref searches. See section 7.2.1 EXPLAIN Syntax (Get Information About a SELECT) for more information about eq_ref and ref.
Since you have very much data at hand, I suggest you merge your date and time columns first. Then you can use an index efficiently. If you don't, you will have to do something like
...WHERE CONCAT(date, ' ', time) = SELECT MAX(CONCAT(date, ' ', time)) ...
So, first do this for both tables.
ALTER TABLE tableA ADD COLUMN creation_date datetime; /*or whatever name, just make it meaningful and don't use keywords*/
UPDATE tableA SET creation_date = CONCAT(date, ' ', time);
ALTER TABLE tableA DROP COLUMN date, DROP COLUMN time;
CREATE INDEX idx_dt_tableA_creation ON tableA(creation_date);
Then you can insert both tables into your combine_table (Note, left this for completeness, the second option is much better).
INSERT INTO combined_table
SELECT col1, col2, creation_date
FROM (
SELECT col1, col2, creation_date
FROM tableA
UNION ALL
SELECT col1, col2, creation_date
FROM tableB
) sq /*subquery_alias*/
WHERE creation_date = (SELECT MAX(creation_date) FROM (
SELECT col1, col2, creation_date
FROM tableA
UNION ALL
SELECT col1, col2, creation_date
FROM tableB
) another_sq
WHERE sq.col1 = another_sq.col1
)
;
Nonetheless, this will be a heavy operation, if you really have that much data.
Now that I think of it, there's a better way of doing it.
First insert tableA
INSERT INTO combined_table
SELECT * FROM tableA;
Then do an insert on duplicate key update
.
INSERT INTO combined_table c
SELECT * FROM tableB b
ON DUPLICATE KEY UPDATE
/*you can skip col1, since it's the identifying primary key here*/
col2 = IF(b.creation_date > c.creation_date, b.col2, c.col2),
creation_date = IF(b.creation_date > c.creation_date, b.creation_date, c.creation_date)
;
Comments
Post a Comment