原創 如何從資料庫層面檢測兩表內容的一致性

2021-09-05 08:05:27 字數 4585 閱讀 7937

一般來說呢,如何檢測兩張表的內容是否一致,這樣的需求大多在從機上體現,以保證資料一致性。方法無非有兩個,第一呢就是從資料庫著手,第二呢就是從應用程式端著手。 我這裡羅列了些如何從資料庫層面來解決此類問題的方法。

當然第一步就是檢查記錄數是否一致,否則不用想任何其他方法了。

這裡我們用兩張表t1_old,t1_new來演示。

表結構:

create table t1_old (

id int(11) not null,

log_time timestamp default null

) ; create table t1_new (

id int(11) not null,

log_time timestamp default null

) ;兩表的記錄數都為100條。

mysql> select count(*) from t1_old;

+----------+

| count(*) |

+----------+

|      100 |

+----------+

1 row in set (0.31 sec)

mysql> select count(*) from t1_new;

+----------+

| count(*) |

+----------+

|      100 |

+----------+

1 row in set (0.00 sec)

方法一:用加法然後去重。

由於union 本身具備把上下兩條連線的記錄做唯一性排序,所以這樣檢測來的非常簡單。

mysql> select count(*) from (select * from t1_old union select * from t1_new) as t;

+----------+

| count(*) |

+----------+

|      100 |

+----------+

1 row in set (0.06 sec)

這裡的記錄數為100,初步證明兩表內容一致。但是,這個方法有個bug,在某些情形下不能簡單表示結果集一致。

比如:mysql> create table t1_old1 (id int);

query ok, 0 rows affected (0.27 sec)

mysql> create table t1_new1(id int);

query ok, 0 rows affected (0.09 sec)

mysql> insert into t1_old1 values (1),(2),(3),(5);

query ok, 4 rows affected (0.15 sec)

records: 4  duplicates: 0  warnings: 0

mysql> insert into t1_new1 values (2),(2),(3),(5);    

query ok, 4 rows affected (0.02 sec)

records: 4  duplicates: 0  warnings: 0

mysql> select * from t1_old1;

+------+

| id   |

+------+

|    1 |

|    2 |

|    3 |

|    5 |

+------+

4 rows in set (0.00 sec)

mysql> select * from t1_new1;

+------+

| id   |

+------+

|    2 |

|    2 |

|    3 |

|    5 |

+------+

4 rows in set (0.00 sec)

mysql> select count(*) from (select * from t1_old1 union select * from t1_new1) as t;

+----------+

| count(*) |

+----------+

|        4 |

+----------+

1 row in set (0.00 sec)

mysql> 

所以在這點上,這個方法等於是無效。

方法二: 用減法來歸零。

由於mysql 沒有提供減法操作符,這裡我們換做postgresql來檢測。

t_girl=# select count(*) from (select * from t1_old except select * from t1_new) as t;

count 

-------

0(1 row)

time: 1.809 ms

這裡檢測出來結果是0,那麼證明兩表的內容一致。 那麼我們可以針對第一種方法提到的另外一種情況做檢測:

t_girl=# select count(*) from (select * from t1_old1 except select * from t1_new1) as t;

count 

-------

1(1 row)

time: 9.837 ms

ok,這裡檢測出來結果不對,那麼就直接給出不一致的結論。

第三種: 用全表join,這個也是最爛的做法了,當然我這裡指的是在表記錄數超級多的情形下。

當然這點我也用postgresql來演示

t_girl=# select count(*) from t1_old as a full outer join t1_new as b using (id,log_time) where a.id is null or b.id is null; 

count 

-------

0(1 row)

time: 5.002 ms

t_girl=# 

結果為0,證明內容一致。

第四種: 用checksum校驗。

比如在mysql 裡面,如果兩張表的checksum值一致,那麼內容也就一致。

mysql> checksum table t1_old;

+---------------+----------+

| table         | checksum |

+---------------+----------+

| t_girl.t1_old | 60614552 |

+---------------+----------+

1 row in set (0.00 sec)

mysql> checksum table t1_new;

+---------------+----------+

| table         | checksum |

+---------------+----------+

| t_girl.t1_new | 60614552 |

+---------------+----------+

1 row in set (0.00 sec)

但是這種方法也只侷限於兩表結構一摸一樣。 比如,我修改下表t1_old的字段型別,那麼checksum的值也就不一樣了。

mysql> alter table t1_old modify id bigint;

query ok, 100 rows affected (0.23 sec)

records: 100  duplicates: 0  warnings: 0

mysql> checksum table t1_old;

+---------------+------------+

| table         | checksum   |

+---------------+------------+

| t_girl.t1_old | 3211623989 |

+---------------+------------+

1 row in set (0.00 sec)

mysql> checksum table t1_new;

+---------------+----------+

| table         | checksum |

+---------------+----------+

| t_girl.t1_new | 60614552 |

+---------------+----------+

1 row in set (0.00 sec)

所以從上面幾種資料庫提供的方法來看,用減法來歸零相對來說比較可靠,其他的方法比較適合在特定的情形下來檢測。

原創 如何從資料庫層面檢測兩表內容的一致性

一般來說呢,如何檢測兩張表的內容是否一致,這樣的需求大多在從機上體現,以保證資料一致性。方法無非有兩個,第一呢就是從資料庫著手,第二呢就是從應用程式端著手。我這裡羅列了些如何從資料庫層面來解決此類問題的方法。當然第一步就是檢查記錄數是否一致,否則不用想任何其他方法了。這裡我們用兩張表t1 old,t...

原創 如何從資料庫層面檢測兩表內容的一致性

一般來說呢,如何檢測兩張表的內容是否一致,這樣的需求大多在從機上體現,以保證資料一致性。方法無非有兩個,第一呢就是從資料庫著手,第二呢就是從應用程式端著手。我這裡羅列了些如何從資料庫層面來解決此類問題的方法。當然第一步就是檢查記錄數是否一致,否則不用想任何其他方法了。這裡我們用兩張表t1 old,t...

從資料庫層面理解 隨機 I O 順序 I O

在 談這倆概念前 先來說說 大i o vs.小i o 通常 我們把 16kb的i o認為是小i o 而 32kb的i o認為是大i o 了解i o的大小 影響到後期對快取 raid型別 lun的一些屬性的調優 當前大多數資料庫使用的都是傳統的機械磁碟 因此 整個系統設計要盡可能順序i o 避免昂貴的...