为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
使用sysbench工具在mysql数据库上模拟OLTP业务，分10个线程对10个表，每个表5000条记录做操作
sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=10.200.25.*** --mysql-port=3306 --mysql-db=testdb --mysql-user=test --mysql-password=****** --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=5000 --threads=10 --time=120 --report-interval=10 run
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出打印结果，请务必全选并复制粘贴上传。
sysbench 测试的创建的 schema 是自增主键的表，自增主键不适合在 TiDB 上面进行高并发写入场景。建议将自增主键的表结构进行一下优化，这里可能会有写入热点的问题，导致你描述现象是一个 TiKV 使用率高，可以参考一下 《TiDB-in-Action》来优化一下 sysbench 的压测逻辑。
https://book.tidb.io/session4/chapter7/hotspot-resolved.html
主要是上游库mysql 业务上使用的表基本都是带自增的，这个比较难优化了，除了这个还有其他的地方可以优化的吗
可以使用 DM 进行增量同步，下游自己建一个主键非 int 的类型的表，然后设置 shared_row_id_bits 打散。然后全量通过 mydumper/lightning 来完成同步。
可以参考以下方法收集：
(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl
(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。
(3)、使用这个 full-page-screen-capture 插件进行截屏保存
sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=10.200.25.xxx --mysql-port=3306 --mysql-db=testdb --mysql-user=test --mysql-password=xxxx --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=3000 --threads=80 --time=120 --report-interval=10 run
测试关闭了TIDB 表自动统计信息了。 关闭自动统计分析后，确实对减少同步延迟有效果。大概可以减少0.5-0.7分钟左右的延迟。
TIDB.log (47.8 KB)这个是 swap ，你的 swap 没有关闭吗？ 安装脚本是有检测关闭的，你当时是设置参数全部跳过了吗？ roles/check_system_dynamic/tasks/main.yml:69: msg: “Swap is on, for best performance, turn swap off”
现在swap占用cpu过高，看下能否关闭swap，多谢。
马上解决这个问题，我在测试一次
解决cpu高的问题后，测试情况如下
1 关闭自动收集统计信息
2
sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=10.200.25.2SSS --mysql-port=3306 --mysql-db=testdb --mysql-user=test --mysql-password=SSS–oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=3000 --threads=80 --time=120 --report-val=10 interscreencapture-10-200-25-80-3000-d-eDbRZpnWk-hcloud-test-cluster-overview-2020-05-19-11_28_06.pdf (3.6 MB) screencapture-10-200-25-80-3000-d-Lg4wiEkZz-hcloud-test-cluster-tikv-trouble-shooting-2020-05-19-11_27_28.zip (4.3 MB) screencapture-10-200-25-83-3000-dashboard-db-test-cluster-dm-worker-2020-05-19-11_27_09.pdf (1.5 MB)
顺便问下这个统计信息自动收集关闭run-auto-analyze有什么影响？
在测试过程中，发现表数据量少些，怎么同步延迟还大些？？
能帮忙在看看吗？
稍等，会尽快回复
在测试过程中，发现表数据量少些，怎么同步延迟还大些？？
sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=10.200.25.225 --mysql-port=3306 --mysql-db=testdb --mysql-user=test --mysql-password=123456 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=200 --threads=10 --time=120 --report-interval=10 run
延迟有1.3分钟
如果是上面的截图，按照上面的答复，先尝试解决热点问题。
