Форум пользователей MySQL

Поставил
  net_read_timeout=30
  net_write_timeout=60
На всякий случай даже поставил
  interactive_timeout=28800
  wait_timeout=28800

Но это не помогло....причём, я так понял, эти значения в секундах....но ошибка всё равно появляется...раньше, чем успевает пройти 30 секунд!
Запрос такой: "SELECT * FROM blob_tbl WHERE id = 224;"
Когда запрос проходит, то он проходит за десятки милисекунд, то есть проблема не в нагрузке на сервер, к тому же у меня сервер и клиент стоит на одной машине.
Я посылаю запрос с EMS MySQL Manager'а и из своей проги на дельфях, используя DirectMySQL, так что проблема мне кажется в сервере....возможно в настройках.....хотя я пробовал переустанавливать сервер....

Может быть таблицы глючные....может испортились как-то в процессе использования....как можно проверить это? Я слышал есть какой-то repair? Может это поможет?

А сейчас есть какие-нибудь мысли?)

Отредактированно iCode (26.12.2007 10:50:16)

А ключик на поле id есть?

rgbeast написал:

а. REPAIR TABLE blob_tbl

Таблица InnoDB не поддерживает команду REPAIR

rgbeast написал:

б. ALTER TABLE blob_tbl ENGINE=InnoDB;
Какая версия MySQL?

Таблицы уже InnoDB, я писал это в первом сообщении...там же написано, что версия MySQL - 5.0.18.

paulus написал:

А ключик на поле id есть?

Вот DDL, который мне сгенерил EMS:
CREATE TABLE `blob_tbl` (
  `id` smallint(6) unsigned NOT NULL auto_increment,
  `body` mediumblob,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 PACK_KEYS=0 ROW_FORMAT=COMPACT;

paulus написал:

Еще посмотрите в логе не перезапускается ли сервер при в это время

А где это смотреть? Где логи лежат?

paulus написал:

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

Я тоже думал, что это какая-то ненужная фигня...
Её EMS сам добавил.

paulus написал:

А вообще, такой запрос должен отрабатывать моментально при условии стабильной работы
базы. Попробуйте обновить MySQL до нормальной версии какой-то?

И работал....не знаю, что случилось....в том-то и дело!
До какой версии ты бы посоветовал обновить?

Я тоже думал, что это какая-то ненужная фигня...
Её EMS сам добавил.

Не сам, а по вашему указанию.

когда создавали поле вы поставили несколько галок. В частности Unique и Primary. А это не одно и тоже.
Primary всегда уникален, поэтому по ВАШЕМУ запросу Unique EMS создал дополнительный уникальный индекс, что в вашем DDL и наблюдается.

Отредактированно Shopen (10.01.2008 03:26:55)

То, что показывает SHOW TABLE STATUS - это оценка количества строк,
она может варьироваться немного

Напишите какой-нибудь тестовый сценарий, который несколько раз выбирает
строки подряд в одном соединении, и потом в разных. Оно не будет отдавать
результат?

См. переменные wait_timeout и interactive_timeout http://dev.mysql.com/doc/refman/5.1/en/ … it_timeout

Устроим сегодня день археолога

По непонятной мне причине стали отваливаться запросы... В БД есть несколько сотен таблиц, в цикле отправляем запросы с COUNT(*) по определённой клаузе для каждой таблицы. В итоге не всегда удаётся достучаться до всех таблиц, получаем "Lost connection to mysql server during query". Раньше вместо COUNT(*) была выборка самих данных и всё работало как часики, но вот переделали скрипты на подсчёт самих записей и всё, теперь сервер периодически отваливается. Отваливается в основном на одной и той же таблице, но не всегда на ней и не всегда вообще отваливается В phpMyAdmin проблемные запросы выполняются без проблем.

Будут ли какие-либо идеи по решению проблемы? ПамажЫте кто чем сможет))

Если закрыть старые темы, то просто будут появлятся такие же новые)))

Я бы понял, если б ошибка была постоянно, а так она то есть, то нет... В скриптах таймауты наоборот снимаем, ни к чему они Дело в том, что в цикле есть только один слип на 30 секунд, который включается только в определённых ситуациях. Собственно этих ситуаций пока не возникало Да и что там 30 секунд-то, у нас часами коннекты висят и все живы и здоровы. А тут прям ума не приложу... Скрипт, как правило, обрабатывается за несколько секунд.

Может ли быть проблема из-за нехватки памяти? Кстати, по памяти сразу вопрос: когда юзаем Memory табличку на 250мб данных, то не редко возникает ошибка нехватки памяти. Собственно вопрос в том, как можно увеличить используемую память для MySQL? Это делается в пределах настройки мускля или на уровне ОС? Смотрели тесты, в момент возникновения ошибки свободная память ещё имеется.

Запросы в другой среде естественно обрабатываются без проблем
Сценарии на пхп

А max_heap_table_size при чём? Несчастный COUNT порождает ошибку, при чём не всегда)) Я вот заметил, что мускль отваливается на таблицах с большим количеством данных, а на клаузном поле, оказалось, даже индекса нет... Проставил индексы на нескольких таблицах, теперь сбои начинаются на других))

Это всё хорошо, но я по прежнему не вижу логики. Раньше запрос возвращал сами данные и ошибок не возникало, а сейчас просто считает кол-во записей, что иногда вызывает ошибку. Вроде наоборт кеши должны меньше памяти требовать и т.п.

Да, в PHP действительно не ставятся таймауты

Интересует следующее: выживает ли сервер (\s, смотреть uptime), отрабатывают
ли запросы нормально с той же машинки, но из консольного клиента?

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