最近，当讨论某些合作伙伴和不同时，他们提到他们被字符串替换。根据我个人的理解，它的主要作用是占据位置。当人参类型是整形手术时，最终的剪接SQL也应该是塑料，而不是弦线的方式
让我们看一下映射器接口中的不同参数类型。
我们使用springboot + mybatis + mysql构建实例演示
核心依赖项，至于版本选择，请转到MVN仓库，找到最新的
另一个不请求的是DB配置信息，
用于测试的数据库
测试数据，主要是字段，带有许多数字的字符串
本文忽略了Mybatis中PO，映射器接口和XML文件的详细信息。有兴趣的合作伙伴可以直接查看底部源代码（或检查上一个博客文章）
对于上述情况，定义一个基于名称查询数据的接口，但是此名称参数类型是整数
映射器接口：
相应的XML文件如下
上面的写作非常普遍。我们的问题是整数，那么最终的SQL是什么？
那么如何确定最终SQL是什么样的？这是一种直接输出MySQL以执行SQL日志的方法
在MySQL Server上执行以下两个命令，打开SQL执行日志
访问上面的接口后，我们会发现在最终发送到mySQL的SQL语句中，它仍然是参数替换后的整数
在使用中，有时除了参数外，我们还将指定JDBCTYPE。那么，我们是否会指定这将影响XML中的最终SQL生成？
生成的SQL如下
从实际的SQL来看，此JDBCTYPE不会影响最终的SQL参数缝线。那么它主要使用的是什么？（它主要适用于NULL中引入时可能发生的类型转换）
当我们将参数类型作为字符串传递时，最终的SQL推理应带来报价编号
相应的XML
以上的最终SQL如下
阅读了上述部分后，基本上有一个简单的推论（当然，您需要从源头进行分析）
所以问题是，你为什么知道这一点？
例如，在本文的示例中添加了索引。当我们的SQL无法转到索引时。如果要采用索引，则需要传递的参数必须是字符串。
基于此，我们有一个应用程序方案。为了避免参数类型的问题，不能将索引带走。我们希望参数的参数是参数的类型。
我们使用自定义类型Handler实现此场景
然后在XML中指定typehandler
上面的SQL输出将带有一个引号，以便可以从源求解参数类型的类型，这将导致索引的问题
本文使用一个简单的示例来测试映射器接口中的不同参数类型，即最终SQL生成的影响
当我们希望无论哪种类型的参数，最终的SQL都会被字符串替换，我们可以在定义的帮助下实现它。这可以避免来源。
最后一个问题是，上述结论是可靠的吗？Mybatis中的最终SQL缝线在哪里？此SQL剪接的过程是什么？
关于SQL剪接的整个过程，将要启动随后的博客文章。我是灰色。经过帮助的大兄弟喜欢它，收取价格并进行评估。
微信公共帐户：一个灰色博客