Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
Всем привет. Подскажите, как лучше сравнить 2 большие таблицы (1.8млрд) по PK? Есть 2 таблицы, из одной переносились данные в копию разными методами (триггер+insert into), хочу проверить, не потерялись ли при переносе какие то строки. Возможно ли на таком массиве выявить, каких ID недостает в таблице получателе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 03:52 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 04:22 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
fkthat, Сколько по времени данная конструкция обработает такой объём? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 11:43 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
teCa, на таких объемах может достаточно долго. я бы написал так: Код: sql 1. что бы добиться оператора MJ:right anti semi join иначе у вас может получиться план где будет соединение слиянием с последующим оператором фильтра по c2.id is null ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 12:17 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 15:02 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
felix_ff, Впрочем, судя по планам, твой вариант пошустрее должен быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 15:28 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
fkthat, на мелких объемах разницы видно не будет. + важным фактором является как раз количество отсутствующих строк во второй таблице. если скажем в обоих таблицах по 2 лярда, а разница между строками ~100k, то оба запроса в плане потребления ресурсов будут почти идентичны. а вот если разница будет большой, к примеру ~овер 10 лямов строк, то тогда план с оператором фильтра потребит больше циклов CPU ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 15:36 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
Есть смысл попробовать вариант с EXCEPT, он работает вполне сносно при сверке крупных массивов данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 15:36 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, вот кстати хорошая статья по сравнению https://sqlperformance.com/2012/12/t-sql-queries/left-anti-semi-join ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 15:49 |
|
||
|
Сравнить 2 большие таблицы по PK ??
|
|||
|---|---|---|---|
|
#18+
felix_ff teCa, на таких объемах может достаточно долго. я бы написал так: Код: sql 1. что бы добиться оператора MJ:right anti semi join иначе у вас может получиться план где будет соединение слиянием с последующим оператором фильтра по c2.id is null Воспользовался этим вариантом, сравнилось за 22 минуты, более чем хорошо. Выявил 650 тысяч отсутствующих строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2020, 16:53 |
|
||
|
|

start [/forum/topic.php?fid=46&gotonew=1&tid=1685515]: |
0ms |
get settings: |
5ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
20ms |
get topic data: |
7ms |
get first new msg: |
3ms |
get forum data: |
3ms |
get page messages: |
34ms |
get tp. blocked users: |
2ms |
| others: | 211ms |
| total: | 297ms |

| 0 / 0 |
