MySQL 中真正的字母数字/自然排序 - 为什么答案总是递归？

本篇文章给大家分享《MySQL 中真正的字母数字/自然排序 - 为什么答案总是递归？》，覆盖了数据库的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

昨天我尝试解决 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 转换为数据库上的存储列。遗憾的是，我使用的游乐场似乎不支持这一点，而且今天是周日，所以我将把它留给你，亲爱的观众！

祝您周末休息愉快，度过愉快的一周。

本篇关于《MySQL 中真正的字母数字/自然排序 - 为什么答案总是递归？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！