Здравейте,

имам следния проблем : Да си представим, че имаме таблица А и таблица В. Всяка от тези таблици има само по една колона тип инт, която се нарича ИД примерно. Целта ми е да намеря всички ИД-та от таблица А които не се срещат в таблица Б. Пробвах следното :

select A.id from A left join B on A.id=B.id where B.id is null

Това работи, но е аааадски бавно. При малко по-натоварен сървър отнема към 10-15 часа!!! В двете таблици има м/у 10 и 20 000 000 записа, като 99.99 % се повтарят, има най-много 20тина, които не се срещат в таблица Б.

Търся по-бърз начин за намиране на липсващите записи. Отворен съм за всякакви предложения.

Благодаря предварително



П.С.
използвам mysql 4.0.20-standard ( не ме питайте защо, не мога да го променя ), едната таблица (тази с по-малкото записи) е InnoDB, а другата - MyISAM

Съдържаниет е скрито
Влезте за да го видите

Избрал си оптималната заявка предвид структурата на данните, която си описал, но все пак става въпрос за изчислението на 40 трилиона комбинации, така че е напълно нормално да отнеме повечко време.

Предвид на версията на MySQL, която използваш и съответно невъзможността да използваш спусъци, имаш ли възможност да контролираш вкарването в тези две таблици по някакъв начин и колко често се случва това? Изобщо можеш ли да дадеш малко повече информация за процесите, които са свързани с тези данни - откъде идват, колко често, и т.н.

Everything louder than everything else...

Мдам, може би трябваше да опиша ситуацията, накратко :
Обслужвам един голям онлайн шоп за книги, ЦД-та и всякакви други електронни и печатни медии. Задачата ми е за всеки един артикул да генерирам един ХТМЛ файл, това се прави за целите на Гугъл оптимизацията. Таблицата Б се манипулира от операторите на сайта, добавят нови данни, променят и т.н. Посредством mysql репликация промените се отразяват на моя сървър. Всеки ден генерирам нови ХТМЛ-и за променените артикули и в таблица А записвам ИД-тата на новогенерираните страници. До тук всичко изглежда лесно. Но преди няколко седмици излезе проблем с изтритите артикули. Когато от таблица Б се изтрие даден артикул, ХТМЛ файла за него остава онлайн и все още може да бъде достигнат през Гугъл. Това по принцип не би трябвало да е проблем, но се оказа че даже е голям такъв. Собственика на сайта поиска от мен да генерирам празни страници за всеки един изтрит артикул (да пише "този продукт вече не се поддържа ала бала ..."). Оказа се, че софтуера, който ползват за обслужване на сайта няма възможност да даде справка за изтритите артикули, те просто в един момент изчезват от таблица Б. Единственото решение, до което стигнах е периодично да сравнявам списъка на генерираните страници със списъка на актуалните артикули и при разлика да генерирам празни страници за продуките. Това е и целта на горното "безумие"

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Без да имам опит в репликацията с MySQL, това за което се сещам е да се опиташ да четеш по някакъв начин

Съдържаниет е скрито
Влезте за да го видите

В отговор на:

---

Колкото до генерирането - не можеш ли вместо да генерираш файлове, да имаш един PHP скрипт, който да ги генерира динамично?

---

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Че Гугъл откъде може да знае дали въпросните HTML-и са статични или динамични?!

Съдържаниет е скрито
Влезте за да го видите

Изкушавам се да ти предлогжа една схема която за съжаление се съмнявам, че ще поработи.

> използвам mysql 4.0.20-standard

Пускаш при теб втори сървър с 5.0.x

* Закачаш го да репликира или директно от отдалечения Master или от твоя 4.0.20
* Указваш му да репликира само таблица Б

* Върху таблица Б дефинираш спусък при DELETE който да вмъква id на изтритите редове в таблица В

Примерно:

CREATE TRIGGER del_trigger BEFORE DELETE ON b FOR EACH ROW INSERT INTO deleted VALUES(OLD.id);


При тази постановка можеш да вържеш приложението което генерира файловете към двата твои сървъра едновременно и когато те интересуват изтритите редове да питаш В таблицата на 5.0

Още сложен вариант би било да дефинираш тази таблица В като FEDERATED с отдалечен оригинал на твоя 4.0.20 сървър.

Дали всичко това ще сработи честно казано не знам.

За съжаление 4.0 -> 5.0 репликация не е нещо на което бих разчитал напълно. Много зависи от структурата на конкретните таблици.

Поради тази причина не ти препоръчвам направо да смениш твоя локален сървър с 5.0. На теория би трябвало да може.

Съдържаниет е скрито
Влезте за да го видите

>> В двете таблици има м/у 10 и 20 000 000 записа, като 99.99 % се повтарят

Защо не направиш 2 времении таблици A2 и B2, само с 1 колона id (неповтарящи).
ПОСЛЕ да ги индексираш.
И да си пускаш заявата за A2 и B2.

Явно не си ме разбрал правилно : 99.99% от записите в таблица А ги има и в таблица Б. Целта ми е да намеря кои записи ги има само в А и ги няма в Б.

Иначе локално за таблиците ИД-тата са си уникални

Съдържаниет е скрито
Влезте за да го видите

Интересна идея, но и на мен ми се струва че няма да е много читава. Имам лоши спомени от репликация м/у различни major версии на mysql (в интерес на истината тогава беше м/у 3.х и 4.х но се съмнявам че ще е много по-различно).

В момента се боря със хората от сайта да ъпгрейднем техния mysql до 5.х, ако не успея пак ще мисля какви магии да правя.

Съдържаниет е скрито
Влезте за да го видите