Методы выявления ошибок в SQL приложении

Проблемы с неправильными данными возникают не только в случае с SELECT аналогичным рассмотренным ранее, но и в случае запросов, модифицирующих данные. Так называемых DML запросов.


mysql> create table t1(f1 int);

Query OK, 0 rows affected (0.01 sec)

mysql> create table t2(f2 int);

Query OK, 0 rows affected (0.08 sec)

mysql> insert into t1 values(1);

Query OK, 1 row affected (0.01 sec)



mysql> select * from t1;

+------+

| f1   |

+------+

|    1 | 

+------+

1 row in set (0.00 sec)



mysql> delete from t1, t2 using t1, t2;

Query OK, 0 rows affected (0.00 sec)

Данный запрос должен был бы удалить все строки в таблицах t1 и t2: использован using t1, t2; и нет предиката WHERE. Однако это не так.

Обратите внимание на строчку "0 rows affected". Она обозначает, что было удалено 0 строк, то есть ничего удалено не было! Почему?


mysql> select * from t1;

+------+

| f1   |

+------+

|    1 | 

+------+

1 row in set (0.00 sec)

В случае с SELECT мы могли бы воспользоваться предыдущим приёмом и посмотреть вывод EXPLAIN EXTENDED. Но MySQL не поддерживает EXPLAIN DELETE/UPDATE/INSERT. Эта возможность планируется, но в данный момент ещё не реализована. Что же предпринять в этом случае?

Лучший способ проверить запросы delete/insert/update - это конвертировать их в соответствующие select запросы:


mysql> select * from t1, t2;

Empty set (0.00 sec)

Мы получили тот же запрос, что рассматривали в предыдущей главе. Соотетственно вывод аналогичный: в данном случае выражение t1, t2 обозначает t1 INNER JOIN t2. А так как в таблице t2 нет данных, то и нет поля, по которому они могли бы объединиться. Соответственно не было ничего удалено.

Аналогичным способом можно работать и с проблемными update запросами.

Приём 6: преобразуйте DML запросы в соответствующий SELECT чтобы выяснить какие строки будут изменены.

Глава 3. В базе неверные данные или что делать с проблемным DML запросом.