SELECT 1 from DUAL: MySQL

При просмотре журнала запросов я вижу нечетный шаблон, который у меня нет для объяснения.SELECT 1 from DUAL: MySQL

После практически каждого запроса у меня есть «выбрать 1 из DUAL».

Я понятия не имею, откуда это происходит, и я явно не делаю запрос явно.

Бревно в основном выглядит следующим образом:

10 Query  SELECT some normal query 
    10 Query  select 1 from DUAL 
    10 Query  SELECT some normal query 
    10 Query  select 1 from DUAL 
    10 Query  SELECT some normal query 
    10 Query  select 1 from DUAL 
    10 Query  SELECT some normal query 
    10 Query  select 1 from DUAL 
    10 Query  SELECT some normal query 
    10 Query  select 1 from DUAL 
    ...etc...

Кто-нибудь сталкивался с этой проблемой раньше?

MySQL Версия: 5.0.51

Driver: Java 6 приложения с помощью JDBC. MySQL-разъем-Java-5.1.6-bin.jar

Пул соединений: Обще-ДБХП 1.2.2

validationQuery был установлен в положение "выберите 1 из DUAL" (очевидно) и, видимо, пул соединений по умолчанию testOnBorrow и testOnВведите значение true, если запрос проверки не равен нулю.

Еще один вопрос, который возникает для меня, заключается в том, нужен ли мне , чтобы получить запрос проверки, или если я могу получить повышение производительности, отключив его или, по крайней мере, уменьшив частоту, с которой он используемый. К сожалению, разработчик, который написал наш «менеджер баз данных», больше не с нами, поэтому я не могу попросить его оправдать его для меня. Любой вход был бы оценен. Я собираюсь через API и Google некоторое время и отчитаться, если найду что-нибудь полезное.

EDIT: добавлено еще информации

edit2: Добавлена информация, что было запрошено в правильном ответе для всех, кто находит это позже

источник

2009-05-27 biggusjimmus

Какой пул вы используете? –

Это может исходить из пула подключений вашего приложения. Мы используем простой запрос для проверки соединения.

Просто быстро взглянул на источник в mysql-connector-j, и он не появился там.

Наиболее вероятной причиной является пул соединений.

Общие пулы соединений:

Обще-ГСБД имеет свойство конфигурации validationQuery, это в сочетании с testOnBorrow и testOnReturn может привести заявления, которые вы видите.

c3p0 имеет preferredTestQuery, testConnectionOnCheckin, testConnectionOnCheckout и idleConnectionTestPeriod

За то, что это стоит, я, как правило, настроить тестирование подключения и проверку/одолжить даже если это означает небольшую дополнительную сетевую болтовню.

источник

2009-05-27 20:47:58

Большое спасибо за ваше редактирование, поскольку оно поместило меня прямо по правильному пути, как указано в моем отредактированном OP. Каковы последствия удаления запроса проверки или установки testOnBorrow/testOnReturn/etc на false? Есть ли способ уменьшить частоту, а не удалять ее полностью? – biggusjimmus

Что обычно происходит, если у вас нет какой-либо проверки, так это то, что время соединения db отключается в течение ночи, а первые X входа в систему утрачиваются, потому что они имеют устаревшее соединение. commons-dbcp имеет testWhileIdle, это запустит запрос проверки в другом потоке, а тайминги будут настраиваться. Как я уже сказал выше, я просто оставлю это на testOnBorrow, пока вы действительно не нажмете ограничения производительности своей сети/оборудования. –

Спасибо, вы были чрезвычайно полезны. =) – biggusjimmus

«двойное» имя таблицы/объекта - это конструкция Oracle, которую поддерживает MySQL для совместимости, или для обеспечения цели для запросов, для которых нет цели, но люди хотят, чтобы все было тепло и нечетко. Например.

select curdate()

может быть

select curdate() from dual

Кто-то может обнюхивать вас, чтобы увидеть, если вы работаете в Oracle.

источник

2009-05-27 20:48:59

Я не вижу, как это может определить, используют ли они оракул. Тем более, что вы заявляете в своем ответе, что MySQL также поддерживает его. Я не думаю, что это ограничено этими двумя. Это просто общее имя фиктивной таблицы. Я также видел, как люди добавили таблицу DUAL в базы данных PostgreSQL для обеспечения совместимости. –

Я выполнил 100 вставок/дельтах и протестировал их как на DBCP, так и на C3PO.

DBCP :: testOnBorrow = true влияет на время отклика более чем на 4 раза.

C3P0 :: testConnectionOnCheckout = true влияет на время отклика более чем на 3 раза.

Вот результаты: ГСБД - BasicDataSource

Среднее время 100 операций (операции вставки) testOnBorrow = ложные :: 219.01 мс testOnBorrow = Истинные :: 1071.56 мс

Среднее время 100 операции (удаление OPRATION) testOnBorrow = ложные :: 223,4 мс testOnBorrow = True :: 1067.51 мс

C3PO - ComboPooledDataSource Avera GE время для 100 операций (операция вставки) testConnectionOnCheckout = ложные :: 220,08 мс testConnectionOnCheckout = TRUE :: 661.44 мс

Среднее время для 100 операций (удаление Opration) testConnectionOnCheckout = ложные :: 216,52 мс testConnectionOnCheckout = истина :: 648,29 мс

Сопротивление: установка testOnBorrow = true в DBCP или testConnectionOnCheckout = true в C3PO влияет на производительность в 3-4 раза. Есть ли другие настройки, которые повысят производительность.

-Durga Prasad

источник

2010-02-18 11:20:45

SELECT 1 from DUAL: MySQL

ответ

Смежные вопросы