SQL-запросы внутри цикла - PullRequest
Новая
       7

SQL-запросы внутри цикла

5 голосов
/ 17 января 2011

Код Google предполагает, что вы должны ИЗБЕЖАТЬ sql запросов в цикле.Причина в том, что многократные обращения к базе данных значительно замедляют ваши сценарии.Вот пример запроса, который они задают. 

$userData = array();
foreach ($userList as $user) {
     $userData[] = '("'.$user['first_name'].'", "'.$user['last_name'].'")';
}
$query = 'INSERT INTO users (first_name,last_name) VALUES'.implode(',',$userData);
mysql_query($query);

Мои вопросы ... 1. Насколько важно не допустить ваш запрос в цикл и всегда ли его можно избежать?2. Как вы можете реализовать оператор SELECT с этой же логикой.

т.е. допустим, у меня есть этот запрос. 

$index=0;
while ($index < count($id)) {
     $result[] = mysql_query("SELECT * FROM tblInfo WHERE site_id = '".$id[$index]."' ");
     $index++;
}

Как можно выполнить этот оператор SELECT вне цикла?У меня есть большое количество операторов SELECT, которые намного сложнее, чем эта.Поэтому, если это будет сочтено необходимым, я бы хотел получить эти запросы из циклов.Если кто-то согласен с Google, вы можете опубликовать пример кода.

Любой ответ будет принят с благодарностью.

Ответы [ 3 ]

8 голосов
/ 17 января 2011

Вы можете использовать оператор MySQL IN со списком идентификаторов. 

SELECT * FROM table WHERE id IN (1,4,6,8,5,6)

Он может обрабатывать даже очень длинные списки тысяч идентификаторов (конечно, лучше, чем тысячи SELECT с). Но в таком случае вам также стоит рассмотреть дизайн вашего приложения. Если вам нужно использовать IN с тысячами идентификаторов при каждой загрузке страницы, в вашем дизайне что-то не так.

INSERT s также могут быть сведены в один запрос, см. документацию .

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

1 голос
/ 17 января 2011

Насколько важно избегать стоимости поездки туда и обратно, зависит от нескольких вещей.

Во-первых, сколько поездок вы совершаете? Если вы делаете 3 или 4, вы, вероятно, можете проигнорировать совет, если прислушаться к нему будет больно.

Во-вторых, насколько дорогой для вас обходной путь? Если обратный путь к БД занимает 100 мс, этого следует избегать гораздо серьезнее, чем если бы он занимал всего 2 мс.

В-третьих, насколько чувствителен ко времени процесс, который должен выполнять запросы? Если вы заставляете пользователя ждать, вы должны обратить на это внимание - пользователи ненавидят ждать! Если вы используете Ajax-процесс, который выполняется за кулисами и выполняет некоторую работу, возможно, это менее важно (хотя, возможно, вам все равно придется следить за тайм-аутами).

По сути, совет Google хорош, так как потраченное впустую время потрачено впустую. Однако в зависимости от конкретного случая потраченное время может быть более или менее серьезным для вас, вашей системы и ваших пользователей.

1 голос
/ 17 января 2011

Вы можете найти эту статью интересной: http://blog.fatalmind.com/2009/12/22/latency-security-vs-performance/

...