在SQL中截取指定长度的字符串，通常涉及SUBSTRING和LEFT两个常用函数。虽然它们看起来都能完成“从左边取一部分字符”的任务，但参数设计和底层实现在不同数据库中并不完全相同。理解这些差异，可以避免在数据清洗、报表格式化和接口字段截取时出现少截一位、多截一位甚至乱码的问题。本文将以常见数据库为例，分别说明两种函数的用法、差异和适用场景。
一、SUBSTRING与LEFT的基础语法
SUBSTRING函数的核心是从字符串的某一个位置开始，截取指定数量的字符。标准SQL中，它的常见形式是SUBSTRING(字符串 FROM 起始位置 FOR 长度)，但大多数数据库也支持更简洁的逗号形式SUBSTRING(字符串, 起始位置, 长度)。以MySQL为例，SUBSTRING('Hello World', 1, 5)返回Hello。这里起始位置从1开始计数，而不是编程语言中常见的0。
LEFT函数则更加直接，它固定从字符串最左侧开始截取。LEFT(字符串, 长度)中的长度表示要保留的字符数量。例如LEFT('Hello World', 5)同样返回Hello。如果只需要截取前缀、手机号前三位、地区码等固定开头信息，LEFT的语法通常比SUBSTRING更直观。
两者的第一个重要区别在于灵活性。SUBSTRING可以指定任意起始位置，因此既能模拟LEFT，也能模拟RIGHT，例如SUBSTRING('abcdef', 2, 3)返回bcd。LEFT则只能从索引1开始。所以在只需要左侧截取时，LEFT语义更清晰；在需要动态起始位置或从中间提取时，SUBSTRING是必选项。另一个细节是长度参数超过字符串实际剩余长度时，多数数据库会返回从起始位置到字符串末尾的全部字符，而不会报错，这一点在编写通用SQL时可以放心利用。
二、不同数据库中的表现差异
虽然SUBSTRING和LEFT都属于字符串处理基础函数，但在MySQL、SQL Server、PostgreSQL和Oracle中，参数规则存在容易踩坑的差异。MySQL的SUBSTRING和SUBSTR函数完全等价，起始位置从1开始，长度参数可以省略，省略时返回从起始位置到末尾的所有字符。例如SELECT SUBSTRING('MySQL函数', 3);返回“SQL函数”。SQL Server的SUBSTRING也是从1开始，但长度参数必须提供，不能省略；它不支持标准SQL的FROM FOR语法。
PostgreSQL的SUBSTRING特别灵活，既支持逗号形式也支持标准SQL的FROM FOR形式，起始位置同样从1开始。例如SUBSTRING('PostgreSQL' FROM 3 FOR 4)返回“stgr”。值得注意的是，PostgreSQL中LEFT函数不是标准SQL，但作为扩展提供，使用起来没有区别。Oracle则只提供SUBSTR作为主要截取函数，从1开始计数，长度可以省略；Oracle没有内建LEFT函数，开发者通常使用SUBSTR(字符串, 1, 长度)来模拟LEFT。
不同数据库对0和负数起始位置的处理也不一样。MySQL允许起始位置为0，结果等同于从1开始；起始位置为负数时，会从末尾反向定位。SQL Server对起始位置小于1的情况有特殊计算方式，容易产生与直觉不符的结果。Oracle的SUBSTR遇到负数起始位置也会从末尾倒数。因此在编写跨数据库SQL时，不建议依赖这些边界行为，最好显式使用正整数起始位置。
三、中文字符与多字节字符的截取
在涉及中文、日文、韩文等多字节字符时，SUBSTRING和LEFT的截取单位会直接影响结果。现代数据库如MySQL在UTF-8字符集下，默认按“字符”而不是“字节”截取。例如LEFT('你好世界', 2)返回“你好”，不会把某个汉字截成乱码。但这有一个前提：列或表达式的字符集必须是合适的，且连接层没有错误转换。
如果使用MySQL的旧字符集如UTF8MB3，或原生UTF-8实际上每个汉字占3个字节，某些依赖字节处理的旧函数如SUBSTRING仍按字符处理，但早期的MID或某些数据库驱动可能按字节计算。真正需要按字节截取时，MySQL提供SUBSTRING按字符，SUBSTRING_INDEX按字符；Oracle中SUBSTR按字符，SUBSTRB按字节。PostgreSQL中left和substring默认按字符，但如果使用substring的from for语法并转换到bytea类型，可以按字节截取。
假设一个业务需要从身份证号中提取出生日期，由于身份证号为ASCII字符，使用SUBSTRING(id_card, 7, 8)即可稳定得到结果。如果处理的是用户昵称、地址等包含中文的字段，更推荐使用按字符截取的函数，并在数据库层确保字符集统一为UTF8MB4，避免出现半个汉字被拆开后显示为问号的情况。判断是否按字节截取时，可以通过LENGTH和CHAR_LENGTH对比验证。
四、常见错误与性能优化策略
使用SUBSTRING和LEFT时，一个典型错误是把编程语言的0起始索引习惯代入SQL。很多开发者会写出SUBSTRING(username, 0, 3)，在MySQL中还能返回前两位，在SQL Server中则可能返回空字符串或与预期不一致。为了保证结果一致，应统一使用从1开始的位置，或者先查询目标数据库文档确认边界行为。另一个错误是忘记处理NULL值。SQL中任何字符串函数遇到NULL参数，返回值通常也是NULL，不会抛出异常，但后续业务代码可能因为这个NULL导致判断逻辑失效。
-- 从用户昵称中截取前10个字符，若昵称为空则返回默认值 SELECT COALESCE(LEFT(nickname, 10), '匿名用户') AS short_name FROM users;
上述SQL使用COALESCE处理NULL，避免截取结果为空时影响前端展示。对于长文本截取，如果只需要判断前缀是否匹配某个固定串，不必先截取再比较，应使用LIKE 'prefix%'或全文索引，减少函数计算和索引失效的可能。当WHERE条件写成LEFT(column, 3) = 'abc'时，大多数数据库无法使用普通索引，会退化为全表扫描。若该查询频繁，可增加计算列并建立函数索引，或者调整查询方式。
在大量数据清洗任务中，尽量避免在JOIN连接条件或WHERE子句中使用SUBSTRING包裹索引列。例如SUBSTRING(order_no, 1, 4) = '2025'会阻止数据库利用order_no上的索引。更好的做法是增加一个冗余字段保存年份前缀，或者改写为范围查询。对于必须进行的截取，也应限制在结果集中的少量行，先在子查询中过滤后再截取，减少不必要的CPU开销。
总结来看，LEFT适合固定从左侧截取，语法简单、语义固定；SUBSTRING适合任意起始位置，灵活性强但需要注意数据库方言差异。选择哪一个，取决于业务需求是简单前缀截取还是复杂的位置提取。在跨数据库项目中，建议封装统一的字符串截取函数或使用ORM工具提供的抽象方法，避免直接依赖某一种数据库的边界行为。
SQL截取字符串SUBSTRING函数LEFT函数修改时间：2026-08-26 19:37:28