-
t_invoice_kj_record
insert 操作并不慢，耗时 time:419.505µs ；
针对这块，我有个疑问：
a. 是否有热点问题？
b. 对于batch insert，是否有足够的优化？ -
t_plugin_online_record 表数据量很小了才500…
但是场景是期望能够支持到 insert 和 update，我查阅执行计划慢的原因：
time:36.579234809s 总耗时
check_insert:{total_time:36.575252287s, mem_insert_time:408.598µs, prefetch:36.574843689s, rpc:{BatchGet:{num_rpc:6, total_time:22.632265ms}}}
检查插入的过程，就耗掉一大半了… 其中 rpc 回调 就 执行了 6次，执行时间 22.632265ms
疑问：
a. 是否有热点问题？
4.X 的版本也是聚簇索引的，但是是隐式的，如果判断有热点问题，建议切换成 auto_random
b. 业务场景上是否有足够的优化空间？ 对于唯一标识是否存在，肯定是知晓的，那么在处理层面就可以单纯切换成 batch insert 和 batch update，并且这个事务也不会太大，可以解决这个慢的问题
- t_plugin_transfer 是什么类型的结构？
按照你给出的计划来看，并不慢
commit_txn: {prewrite:2.177618ms, wait_prewrite_binlog:1.236378809s, get_commit_ts:346.903µs, commit:1.613045ms, region_num:1, write_keys:1, write_byte:3650}
都是以ms 为单位的…
还有更大的疑问，目前环境的整体的配置是否依据了官方的要求？