2015-10-26 3 views
0

Я с этой проблемой, вот мои операторы SQL:MySQL запросов пропустить некоторые строки иногда

select * from tb1 where id > the_max_read order by id 

В таблице ТВ1 является мониторинг изменений некоторых других таблиц, поэтому он продолжает расти.
Переменная the_max_read - это максимальный идентификатор, который уже прочитал программа.
Я запускаю этот sql через C++ и используя mysql_query функцию mysql и сохраняю результат с помощью mysql_store_result.
Двигатель БД innodb.

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

Например, скажем, у меня есть эта таблица:

| -- id | -- name| 
| 834370 | name1 | 
| 834371 | name2 | 
| 834372 | name3 | 
| 834373 | name4 | 
| 834374 | name5 | 
| 834375 | name6 | 

и the_max_read = 834371, когда запустить выше SQL, результат содержит только 834374 и 834375.

Хотя эта таблица может быть вставлена ​​в некоторые новые строки другими программами, но я до сих пор не могу понять, почему она просто пропускает некоторые строки, это почти самый простой sql.

+0

Каковы ваши настройки блокировки? Особенно автокоммит и уровень изоляции. Мне неудивительно, что строки, которые добавляются разными транзакциями, не отображаются напрямую. – flowit

+0

@flowit Я попытался сохранить Id в моей программе, если минимальное чтение id не является текущим max_read + 1, я снова прочитаю и попытаюсь в течение 30 секунд до замены текущего max_id. Считаете ли вы, что какая-то транзакция может занять более 30 секунд? Все настройки MySQL установлены по умолчанию. –

ответ

0

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

Попробуйте прочитать неизрасходованного данные: http://dev.mysql.com/doc/refman/5.1/en/set-transaction.html

например

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; 
select * from tb1 where id > the_max_read order by id; 
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; 

Надеюсь, что это поможет.

+0

Есть ли шанс, что я могу прочитать некоторые грязные данные? Что мне делать, чтобы мои данные были правильными? –

+0

В моем понимании вашего примера, в момент, когда вы читали 834371, записи 834373 и 834372 являются «грязными данными» (еще не зафиксированными). Однако вы ожидаете увидеть записи на своем выходе. Но записи все равно могут отбросить назад. На мой взгляд, ваша текущая ситуация правильная, но если вы хотите видеть записи, когда читаете, то вы будете читать нефиксированные данные. – Phuthib

+0

Я уверен, что 834373 и 834374 не откатываются, у меня есть этот db сейчас и Я вижу, что они там. Я думаю, возможно, транзакционные транзакции 834373 и 834734 действительно стоят более 30 секунд. Эти две строки вставляются триггерами таблиц, которые я хочу контролировать. Возможно, некоторые операции с этими таблицами выполняются слишком медленно. Сейчас я немного отчаялся, так невежественный. –