sql怎样使用substring截取字符串部分内容 sqlsubstring截取字符串的教程

日期：2025-08-20 00:00 / 作者：蓮花仙者

SUBSTRING函数用于截取字符串，需指定源字符串、起始位置（从1开始）和长度；可结合CHARINDEX等函数动态截取，常用于数据清洗、脱敏及解析结构化数据，但需注意起始位置错误、NULL处理及性能问题，尤其避免在WHERE子句中导致索引失效。

在SQL里，要从一个字符串里截取你想要的那部分内容，

SUBSTRING

函数就是你的得力工具。说白了，它就是让你指定从哪里开始，截取多长。

解决方案

SUBSTRING

函数的基本用法其实挺直观的，它通常需要三个参数：原始字符串、起始位置和要截取的长度。

语法结构：

SUBSTRING(源字符串, 起始位置, 截取长度)

源字符串 (source_string): 你想从中截取内容的那个字符串。
起始位置 (start_position): 这是一个整数，表示你开始截取的位置。大部分SQL数据库（比如SQL Server, MySQL, Oracle）都是从1开始计数的，也就是说，字符串的第一个字符是位置1，第二个是位置2，以此类推。
截取长度 (length): 这也是一个整数，表示你希望从起始位置开始截取多少个字符。如果你指定的长度超出了字符串的实际剩余长度，通常数据库会截取到字符串的末尾。

实际例子来感受一下：

从字符串开头截取： 假如你有一个产品编号

'PROD-2025-001'

，你想取出前面的

'PROD'

。

SELECT SUBSTRING('PROD-2025-001', 1, 4);
-- 结果会是 'PROD'

从字符串中间截取： 还是那个产品编号，如果你想拿到年份
```
'2025'
```
。
```
SELECT SUBSTRING('PROD-2025-001', 6, 4);
-- 结果会是 '2025'
```
这里6是因为
```
P-R-O-D--
```
是5个字符，年份从第6个字符开始。
截取到字符串末尾： 如果你想截取产品编号的最后一部分
```
'001'
```
，但你可能不确定总长度。
```
SELECT SUBSTRING('PROD-2025-001', 11, 100); -- 100是个足够大的数字
-- 结果会是 '001'
```
这里，即使你给的截取长度
```
100
```
远超实际所需，它也会自动截取到字符串的末尾。
结合其他函数动态截取： 有时候你并不知道要截取的部分具体在哪里，比如从一个URL中提取域名。这时候，
```
SUBSTRING
```
常常会和
```
CHARINDEX
```
(SQL Server) 或
```
INSTR
```
(Oracle) /
```
LOCATE
```
(MySQL) 这样的函数一起使用，来动态确定起始位置。假设你想从邮箱地址
```
'user@example.com'
```
中提取域名
```
'example.com'
```
。
```
-- SQL Server 示例
DECLARE @email VARCHAR(100) = 'user@example.com';
SELECT SUBSTRING(@email, CHARINDEX('@', @email) + 1, LEN(@email) - CHARINDEX('@', @email));
-- 结果会是 'example.com'
```
这里
```
CHARINDEX('@', @email)
```
找到
```
@
```
符号的位置，加1就是域名的起始位置。
```
LEN(@email) - CHARINDEX('@', @email)
```
则计算出从
```
@
```
之后到字符串末尾的长度。

SUBSTRING函数在不同数据库系统中有何异同？

在我看来，虽然核心功能都是字符串截取，但

SUBSTRING

这个函数在不同的数据库系统里，它的具体名称或者语法细节确实有些微妙的差异。这有时候会让人觉得有点头疼，尤其是在跨数据库平台工作的时候。

SQL Server 和 MySQL： 这两个是比较一致的，都用
```
SUBSTRING(string, start, length)
```
。MySQL还有一个别名
```
SUBSTR
```
，功能完全一样。它们的起始位置都是从1开始计数。
PostgreSQL： PostgreSQL也支持
```
SUBSTRING(string, start, length)
```
这种形式，而且同样支持
```
SUBSTR
```
作为别名。不过，它还有一个更符合SQL标准、我个人觉得可读性也挺好的语法：
```
SUBSTRING(string FROM start FOR length)
```
。这种写法在语义上更清晰，
```
FROM
```
和
```
FOR
```
把参数的意义明确地表达出来了。起始位置也是从1开始。
Oracle： Oracle通常使用
```
SUBSTR(string, start, length)
```
。它的起始位置同样是从1开始。值得一提的是，Oracle的
```
SUBSTR
```
还支持负数作为起始位置，表示从字符串末尾开始倒数。比如
```
SUBSTR('abcdef', -2, 1)
```
会返回
```
'e'
```
。这是一个挺方便的特性，但在其他数据库里可能需要变通实现。

所以你看，虽然大家都在做截取这件事，但具体“怎么说”或者“怎么做”还是有点小区别的。当你从一个数据库切换到另一个时，稍微留意一下这些细节就能省去不少麻烦。

除了基本截取，SUBSTRING还能解决哪些实际问题？

SUBSTRING

这玩意儿，别看它只是个简单的截取函数，但结合其他逻辑，它能解决的实际问题可不少。它不仅仅是把长字符串变短，更多时候是用来“解析”或者“规整”数据。

数据清洗与格式化： 比如，你有一批电话号码，有的带区号，有的不带，或者格式不统一（如
```
'138-1234-5678'
```
、
```
'(010)87654321'
```
）。你可以用
```
SUBSTRING
```
配合
```
REPLACE
```
、
```
CHARINDEX
```
等函数，把它们统一成你想要的格式，比如只取手机号后8位。
```
-- 假设我们想统一提取手机号的后8位，且知道它们都在特定位置
SELECT SUBSTRING('13812345678', 4, 8); -- 提取'12345678'
```
当然，实际情况会复杂得多，可能需要更多判断。
提取结构化数据中的特定字段： 很多时候，我们的数据是编码过的，比如一个订单号
```
'ORD-20251026-A001'
```
，你可能需要单独提取出日期
```
'20251026'
```
或者序列号
```
'A001'
```
。
```
SUBSTRING
```
在这里就显得非常有用。
```
-- 提取订单日期
SELECT SUBSTRING('ORD-20251026-A001', 5, 8);
-- 提取序列号
SELECT SUBSTRING('ORD-20251026-A001', 14, 4);
```
敏感信息脱敏： 在展示用户数据时，出于隐私保护，我们经常需要对手机号、身份证号、邮箱等敏感信息进行部分隐藏。
```
SUBSTRING
```
结合字符串拼接就能轻松实现。比如，把手机号
```
13812345678
```
显示为
```
138****5678
```
。
```
SELECT SUBSTRING('13812345678', 1, 3) + '****' + SUBSTRING('13812345678', 8, 4);
-- 结果：'138****5678'
```
日志分析与URL参数解析： 从日志中提取特定的错误代码，或者从URL的查询字符串中解析出某个参数的值，
```
SUBSTRING
```
都是不可或缺的工具。配合
```
CHARINDEX
```
（或等效函数）来定位关键分隔符，然后截取中间的内容。

可以说，只要你的数据里有规律可循的字符串结构，

SUBSTRING

就有用武之地。它就像一把手术刀，帮你把数据精准地“切”开，取出你真正需要的部分。

使用SUBSTRING时常见的陷阱与性能考量是什么？

在使用

SUBSTRING

的时候，我个人觉得有几个地方是比较容易踩坑的，而且性能问题也值得我们好好琢磨琢磨。

常见的陷阱：

起始位置的“差一位”错误 (Off-by-one errors)： 这是最常见的错误了。因为大多数数据库的
```
SUBSTRING
```
起始位置是从1开始计数的，而不是0。如果你习惯了编程语言里的0索引，很容易就把起始位置搞错。比如，想要字符串的第二个字符，你写了
```
SUBSTRING(str, 0, 1)
```
，那在SQL Server里是会报错的。或者，你想要截取N个字符，但起始位置没算对，结果就差了那么一点。
```
NULL
```
值的处理： 这是一个小细节，但很重要。如果你的源字符串是
```
NULL
```
，那么
```
SUBSTRING
```
的任何操作结果都会是
```
NULL
```
。这在数据清洗时尤其需要注意，避免因为
```
NULL
```
值导致意料之外的结果。你可以用
```
ISNULL
```
(SQL Server) 或
```
COALESCE
```
来提前处理。
长度参数的理解： 如果你给的
```
截取长度
```
参数过大，超出了字符串从
```
起始位置
```
到末尾的实际长度，大多数数据库并不会报错，而是会截取到字符串的末尾。这通常是符合预期的，但如果你想严格控制截取长度，就得确保你的长度计算是准确的。如果
```
截取长度
```
是0，结果就是空字符串。
字符集和字节长度： 这是一个比较深的问题，尤其是在处理多字节字符（如UTF-8编码的中文）时。在某些数据库（比如SQL Server），
```
LEN()
```
函数计算的是字符数，而
```
DATALENGTH()
```
计算的是字节数。
```
SUBSTRING
```
通常是按字符数来截取的。但如果你在处理旧系统或特定编码时，需要特别注意一个“字符”到底占用多少个“字节”，这可能会影响你的
```
截取长度
```
计算。大多数现代系统默认都处理得很好，但了解这个背景还是有必要的。

性能考量：

索引失效： 这是最关键的一点。如果你在
```
WHERE
```
子句中对一个列使用了
```
SUBSTRING
```
函数进行条件过滤，比如
```
WHERE SUBSTRING(ColumnA, 1, 5) = 'ABCDE'
```
，那么这个查询很可能无法利用
```
ColumnA
```
上的任何索引。数据库需要对表中的每一行都执行
```
SUBSTRING
```
操作，然后才能进行比较，这会导致全表扫描，对于大数据量来说性能会非常糟糕。
- 应对策略： 如果你经常需要基于字符串的前缀进行查询，可以考虑创建一个“计算列”来存储这个前缀，并在这个计算列上建立索引。或者，在查询时尽可能地将
```
SUBSTRING
```
  操作放在等号的右边，让数据库有机会使用索引（如果条件允许）。
计算开销： 尽管
```
SUBSTRING
```
本身是个高效的函数，但在非常大的数据集上，对每一行都执行字符串操作仍然会产生不小的CPU开销。如果你的查询返回了数百万行数据，并且每行都需要进行复杂的
```
SUBSTRING
```
计算，那么整个查询的响应时间会明显增加。
替代方案的考量： 对于一些特定的截取需求，可能有更优化的函数。比如，如果你只是想截取字符串的开头部分，
```
LEFT()
```
函数通常比
```
SUBSTRING(string, 1, length)
```
更直观，在某些数据库内部实现上可能也更高效。同理，
```
RIGHT()
```
用于截取末尾部分。

总的来说，

SUBSTRING

是一个非常实用的函数，但用的时候还是得留个心眼。理解它的工作原理和潜在的性能影响，能帮助我们写出更健壮、更高效的SQL查询。