MysqlWallTest23同一个条件不同的测试结果，为何？？？

成这种情况的原因可能是因为数据库表中存在数据并发修改的情况，导致查询结果不一致。

在多个线程并发访问同一个数据时，可能会发生以下情况：

脏读（dirty read）：一个事务读取到了另一个事务还未提交的数据，导致读取的数据不一致。

不可重复读（non-repeatable read）：一个事务在读取同一条数据时，多次读取得到的结果不一致。

幻读（phantom read）：一个事务在读取某一范围的数据时，多次读取得到的结果不一致。

这些问题可能会导致MysqlWallTest23测试用例中同一个条件不同的测试结果。为了避免这种情况，可以采用以下方法：

使用数据库的事务机制：在多个线程并发访问同一个数据时，可以使用数据库的事务机制来保证数据的一致性。可以将多个查询操作封装在同一个事务中，避免多个事务并发修改数据导致的问题。

使用数据库锁机制：可以使用数据库的锁机制来避免多个线程并发访问同一个数据时的问题。例如，可以使用行级锁或表级锁来保证数据的一致性。

使用乐观锁或悲观锁机制：乐观锁和悲观锁是一种常用的并发控制机制，可以用来避免多个线程并发修改同一个数据导致的问题。

永真条件（1=1）前置注入风险小，后置的风险很大

原回答者GitHub用户wenshao

您的两个测试方法test_true()和test_false()中，使用了WallUtils.isValidateMySql()方法来判断是否为有效的MySQL语句。两个测试方法的查询语句看起来只是将条件的顺序进行了调换，但结果却不同。

这是因为您使用了阿里巴巴的druid-wall插件来进行SQL语句的安全性检查。druid-wall插件会对SQL语句进行语法解析和语义分析，并进行一系列的安全性检查。其中，安全性检查的结果可能会受到SQL语句中条件的顺序影响。

在您的测试方法中，test_true()方法的查询语句是"select count(*) total from utao_goods where 1=1 and pprice between 0 and 99999 and state=1"，而test_false()方法的查询语句是"select count(*) total from utao_goods where pprice between 0 and 99999 and state=1 and 1=1"。

根据druid-wall的实现逻辑，它会对SQL语句进行解析，并根据一些规则进行安全性检查。这些规则可能会关注SQL语句中的条件顺序，并可能对条件的位置进行一些限制。

因此，当您调换条件的顺序时，druid-wall可能会对查询语句的安全性检查结果产生影响。这就是为什么您的两个测试方法的结果不同的原因。