自然排序需将混合字符串中连续数字视为整体数值比较：postgresql用regexp_replace+lpad补零对齐，mysql 8.0+建议建stored生成列预处理，sqlite则依赖substr/cast或应用层实现。
直接用 ORDER BY 对 'item1'、'item10'、'item2' 排序，结果一定是 item1、item10、item2——这不是 bug，是字典序的正常表现。自然排序不是数据库默认行为，必须显式拆解数字块并转为数值比较。
PostgreSQL：用 regexp_replace() + lpad() 补零对齐
核心思路是把每个连续数字块（如 '1'、'10'）替换成等长字符串（如 '0000000001'、'0000000010'），再整体按字符串排序，从而模拟数值大小关系。
-
regexp_replace(name, '(\d+)', lpad('\1', 10, '0'), 'g')中'\1'是捕获组引用，'g'确保替换所有数字块 - 补零长度必须 ≥ 数据中最大数字的位数；若字段含
'12345678901'（11位），lpad(..., 10, ...)会截断成'2345678901'，导致错序 - 该表达式无法走索引，大数据量时建议配合函数索引：
CREATE INDEX idx_items_name_natural ON items (regexp_replace(name, '(\d+)', lpad('\1', 10, '0'), 'g'));
MySQL 8.0+：用存储生成列预处理，避免运行时计算开销
MySQL 的 REGEXP_REPLACE() 不支持在替换中嵌套函数调用（如 LPAD('$1', 10, '0') 可用，但 LPAD(CAST('$1' AS UNSIGNED), ...) 会报错），所以推荐固化逻辑到列里。
- 建生成列时必须用
STORED（不能用VIRTUAL），否则ORDER BY可能不走索引或报错 -
$1是 MySQL 的捕获组引用语法，不是\1；若原始值为空或无数字，LPAD('$1', 10, '0')会把空字符串变成'0000000000'，污染排序——应加保护：REGEXP_REPLACE(name, '([0-9]+)', IFNULL(LPAD('$1', 10, '0'), '$1')) - 生成列定义后，直接
ORDER BY name_natural即可，性能接近普通字段排序
SQLite：没有正则替换，靠 substr() + printf() 手动分段最稳
SQLite 原生不支持 REGEXP_REPLACE（除非编译时启用扩展），纯 SQL 下无法可靠提取任意位置的数字块。硬解容易漏 case，比如 'v1.2.10' 或 'abc2def3'。
- 简单场景（如前缀固定 + 单数字后缀）可用：
ORDER BY substr(name, 1, length(name)-length(ltrim(substr(name, -10), '0123456789'))), CAST(ltrim(substr(name, -10), 'abcdefghijklmnopqrstuvwxyz') AS INTEGER)，但可读性差、维护成本高 - 真正混合复杂格式（如
'R2D2'、'beta3.14.159'）建议在应用层做自然排序，SQL 层只负责取数 - 如果坚持用 SQLite 纯 SQL，递归 CTE 可实现通用解析，但 N=1000 时性能已明显下降，不推荐生产环境使用
自然排序真正的难点不在语法，而在于“数字块边界”的定义是否统一：是按连续阿拉伯数字切分，还是识别 Unicode 数字？是否忽略前导零？这些业务语义必须和前端、导入脚本对齐，否则同一串数据在不同环节排序结果不一致。
