Я могу вынудить mysql выполнить подзапрос сначала?

Таким образом от ограниченной информации Вы имеете, это может быть комбинацией одной или нескольких вещей:

  • Плохое использование "кучи", т.е. дважды освобождает, читайте после свободный, запишите после свободный, установив флаг HEAP_NO_SERIALIZE с выделениями, и освобождает от нескольких потоков на той же "куче"
  • Из памяти
  • Плохой код (т.е. переполнение буфера, недостаточные наполнения буфера, и т.д.)
  • проблемы "Синхронизации"

, Если это во всех первых двух, но не последнем, необходимо было поймать его к настоящему времени с любым pageheap.exe.

, Который наиболее вероятный означает, это происходит из-за того, как код получает доступ к общей памяти. К сожалению, разыскивание, которое будет довольно болезненным. Несинхронизируемый доступ к общей памяти часто проявляет, поскольку странная "синхронизация" выходит. Вещи как не использование получают/выпускают семантику для синхронизации доступа к общей памяти с флагом, не использование блокировок соответственно, и т.д.

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

кроме того, если можно легко перенаправить выделения к нескольким "куче", Вы могли бы хотеть попробовать это, чтобы видеть, решает ли это или проблему или приводит к большему reproduceable ошибочному поведению.

, Когда Вы тестировали с VS2008, Вы работали с HeapVerifier с набором Памяти Варенья к Да? Это могло бы уменьшить влияние производительности средства выделения "кучи". (Плюс, необходимо работать с ним, Отладка-> Запускается с Верификатора Приложения, но можно уже знать это.)

можно также попытаться отладить с Windbg и различным использованием! команда "кучи".

MSN

8
задан skynetroot 19 November 2009 в 21:29
поделиться

5 ответов

SELECT  `table_1`.*
FROM    `table_1`
INNER JOIN
        `table_2` [...]
INNER JOIN
        `table_3` [...]
WHERE   `table_1`.`id` IN
        (
        SELECT  `id`
        FROM    [...]
        )
        AND [more conditions]

Если внутренняя таблица правильно проиндексирована, подзапрос здесь вообще не «выполняется» в строгом смысле слова.

Поскольку подзапрос является частью В выражении условие помещается в подзапрос и преобразуется в EXISTS .

Фактически, этот подзапрос вычисляется на каждом шаге:

EXISTS
(
SELECT  NULL
FROM    [...]
WHERE   id = table1.id
)

Фактически вы можете увидеть его в подробное описание предоставлено EXPLAIN EXTENDED .

Вот почему он называется DEPENDENT SUBQUERY : результат каждой оценки зависит от значения table1.id . Подзапрос как таковой не коррелируется, коррелируется оптимизированная версия.

14
ответ дан 5 December 2019 в 07:58
поделиться

это известная ошибка в mysql: http://bugs.mysql.com/bug.php?id=25926

полезный обходной путь - сдвинуть подзапрос в другой выберите * из (подзапрос) как подзапрос типа dt .

4
ответ дан 5 December 2019 в 07:58
поделиться

Лучший способ - поместить условия WHERE для table1 в подзапрос в предложение FROM. EG:

SELECT `table_1`.* 
FROM (
      SELECT * FROM `table_1` WHERE `table_1`.`id` IN (...)
     )
  INNER JOIN `table_2` [...]
  INNER JOIN `table_3` [...]
WHERE [more conditions]
2
ответ дан 5 December 2019 в 07:58
поделиться

Вы можете сначала выделить результат подзапроса во временную таблицу, а затем присоединиться к ней в основной запрос.

2
ответ дан 5 December 2019 в 07:58
поделиться

К сожалению, нет, вы не можете. Подзапросы фактически запускаются один раз для каждой строки внешнего запроса.

Я бы фактически предложил вам преобразовать это в другое соединение, используя table_1.id в качестве ключа к другой таблице.

-1
ответ дан 5 December 2019 в 07:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: