之前，这个 SQL 运行好好的，只会查询 default 数据库的列信息。
但昨天他们升级了某些用户权限，就导致这个 SQL 会同时返回 default 数据库和底层 r0 数据库的解信息，而他们在调整权限时，完全没有任何一个人想到了要去相应的修改这个 SQL。
于是，查询结果翻倍了，导致结果文件大小翻倍，原本只有大约60个的文件，变成了大约120个特征。
这里就要说到一个关键设计了。Cloudflare的反爬虫模块为了性能优化，预先分配了固定大小的内存，并且硬编码了一个上限：最多支持200个特征。
这个限制本来设得挺宽松的，毕竟实际只用60个，留了3倍多的余量。
但是，当特征文件因为重复数据导致超过200个特征限制时，问题就来了。Rust代码里有个检查，如果特征数超限就会panic(崩溃)，直接返回500错误。
更糟糕的是，这个特征文件每5分钟自动生成一次，并且会快速推送到全球所有服务器。由于权限调整是逐步推送到各个数据库节点的，所以每5分钟，根据查询落在哪个节点上，可能生成好文件，也可能生成坏文件。
这就导致了一个非常诡异的现象：系统时好时坏，一会儿恢复正常，一会儿又全面崩溃。这种症状让工程师们一度怀疑是不是遭到了DDoS攻击。
巧合的是，Cloudflare的状态页面(托管在第三方，完全独立于Cloudflare基础设施)恰好在这个时候也挂了，更加深了"遭受攻击"的怀疑。
于是就让他们在定位问题时想错了方向，浪费了一些时间。
直到权限调整逐步推送到所有节点，每个节点都开始生成坏文件，系统进入了稳定的故障状态，工程师们才最终定位到真正的问题，从而修复了故障。
本次故障，从北京期间11月18日19:28左右开始，到22:30初步恢复，再到19日01:06彻底恢复，总共经历了差不多5.5个小时，是 Cloudflare 自2019年以来的最大故障。
