关于查询交易（要特别注意区分本次查询的码和原交易的码）：
1. 查询交易成功，原交易成功
2. 查询交易成功， 原交易失败
3. 查询交易成功，原交易处理中
4. 查询交易失败，不做任何处理，等待下一次查询（查询交易失败，注意不能翻失败，查询交易失败可能是网络问题导致的）
5. 隔日查询的问题（上送的原交易时间一定要是原交易发生的时间。假如2月2日发生的交易，2月3日去查询，应该上送的原交易日期是2月2日，如果送2月3日则可能会导致银行返回原交易不存在）
6. 原交易不存在不能贸然置为失败，无此交易置失败有资损风险。
原交易不存在可能是以下几种情况造成的：
1）由于网络原因，查询交易先到、原交易后到，导致查无此交易；
2）原交易发到对方，对方校验就失败了，交易没有落库，再去查询的时候会返回无此交易；
3）或者查询交易到达对方的时候，原交易已经到达对方但是对方还在处理过程中，没有落库，此时会查无此交易）
关于查询分页、性能（测试/产线数据量差异）：
1. 查询的实时性要求。实时性不高的一般连备库，考虑主库备库的同步机制，备库可能时延在半个小时甚至更长时间的延迟。
2. 查询的频率。如果查询频率较高，一般连备库。如果连主库，万一遇到高频访问，把主库整挂了，容易出现主交易链路上出现问题，很危险的。
3. 查询的数据量。分页功能+限制条件，控制数据量。如果查询的数据量很大，一定要有分页功能。还有是否要加时间限制或者多个限制条件，防止查询返回的数据量过大，进应用内存时把应用搞挂。如果查询之后又导出功能，这个导出功能也得注意。
4. 如果还有报表导出功能，要注意导出的数据量。测试的时候，可以测试大数量的10w、50w、100w等大数量导出，参考产线的交易量数据。