2023年夏天，数据我审阅了一篇关于分布式数据库事务处理的库论投稿。作者用三个月的文字实验数据证明，在特定网络延迟下，数据传统两阶段提交协议的库论吞吐量会断崖式下跌。这让我想起十年前读博时，文字导师反复强调的数据那句话：“数据库论文的核心，是库论让读者相信你的系统真的能跑。”

论文开篇就该是文字血淋淋的测试结果。我见过太多稿件，数据前两页都在铺陈“随着数据规模爆炸式增长”的库论废话。直接甩出你的文字基准测试曲线，标注清楚硬件配置和参数调优细节。数据去年有篇关于LSM-tree compaction策略的库论论文，作者第一页就贴出不同负载下的文字写放大系数对比图，审稿人当场就来了兴趣——那些波动剧烈的折线，比任何文字描述都更有说服力。

方法部分最忌讳写成用户手册。有个常见误区：把每个模块的伪代码都塞进去，结果核心创新点被淹没在琐碎细节里。正确做法是突出你的关键设计决策。比如你改进了B+树的分裂算法，就该画清楚分裂前后的节点状态图，用箭头标出指针变化。至于常规的并发控制模块，提一句“采用现有方案”就够，千万别展开。

实验章节才是论文的胜负手。我常跟学生说，这部分要像侦探小说一样层层递进。先证明你的系统能跑通（正确性验证），再对比同类方案（性能基准），最后做敏感性分析（参数影响）。前年那篇关于内存数据库索引的论文，实验部分用了整整六页篇幅，从单线程到百核扩展，从均匀分布到偏斜数据，每个测试场景都配有对应的硬件计数器数据。这种近乎偏执的验证密度，让读者不得不信服。

遇到反直觉的实验结果，千万别藏着掖着。去年我审到一篇关于日志结构化存储的论文，作者发现自己的方案在写密集型负载下反而比传统B-tree慢了15%。他在讨论部分坦诚分析了原因，指出是缓存策略的失配导致的，并给出了改进方向。这种诚实的处理方式，反而让论文的可信度大增。审稿意见里，三位评审都提到了这个细节，认为这是真实的工程实践。

参考文献的功夫在论文之外。我注意到不少新手喜欢堆砌近几年的顶会论文，却忽略了那些奠基性的经典。有次审稿，作者引用了12篇2020年后的VLDB论文，却对1996年Jim Gray那篇关于分布式事务的经典论文只字未提。审稿人一眼就看出这是文献综述的短板——真正的系统研究者，都该知道自己的技术脉络从何而来。

最后说说那些被拒稿的常见原因。除了创新性不足，最多的就是“实验设计有缺陷”。比如只测试了性能峰值，却没记录稳定运行时的抖动；或者对比方案的参数调优明显不公。我见过最离谱的案例，作者把自己的系统优化了三个月，对比系统却用默认配置直接跑。这种明显的偏袒，审稿人一眼就能看穿。

数据库论文写到最后，其实是在回答一个问题：你的系统在什么条件下，比现有方案好在哪？说清楚这个，论文就有了灵魂。至于那些华丽的辞藻和刻板的框架，都是多余的装饰。数据本身，就是最有力的语言。

(责任编辑：百科)