присоединяется к выступлениям

в компании, где я пришел на работу, они запускают реляционную базу данных PHP / Mysql. Я всегда думал, что если бы мне нужно было потянуть другую информацию из разных таблиц, что я мог бы просто сделать простое присоединение к тому, чтобы потянуть такие данные, как ....

SELECT table_1.id, table_2.id FROM table_1 LEFT JOIN table_2 ON table_1.sub_id = table_2.id

Когда я добрался до того, как я работаю, это то, что они делают.

<?php $query = mysql_query("SELECT sub_id FROM table_1");
while($rs = mysql_fetch_assoc($query)) {
    $query_2 = mysql_fetch_assoc(mysql_query("SELECT * FROM table_2 WHERE id = '{$rs['sub_id']}'"));
    //blah blah blah more queries
?>

Когда я спросил, почему сделал это во-вторым образом, они сказали, что он на самом деле бежал быстрее, чем присоединение. Они управляют базой данных, имеющей миллионы записей на разных таблицах, а некоторые таблицы немного ширины (ROW-WISE). Они сказали, что они хотели избежать присоединений в том случае, если плохо выполненная запрос может заблокировать таблицу (или несколько из них). Еще одна вещь, которую нужно помнить, так это то, что в этой базе данных есть массивный строитель отчетов, прикрепленный к этой базе данных, который клиент может использовать для создания собственного отчета, и если они сходят с ума и создают большой отчет, он может привести к тому, что может вызвать некоторое хаос.

Я был смущен, поэтому я подумал, что вы выбросите это там для общего общего программирования. Это может быть вопрос мнения, но это действительно быстрее сделать заявление о том, что один большой запрос, чтобы тянуть много рядов, за которым следует много маленьких крошечных подпросов, если вы будете) или сделать присоединение (тянуть Больший запрос один раз, чтобы получить все необходимые данные). Пока индексы сделаны правильно, это имеет значение? Еще одна вещь, которую следует полагать, что текущая БД находится в формате InnoDB.

Спасибо!

Обновление 8/28/14

Итак, я подумал, что я добавлю обновленную информацию и что работал более долгосрочным. После этой дискуссии я решил восстановить генератор отчетов здесь на работе. У меня нет окончательных номеров результатов, но я думал, что поделился тем, что было результатом.

Я думаю, что пошел немного сверхугольника, потому что я повернул весь отчет (это довольно динамично, насколько возвращено данными), в массивную регистрацию. Большинство присоединений, если не все присоединяются к значению для первичного ключа, чтобы все они действительно действуют действительно быстро. Если в отчете сообщалось, что в отчете по словам 30 столбцов данных для тяги, и он вытащил 2000 записей, каждое поле выполнило запрос для получения данных (потому что этот кусок данных может быть на другом поле). 30 x 2000 = 60000 и даже при сладком времени запроса 0,0003 секунды на запрос, это было еще 18 секунд только времени запроса (что в значительной степени то, что я помню это быть). Теперь, когда я перестроил запрос как массивное соединение на кучу первичных ключей (где это возможно), тот же отчет загружен примерно через 2-3 секунды, и большую часть этого времени загружали HTML. Каждая запись, которая возвращается запускается между 0-4 дополнительными запросами в зависимости от необходимых данных (может не понадобиться никаких данных, если она может привлечь его в присоединениях, что происходит 75% времени). Таким образом, одинаковые 2000 записей будут вернуть дополнительные 0-8000 запросов (намного лучше, чем 60000).

Я бы сказал, что то время заявление полезно в некоторых случаях, но как указано ниже в комментариях, бенчмаркинг - это то, о чем это все. В моем случае присоединения были лучшим вариантом, но в других областях моего сайта о том, что заявление, а то время более полезное. В одном случае у меня есть отчет, в котором клиент может запросить несколько категорий, и только возвращает данные для этих категорий. Что случилось, у меня было Catechation in (..., ..., ..., .., etc etc etc и т. Д.) с 50-500 IDS и индекс будет задыхаться и умереть в моих руках, как я держал его в финальных моментах. Итак, что я сделал, было распространено идентификаторы в группах по 10 и пробежал тот же запрос X / 10 раз, и мои результаты были принесены способ быстрее, чем раньше, потому что индекс любит иметь дело с 10 идентификаторами, а не 500, так Я видел большое улучшение моих запросов, тогда из-за того, что делает то время заявление.