好消息
tiproxy v1.3支持流量收集回放（实验特性）了，感兴趣小伙伴可以测测，有啥问题或者建议反馈一下。
https://docs.pingcap.com/zh/tidb/dev/tiproxy-traffic-replay
流量收集回放适用场景
- TiDB 版本升级前验证：在新版本的测试集群上回放生产流量，验证新版本 TiDB 能否成功执行所有 SQL 语句。
- 执行变更前影响评估：在测试集群上使用生产流量模拟，验证变更对集群的影响。例如在变更配置项或系统变量、变更表结构、使用 TiDB 的新功能前，先在测试集群验证效果。
- TiDB 扩缩容前性能验证：在新规模的测试集群上按对应速率回放流量，验证新规模集群的性能是否满足要求。例如，为了节省成本要将集群规模缩容到 1/2 时，可以按 1/2 速率回放流量，验证缩容后 SQL 延迟是否满足要求。
- 性能上限测试：在相同规模的测试集群上多次回放流量，每次调大回放速率，测试该规模下集群的吞吐量上限，以评估性能是否满足未来业务增长需求。
流量回放不适用于以下场景：
- TiDB 与 MySQL 的 SQL 兼容性验证：TiProxy 只支持读取 TiProxy 生成的流量文件，不支持从 MySQL 捕获流量后在 TiDB 上回放。
- TiDB 版本间 SQL 执行结果对比：TiProxy 只验证 SQL 语句是否执行成功，不对比运行结果。
【反馈有奖励】
参与测试 tiproxy v1.3 后留言+反馈建议，可以获得 100 积分
1 个赞
dba-kit
(张天师)
2
运行结果，其实可以间接的直接分析information_schema.STATEMENTS_SUMMARY_HISTORY表，不过这些表的保存信息有限，很有可能抓包流量对应的记录，在进行回放时已经被刷掉了。 建议是流量采集完毕，立刻备份下STATEMENTS_SUMMARY_HISTORY表的内容，直接导入到测试 TiDB 集群上。
用户如果想对比SQL 执行结果，直接写 SQL 对比上游 TiDB 集群和下游 TiDB 集群上的STATEMENTS_SUMMARY_HISTORY就可以了，根据digest 每类 SQL的 平均耗时、扫描行数、成功率都可以算出来。
Demo二棉裤
(eR棉裤)
4
作为一个普通的TIDB 用户，且没有任何开发能力的用户，我觉得，复制流量进行测试后，不仅仅是验证SQL 执行的正确性，且需要看到执行计划，对比上下游出现的不同之处。比如上游某个时间段内执行过的所有流量，同步到下游，执行完，能再dashboard中直观的展示出来，而不是通过记录到数据库表中。对于黑盒用户来说，做到简单易用。
感谢。我说下之前的规划：
- 比较结果集：采集时记录行数、结果集的 checksum，然后在测试集群比对。问题是本来就很难保证结果一致，所以会产生很多误报。
- 比较性能：采集时记录 SQL 延迟，在测试集群比对。
- 比较执行计划：采集流量后，建两个测试集群，分别对应两个版本，TiProxy 在 SQL 前面加上 explain 去比对两个集群的计划，这样能比较所有 SQL 的所有参数，但是操作链路太长。
对比 STATEMENTS_SUMMARY_HISTORY 确实是个很好的方案，能比较的维度很多，尤其是扫描行数。缺点是比较不全面，例如 COMMIT 语句区分不出是哪个事务的，但问题也不大。
