使用asyncIO优化MAC厂商映射查询速度未达预期如何解决

你写的asyncio版本提速差，本质是几个方向的认知错误：

• asyncio是单线程的IO并发模型，只适合有大量IO等待（比如网络请求、磁盘读写）的场景。你这个MAC匹配逻辑是纯CPU计算，没有任何IO等待环节，所有协程还是挤在同一个线程里串行执行，协程调度本身还会额外消耗一点性能，不可能有质的速度提升。
• 你从一开始就没解决核心性能瓶颈：双层循环的时间复杂度是O(CSV条数 * OUI前缀条数)，按常见OUI库3万条前缀算，15000条MAC要做4.5亿次字符串判断，这部分计算量不砍掉，换什么并发模型都没用。
• 额外的无效开销：你每次判断前缀前都给MAC地址转一次大写，等于把同一个字符串大小写转换操作重复做了几万次，纯浪费CPU。

最高优先级的优化是用O(1)哈希查找替换掉原来的O(n)遍历匹配，改完之后总耗时会从几十秒降到0.1秒以内，根本不需要用到异步或者多进程。

第一步：预处理OUI映射表 #

把原来的OUI数组转成分层字典，一次预处理完所有前缀：

1. 遍历所有VendorMapping条目，把前缀里的分隔符（冒号、横杠）全部去掉，统一转成大写，按前缀长度分组存到字典里，key是处理后的前缀，value是厂商名。
2. 把前缀长度按从长到短排序，匹配的时候优先查更长的前缀（OUI有36位、28位、24位三种长度，长前缀的匹配优先级更高，避免短前缀误命中）。

第二步：单条MAC匹配逻辑优化 #

处理每条MAC的时候：

1. 先把MAC里的所有分隔符（冒号、横杠、点）全部清除，统一转成大写，这个操作每条MAC只做1次。
2. 按之前排好序的前缀长度，依次截取MAC对应长度的前缀，直接在对应长度的前缀字典里做哈希查找，找到就直接返回厂商，全部没命中就标记为未知厂商。

核心实现代码参考：

import json
import csv

# 加载并预处理OUI映射
with open("oui.json", "r", encoding="utf-8") as f:
    oui_raw = json.load(f)

prefix_group = dict()
for item in oui_raw["VendorMapping"]:
    # 统一处理前缀格式：去分隔符、转大写
    clean_prefix = item["_mac_prefix"].replace(":", "").replace("-", "").upper()
    prefix_len = len(clean_prefix)
    if prefix_len not in prefix_group:
        prefix_group[prefix_len] = dict()
    prefix_group[prefix_len][clean_prefix] = item["_vendor_name"]
# 前缀长度降序排列，优先匹配更长的精确前缀
match_order = sorted(prefix_group.keys(), reverse=True)

# 处理CSV
match_result = []
with open("mac.csv", "r", encoding="utf-8") as f:
    csv_reader = csv.reader(f)
    next(csv_reader)  # 跳过表头
    for row in csv_reader:
        raw_mac = row[0].strip()
        # 统一处理MAC格式：去分隔符、转大写，仅执行1次
        clean_mac = raw_mac.replace(":", "").replace("-", "").replace(".", "").upper()
        vendor = "Unknown"
        for prefix_len in match_order:
            target_prefix = clean_mac[:prefix_len]
            if target_prefix in prefix_group[prefix_len]:
                vendor = prefix_group[prefix_len][target_prefix]
                break
        match_result.append((raw_mac, vendor))

可选额外优化 #

• 如果你用的OUI库全是标准24位前缀（即MAC前3段，对应6个十六进制字符），可以直接去掉长度分组逻辑，单字典存前6位前缀即可，速度还能再提升30%左右。
• 15000条MAC的量级非常小，单线程跑上述代码耗时不会超过100毫秒，完全没必要上多进程、异步这类复杂方案，徒增维护成本。
• 不要用startswith做遍历匹配，字典哈希查找的性能是循环遍历startswith的上千倍。

内容的提问来源于stack exchange，提问作者Vida Eninkio