MySQL - запрос зарегистрирован, но не вставлен в базу данных

Question

Я работаю в автоматизированной системе в стеке LAMP и испытываю несколько пропусков запросов, т.е. запрос выполняется PHP, но его нет в базе данных, и ошибок нет.

Итак, я включил ведение журнала всех запросов в mysql, чтобы увидеть, достигает ли этот запрос вообще и достаточно ли он существует. Это произошло прямо сейчас, поэтому я объясню на примере:

(Кстати, не пытайтесь найти ошибки в запросах. Их нет. Такие запросы выполняются большую часть времени)

PHP выполняет:

$saveOrderQ = "INSERT INTO orders (order_id, parent_order, date_created, status, type, phase, ticker, quantity, entry_price, tp1, tp2, strategy, relative_volume, distance_from_close) VALUES ({$order->order_id}, 0, '$now', 'OPEN', 'BUY', 0, '$ticker', $positionsSize, $price, $tp1, $tp2, {$tickerAttr['strategy']}, $relativeVol, $distanceFromClose)";
writeToLog($saveOrderQ); // I get the query in the log. This function's log is seperate from mysql log
$saveOrder = mysqli_query($connect, $saveOrderQ);
if(!$saveOrder){
    writeToLog("Failed to insert file 30daybreakout.php Line 59. Error: ".mysqli_error($connect)."\nQuery: $saveOrderQ"); // no error received
}

MySQL Журнал примерно в одно и то же время:

2020-04-13T09:23:02.222315+05:30    127059 Query    SELECT order_id FROM orders WHERE ticker = 'NSE:BALMLAWRIE' AND DATE(date_created) = '2020-04-13' AND parent_order = 0 AND phase < 3
2020-04-13T09:23:02.356930+05:30    127059 Query    INSERT INTO orders (order_id, parent_order, date_created, status, type, phase, ticker, quantity, entry_price, tp1, tp2, strategy, relative_volume, distance_from_close) VALUES (200413000329794, 0, '2020-04-13 09:23:01', 'OPEN', 'BUY', 0, 'NSE:BALMLAWRIE', 54, 91.3, 94.95, 98.6, 1, 108.87022900763, 6.5966141272621)

Эта запись просто отсутствует в таблице заказов.

Я думаю, что таблица заказов каким-то образом заблокирована, но я точно не знаю. Как мне устранить ее?

Answer 1

Также проверьте «Предупреждения». Сделайте это после проверки на наличие ошибок и перед выполнением любого другого SQL, выполнив SHOW WARNINGS LIMIT 11 и напечатав результаты (если есть). Предупреждения не так серьезны, как ошибки, но иногда они дают понять, что все не так, как ожидалось, что приводит к обнаружению реальной ошибки.

Только недавно PHP переключился с 32-разрядных сборок на 64- немного. То есть было небезопасно представлять большие числа в PHP. Какую версию PHP вы используете? Поскольку проблема возникает «иногда», возможно, вы получаете ошибки округления выше 31, 32 (размеры INT) или 53 бита (размер DOUBLE). Чтобы помочь с этим, пожалуйста, укажите некоторые c номера и скажите, что сработало, а что - нет. (200413000329794 занимает 48 бит, поэтому он ничего не потеряет, если он пройдет через DOUBLE в PHP.)

Размещение кавычек вокруг чисел в MySQL не имеет значения: WHERE foo = 123 и WHERE foo = "123" работать так же , если foo в целых числах, а не в char .

Какое значение autocommit вы используете? На мой взгляд, OFF подвержен ошибкам, потому что вы должны помнить COMMIT в конце концов. И слишком легко забыть сделать это или взять ветку, которая иногда избегает COMMIT. Затем, когда соединение закрывается, эта открытая транзакция автоматически ROLLBACKd.

(еще несколько «незапрошенных советов»). В комментарии было предложено изменить дату, чтобы сделать ее «саргисной». Требуется некоторое расширение:

AND date_created >= '2020-04-13'
AND date_created  < '2020-04-13' + INTERVAL 1 DAY

(еще несколько «незапрошенных советов»). При этом это может быть оптимальным показателем:

INDEX(ticker, parent, date_created)

Подробнее (В основном "fishing as str aws")

При вставке константы цифры c в поле нумерации c или при сравнении этого в предложении WHERE значение не имеет значения: цифра c константа указана.

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

С autocommit=ON и без явных транзакций, у меня Проблемы с представлением, как может возникнуть тупик. Укажите SHOW ENGINE INNODB STATUS; сейчас и всякий раз, когда вы подозреваете, что проблема повторяется.

Пожалуйста, укажите SHOW CREATE TABLE и запрос, который объявляет, что строка отсутствует. Неправильное использование FLOAT при поиске нецелых чисел может привести к проблемам с округлением.

Answer 2

Я думаю, что вы должны указать структуру таблицы, или вы можете попробовать запустить этот журнал запросов в вашем MySQL GUI,

INSERT INTO orders (order_id, parent_order, date_created, status, type, phase, ticker, quantity, entry_price, tp1, tp2, strategy, relative_volume, distance_from_close) VALUES (200413000329794, 0, '2020-04-13 09:23:01', 'OPEN', 'BUY', 0, 'NSE:BALMLAWRIE', 54, 91.3, 94.95, 98.6, 1, 108.87022900763, 6.5966141272621)

Я думаю, что есть ошибка, как ваш запрос не выполнить условие таблицы уникальных ключей или что-то в этом роде.

Answer 3

проблема в таких случаях может быть одной из следующих:

1. несоответствие типов данных
2. нарушение первичного ключа
3. оценка внешнего ключа наиболее вероятна в вашем случае это 2-й или 3-й.

Только для тестирования: попробуйте использовать INSERT ON DUPLICATE KEY UPDATE ....: вместо вставки только в ваш SQL. .. дайте нам знать.

Answer 4

Это не окончательное решение, но сейчас я использовал следующий код, чтобы создать некоторую избыточность в системе и, надеюсь, обойти эту проблему.

$saveOrderCount = 0;
do {
    $saveOrder = mysqli_query($connect, $saveOrderQ);
    $saveOrderCount++;
} while(!mysqli_affected_rows($connect) and $saveOrderCount < 3); //Will retry upto a max of 3 times

if($saveOrderCount >= 3){
    writeToLog("Failed to insert in file test.php Line 59. Error: ".mysqli_error($connect)."\nQuery: $saveOrderQ");
}