先说结论，where 1=1不会影响性能，如有错误，请指点一下

trim标记是一个格式化的标记，可以完成set或者是where标记的功能。

2020.1.17，周五，距离春节假期返家仅剩两天，在公司抽空做了下代码代码优化，发现有段mapper代码如下：

    <select id="getList" resultMap="BaseResultMap" parameterType="payment.common.Criteria">
        select a.* from app a where 1=1
        <if test="_parameter != null">
            <include refid="getappListSQL"/>
        </if>
    </select>

其引入的getAPPListSQL如下：

    <!-- app条件 -->
    <sql id="getappListSQL">
        <trim >
            <if test="condition.appId != null">
                and a.id = #{condition.appId}
            </if>
            <if test="condition.appName != null">
                and a.appName like '%${condition.appName}%'
            </if>
        </trim>
        order by a.id desc
        <include refid="*****.Mysql_Pagination_Limit"/>
    </sql>

这个方法从逻辑上看起来好像并没有什么问题，但是看到这段代码时我的心情是沉重的，因为我觉得我的前人还给我留了很多坑。在我之前的认知中，这样会导致sql优化时放弃索引，因此产生了巨大的性能影响，所以打算写这篇文章吐槽一下前人。于是我贴了我修改之后的代码来与原代码进行对比，然后又觉得这样不够有说服力，打算用explain对sql执行效率进行分析，然后贴图上来，事情到现在仍很顺利，BUT：

查完之后我人就傻了。。。

所以说，纸上得来终觉浅，绝知此事要躬行！！！

然后我又去网上查了很多资料，有很多人都发现了这个问题，但是都没有给出一个合理的解释，这又勾起了我的好奇心！我想到MYSQL是有一定的优化机制的，如果我是设计者，我一定会将这些类似“1=1”的条件给优化掉，而不是让他来影响我sql的性能，那就来看一下优化后的sql

果然是我想象的那个样子，优化过后的代码根本没有“1=1”这个条件，更不用谈它还能够影响我们的性能了！！！

最起码不是

我们回头再考虑一下为什么大家都在说“1=1”会影响MySQL的性能，可能在很久之前的sql版本中，“1=1”确实会影响到sql语句的索引优化过程，这是一个很严重的问题，所以大家都记得这个事，在后来sql将这个问题给优化掉了，但是很多新人听老人仍在讲这个问题，所以就一直记得，新人变成老人后又给其他新人去说这个问题，慢慢的大家都记得这个问题，但已经没有人去验证他的真假了。

我觉得这就是csdn用户甚至中国当前IT行业从业人员所面临的问题。

先看有没有，再说为什么！！！