MySQL 中真正的字母数字/自然排序 - 为什么答案总是递归？
昨天我尝试解决 mysql 中的字母数字排序问题，但失败了。 （在这里阅读那篇文章）
我确实接近了，并且有正确的概念，只是错误的执行。
今天，我醒来并顿悟...递归。
递归的问题在于你必须了解递归才能进行递归...而我对递归的理解不足以在 mysql 中进行递归。
但是，通过 chat gippity 来回进行一些操作（我的意思是让它写出我要求的内容，返回我要求的大约 25%，修复它并将其输入到新的聊天中，这样就不会出现问题）不要一直重复大约 2 小时）我得到了有效的答案！
说到重点
愿我向您呈现我的绝唱、我的杰作、生活本身的答案（好吧，这是我见过的 mysql 中真正字母数字排序的唯一有效解决方案）。
with recursive process_numbers as (
select
data_value,
data_value as remaining_data,
cast('' as char(20000)) as processed_data,
1 as iteration
from test_data
union all
select
data_value,
case
when locate(regexp_substr(remaining_data, '[0-9]+'), remaining_data) > 0 then
substring(
remaining_data,
locate(regexp_substr(remaining_data, '[0-9]+'), remaining_data)
+ length(regexp_substr(remaining_data, '[0-9]+'))
)
else ''
end as remaining_data,
concat(
processed_data,
case
when locate(regexp_substr(remaining_data, '[0-9]+'), remaining_data) > 0 then
left(remaining_data, locate(regexp_substr(remaining_data, '[0-9]+'), remaining_data) - 1)
else remaining_data
end,
case
when regexp_substr(remaining_data, '[0-9]+') is not null then
right(concat('0000000000', regexp_substr(remaining_data, '[0-9]+')), 10)
else ''
end
) as processed_data,
iteration + 1
from process_numbers
where length(remaining_data) > 0
and iteration < 100
)
select
data_value,
concat(processed_data, remaining_data) as sort_key
from process_numbers
where remaining_data = ""
order by sort_key;
如果你想尝试一下（并尝试打破它），你可以使用这个数据库小提琴
那么这是如何运作的呢？
它完成了我最初想做的事情，取出每组数字并将它们填充到总共 10 位数字。
很明显，如果你给它提供几个包含 11 个连续数字的字符串，如果不进行调整，它就无法工作，但除此之外它工作得很好！
你看，mysql 可以正确地对数字进行排序，即使在字典排序模式下也是如此，但它有一个缺陷。
它将“11”视为小于“2”，因为它一次对一个字符进行排序（有效）。所以“2”比“1”大，所以它排在第一位。然后它检查下一个字符，此时排序不正确（至少对于数字而言）。
为了更好地理解这一点，想象一下 1 实际上是字母“b”，2 是字母“c”。
这就是mysql“看到”数字的方式，它们只是另一个字符。
因此，如果我有“bb”和“c”，您会期望“bb”出现在“c”之前。现在将数字交换回去，您就会明白为什么“11”位于“2”之前。
那么这是一个黑客行为吗？
是的，我们通过填充将数字“向后”移动来解决这个问题。
回到我们的示例，如果我们将“11”和“2”的长度填充为 3 并将“a”用作 0，则会发生以下情况：
011 = abb 002 = aac
注意现在排序的方式：
- 字符 1：“a”比“a”大 - 不，它们是相同的。
- 字符 2：“b”比“a”大 - 是的，将“a”放在“b”之前
- 字符 3：现在无关紧要，我们已经发现了更早发生的不同且更大的事件。
按照这个逻辑我们现在有：
002 = aac (the second "a" comes before the second "b" in the next row) 011 = abb
这就是它的工作原理！
你要解释一下递归的事情吗？
有点。我已经用这个“绕了房子一圈”，我的知识只是表面水平，但我会尝试一下。
问题在于 regex 在 mysql 中的工作方式。 regex_substr 只会找到一个匹配项，然后为找到的所有其他匹配项继续返回该匹配项。这就是为什么我昨天的解决方案无法正常工作的原因。
但是 regex_replace 有它自己的问题，它似乎没有正确公开匹配的字符串长度（因此我们无法正确地对其进行 lpad）
这就是为什么我认为递归作为答案。
我可以使用 regex_substr 来获得正确的填充行为，并且由于 regex 的每个循环本质上都是一个新函数调用，因此它不会“记住”上一个匹配项，因此它解决了这个问题。
如果你想简单了解一下逻辑，它实际上并不像看起来那么可怕！
- 我们循环给定的字符串，查找任何数字（整个数字，而不仅仅是单个字符）。
- 然后我们将其从剩余数据中删除，这样我们就不会再次匹配它。
- 我们取出刚刚匹配的数字并将其填充为总共 10 位数字。
- 然后我们搜索字符串中的下一个数字部分并重复该过程，将processed_data构建为最终字符串。
- 最后，一旦我们没有更多的数字需要处理，我们将剩余的字母添加到processed_data的末尾以完成转换，并将其作为sort_key返回。
然后我们可以在查询中使用这个 sort_key 来正确排序列。
迭代部分纯粹是一个保护工具，以确保它不会完全运行 mysql 服务器内存不足或在处理足够复杂的字符串时使查询崩溃（或者逻辑中存在错误，这意味着它会永远递归）。
这就是一个包裹！
睡在东西上会带来新的视角，这不是很有趣吗？
也许我应该尝试多相睡眠，这样我每天就可以多睡觉 2-3 次来解决问题，从而成为 10 倍的开发者？哈哈。
无论如何，你已经拥有了它，一个相当强大的true字母数字排序。
哦，实际上，您可能应该使用 generate 或存储过程将 sort_key 转换为数据库上的存储列。遗憾的是，我使用的游乐场似乎不支持这一点，而且今天是周日，所以我将把它留给你，亲爱的观众！
祝您周末休息愉快，度过愉快的一周。