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

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

以上是MySQL 中真正的字母数字/自然排序 - 为什么答案总是递归？的详细内容。更多信息请关注PHP中文网其他相关文章！