SQL两列数据合并为一列显示的查询方法
先说说 MySQL,CONCAT() 函数直接用似乎最省事,但这里有个坑——NULL 值会直接污染整个结果。举个例子,CONCAT( 张 , NULL) 返回的不是 张 ,而是 NULL。所以稳妥的做法是:CONCAT(COALESCE(col1, ), COALESCE(col2, ))
先说说 MySQL,CONCAT() 函数直接用似乎最省事,但这里有个坑——NULL 值会直接污染整个结果。举个例子,CONCAT('张', NULL) 返回的不是 '张',而是 NULL。所以稳妥的做法是:CONCAT(COALESCE(col1, ''), COALESCE(col2, ''))。如果还想在中间加个空格作为分隔符,那就写成 CONCAT(COALESCE(col1, ''), ' ', COALESCE(col2, '')),这样才安全。
另外要提醒一句:在 MySQL 里别用 + 或 || 来拼接字符串。除非你特意开启了 PIPES_AS_CONCAT 模式,否则 col1 || col2 会被当成逻辑或运算,结果要么是 0 要么是 1,肯定不会是你想要的。

PostgreSQL 用 || 拼接,但 NULL 行为和 MySQL 相反
PostgreSQL 里 || 操作符对 NULL 的处理就要友好得多——'abc' || NULL 返回的是 'abc',只有两边都是 NULL 时才会返回 NULL。这点确实比 MySQL 省心。不过,如果你希望统一处理空字符串和 NULL 的情况,还是建议显式转一下:COALESCE(col1, '') || COALESCE(col2, '')。
但要注意的是,PostgreSQL 也有 CONCAT() 函数,而且它的行为跟 MySQL 一样——遇到 NULL 就返回 NULL。所以在这个数据库里,优先用 || 更符合直觉,也更不容易踩坑。
SQL Server 必须用 +,且要手动处理 NULL 和类型转换
再说 SQL Server,它只认 + 操作符来拼接字符串。但别高兴太早,这里有两个硬伤:一是任意一列为 NULL,结果就是 NULL;二是如果列是数字类型(比如 INT),它会直接报错,提示“无法将数据类型 int 隐式转换为 varchar”。
安全的写法是:ISNULL(CAST(col1 AS VARCHAR), '') + ISNULL(CAST(col2 AS VARCHAR), '')。如果其中一列是日期字段,还得先套一层 CONVERT(VARCHAR, col_date, 120) 指定格式,否则你可能会得到 'Jan 1 2024 12:00AM' 这种不可控的输出。
跨数据库可移植写法:用标准 SQL 的 CONCAT(),但得确认版本
话说回来,如果项目要求跨数据库兼容,标准 SQL 的 CONCAT() 函数理论上是最佳选择。SQL:2008 标准规定,CONCAT() 在遇到 NULL 时会直接忽略,即 CONCAT('a', NULL, 'b') 返回 'ab'。但实际支持情况如何?
- MySQL 5.7.9+ 支持,且行为符合标准
- PostgreSQL 9.6+ 支持,同样忽略 NULL
- SQL Server 2012+ 支持,也把 NULL 当空字符串处理
真正的麻烦在于旧版本或者 SQLite 这类轻量级数据库——SQLite 没有 CONCAT(),只能靠 ||,但它又把 NULL || 'x' 当成 NULL 处理。所以“一次写完到处跑”基本不现实,最后还得根据目标数据库来选函数。
最后还有一个容易被忽略的点:拼接后的字段默认没有别名。如果直接写 SELECT CONCAT(name, phone),在应用层拿到的列名可能是一长串 CONCAT(name, phone) 这种怪名字,务必加上 AS full_info 显式命名,不然代码维护起来会很头疼。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
SQL中HAVING子句性能有时优于WHERE子句的深度原因解析
先抛个结论,帮大家省点纠结的时间:HA VING 真的从来就不比 WHERE 性能更好。江湖上流传的“HA VING 更快”,大多是拿错了对比样本,或者是被缓存、数据量这些小细节晃了一下眼。问题的根源其实就一句话:混淆了“执行阶段”和“数据量”这两个完全不同的概念。把它们的先后顺序和各自能干的事儿理
SQL开窗函数计算分组内占比的详细教程
开窗函数这个话题,其实最核心的价值就在于它能让我们在保留全部明细数据的同时,完成复杂的聚合计算。比如,要算每个产品在其所在分类中的销售占比,这在报表分析里太常用了。如果用传统GROUP BY再加JOIN回去,SQL写得啰嗦不说,性能也糟糕。 计算分组内占比的核心逻辑 说白了就是:用当前行的值,除以它
移动端App接口Token未校验导致SQL注入的解决方案
先纠正一个常见误解:Token未校验本身并不会直接导致SQL注入——它只是一个身份凭证,不是SQL的输入源。真正的问题出在另外一条链路上:攻击者利用未校验的Token轻松绕过鉴权,然后塞进恶意参数(比如 user_id、keyword),这些参数再被拼接到SQL中执行,这才是灾难的开端。 所以修复的
Navicat还原后中文字符显示问号的解决方法
说实话,遇到Navicat还原后中文字符全部变成问号的情况,大多数用户的第一反应往往是备份文件损坏了。但真相其实很简单——问题不在文件本身,而是Navicat在还原过程中跳过了字符集协商环节,直接将utf8mb4的字节按照latin1或gbk编码“硬解”写入。换句话说,它根本没有询问数据库“你使用的
Redis集群从节点频繁掉线检查MTU与心跳包大小
揭示一个容易被忽视的问题:Redis集群中从节点频繁掉线,绝大多数情况并非配置错误,而是网络层默默出现丢包——尤其是MTU参数不匹配时,心跳包被迫分片甚至直接被截断。 先说核心判断:MTU不一致确实会导致Redis从节点掉线,这听起来有些反直觉,但却是真实的线上踩坑经验。心跳包(PING PONG)
- 热门数据榜
相关攻略
2026-07-11 07:02
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程

