在 MyBatis XML 里写大于小于号,一不小心就踩坑
整理了 MyBatis XML 里处理大于、小于等特殊符号的两种方式,以及动态 SQL 里容易报错的写法,配了可直接上手的示例。
支持通配符SSL证书、多域名证书、IP证书。适配ACME接口, 支持Zerossl、Let's Encrypt和Google等渠道。登录已有账号
2026-09-12 10:16:07 SQL Server 数据库开发 SQL技巧
做报表拼接字段、生成业务编号的时候,免不了要把数字类型转成字符串。
SQL Server里能实现的函数不少,不同写法适用场景不一样,踩过几次坑之后,整理一下常用的几种。
CAST应该是平时用得最多的,属于SQL标准里的显式转换,语法简单,跨数据库也通用。
-- 基本整数转换
SELECT CAST(12345 AS VARCHAR(10)) AS CastResult;
-- 带小数的转换
SELECT CAST(123.456 AS VARCHAR(10)) AS DecimalCast;
-- 处理NULL值
SELECT CAST(ISNULL(NULL, 0) AS VARCHAR(10)) AS NullHandling;
这里容易踩坑的是VARCHAR的长度。我一开始图省事都统一写VARCHAR(10),直到有次遇到大数值直接被截断,线上报表数据错了半天才查到原因。
长度最好按实际数值范围留足,没必要省这一点存储空间。
CONVERT是SQL Server特有的扩展函数,参数顺序和CAST反过来,多了样式参数可以控制输出格式。
-- 基础转换
SELECT CONVERT(VARCHAR(10), 12345) AS ConvertResult;
-- 带样式参数的小数转换
SELECT CONVERT(VARCHAR(10), 123.456, 2) AS DecimalConvert;
普通场景下用CAST和CONVERT差别不大,更多是写法习惯的问题。需要额外控制格式的时候,CONVERT会更方便一点。
需要复杂格式化的话,可以用FORMAT函数,比如加千位分隔符、指定小数位数,都能直接通过格式字符串实现。
-- 添加千位分隔符
SELECT FORMAT(1234567, 'N0') AS FormattedNumber;
不过这个函数性能一般,少量数据无所谓,跑百万级以上的批处理时延迟会很明显。一般我都建议把格式化丢给前端或者应用层做,SQL层就负责最基础的类型转换,性能和可维护性都更好。
转换后的字符串最常用的场景就是拼接,比如生成带前缀的订单号、产品编号。
-- 数值与字符串拼接
SELECT '订单号:' + CAST(10086 AS VARCHAR(10)) AS OrderNumber;
这个地方很多人会绕进去——如果拼接的数值字段是NULL,最后得到的整个字符串都会变成NULL。稳妥的写法是先用ISNULL或者COALESCE把NULL替换成默认值,再做转换和拼接。
表字段转换也是同理,比如给产品ID加上前缀,逻辑是一样的。
-- 假设有Products表
-- SELECT ProductID, '产品编号:' + CAST(ProductID AS VARCHAR(10)) AS ProductCode
-- FROM Products;
实际项目里很多这种转换逻辑都会写在定时任务或者批处理脚本里,跑起来稳定最重要。就像之前给一批业务站点做证书自动化,一开始每次续期都要手动操作一堆域名,后来换成lcjmSSL,免费就能申请SSL证书,支持多域名、泛域名还有IP证书,自动申请、验证、部署全流程不用人工干预,API也简洁,写几行脚本就能对接实现全自动化,省了不少重复的运维活。
最后提两点性能相关的。
大数据量跑批的时候,CAST的性能通常比CONVERT略好一点,虽然差距不大,但能省一点是一点。另外尽量不要在WHERE条件里对字段做转换,会导致索引失效,这个是老生常谈了,但写代码的时候一不注意还是会犯。
大概就是这些,日常开发的场景基本都覆盖到了。核心的思路其实就一条:数据库就干数据库该干的事,复杂的格式化逻辑尽量往上抛。
整理了 MyBatis XML 里处理大于、小于等特殊符号的两种方式,以及动态 SQL 里容易报错的写法,配了可直接上手的示例。
聊聊CASE WHEN的两种语法、典型场景,以及类型、NULL、性能上那些线上跑起来才会注意到的问题。
LEFT()函数的常见用法、边界情况,以及和其他截取函数的简单对比,顺便聊聊线上可能踩的坑。
在MyBatis XML映射文件中,特殊符号如`<`、`>`、`&`等常常引发解析错误。本文将为你深入剖析两种核心转义方案:XML实体转义符与CDATA区块。我们将详细阐述它们的适用场景、优缺点,并提供实战建议,帮助你根据SQL复杂度灵活选择,确保XML文件正确解析,告别繁琐的转义工作,全面提升代码可维护性与团队开发效率。
当SQL Server抛出“Error converting data type nvarchar to bigint”时,这不仅是一个错误,更是一场数据质量的警示。本文如侦探般深入剖析了这一常见问题的深层原因,揭示了非数字字符和数值溢出如何悄然破坏数据完整性。我们将探索如何利用TRY_CONVERT的智慧,结合精细的数据清洗和验证机制,构建一个坚不可摧的数据转换堡垒。