MySQL "TOP" JOIN?

программирование php MySQL базы данных sql

Доброго времени суток. У меня встал такой вопрос, раньше была 1 таблица в которой хранилось около 700 000 записей и она очень быстро растет, было принято решение разбить ее на 2 таблицы, и возник вопрос с выборкой информации так как она нужна из двух таблиц сразу, тоесть, сейчас ест 2 практически одинаковые таблицы, с разнице в названии и содержимом, столбцы и их наименования одинаковы, как и их индексы и т.д. вопрос, можно ли за один запрос вывести часть данных из одной табл. и часть из второй. Тоесть при запросе их склеить в одну табл, но не LEFT JOIN так как тогда они становятся рядом, а что-то вроде TOP JOIN )) чтобы таблицы были слиты в одну друг под другом? Или если есть альтернативный вариант, то подскажите, спасибо взарание большое!

Примечание:
Всем большое спасибо, за советы) На первый взгляд это действительно выглядит глупо просто разделить таблицу на 2, но основная выборка будет вестись из малой таблицы, и гораздо реже из обоих, и через какое-то время из мало перекидывается часть данных в большую таблицу, тоесть малая табл. получается своего рода посредником, и решил я своим способом, в случае если из первой таблицы результатов не найдено, то надо посмотреть во второй, это актуально по скольку информация 100% не дублируеться. И если результат найден в первой, то во вторую мы и не смотрим)

Примечание:
Подробнее, есть 2 тбалицы, "Новости" и "Архив новостей", как можно понять, Архив содержит все новости, в таблице "Новости" в день окло 3 тыс, набирает, и каждый день часть скидывает в Архив, при таком апдейте, архив начинает тормазить, и как вариант было решено разбить на 2 части, по скольку апдейт проходит ежедневно, то он будет проходить с малым архивом, а каждые 3 месца будет проходить 2-ой апдейт между малым и большим архивом. Возможно я действительно усложняю, я это даже понимаю, но надо чтобы это работало быстрее) Может просто железка уже нетянет, но по сути можно оптимизировать я думаю, может просто апдейт разбить на небольшие кусочки, чтобы за раз вставлялось не 2к записей, а по 300 например в цикле. Просто сам апдейт довольно сложный и системе предварительно надо перелопатить все 700 000 для сравнения с теми которые заходят новые. Наверно кучно объяснил, но как-то так.
Ответы:
Вам нужен UNION. Но судя по описанию проблемы и её решению, вы гребёте явно не в том направлении. У меня есть подозрение, что таблица просто неправильно спроектирована и вы не знаете что такое индексы.
Такое впечатление, будто Вы думаете, что выборка из двух таблиц по 350k записей будет работать быстрее, чем из одной с 700k записей... Так вот, это сильно не так. :)
#1
Такие усложнения очень редко бывают оправданы, однако, если вы опишите задачу более подробно, мы сможем подсказать пути к оптимизации.
Хммм, вы решили придумать партиционирование таблиц?
Почему не использовать реализацию на уровне субд?
>>> Хммм, вы решили придумать партиционирование таблиц?
Для такого поведения давно придумали более очевидные и интересные штуки, типа кеширования ( как пример, memcached), которое можно гибко настроить, которое лучше вас построит статистику запросов и закеширует именно те, к которым действительно часто будут обращаться.


12 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.