1.数据大不大。大的话，耐心等待。 2.一般时间与数据大小成正比。 3.创建需要时间，取消回滚时也需要时间。反向操作，谨慎操作。 4.cancel kill等操作也会加速心跳，荷尔蒙的分泌。

one very good student！

查询下，看看 SELECT store_id, leader_count, region_count FROM INFORMATION_SCHEMA.TIKV_STORE_STATUS;

提高效率的几点思考方向： 1.在线ddl。不影响读。 2.尽可能不移动数据，复制数据 3.只变化增量数据。 4.多租户，资源隔离 事务隔离

去了解悲观和乐观，默认悲观。 默认 自动提交事务。 不要怀疑tidb基本的处理逻辑。 可以根据反馈 多了解下tidb 。某些地方和mysql也是有区别的。

1。功能问题。 2.算法问题。 3.文章质量问题。 我倾向算法问题。显示出来的排序前面的是质量较高的。可能默认把自己的文档排除了，排的比较靠后。全文搜索，精准搜索功能不佳。 如果是bug，也没有什么大的技术难度。社区搜索 能搜到 最配的答案为最佳。

pd etcd

其实你自己都知道为什么。

@Billmay表妹 下

联系官方，后台改下

连续时间使用between and 试试呢？

牛 了 牛 了

配置ntp 保证各个实例的时间一致。分布式时系统对时间要求还是很高的。然后重启下集群试试呢

telnet ip 端口 试下呢

如果把更新拆分 删除 和插入。且你们用到了csv和avro协议会可能仅输出新值的话，应该会有影响。我理解的是因为没法更新前后的比较了。

good good good ~

超时，报错服务不可用？channel 字段区别度高吗？explain 看下。估计是没走索引。 可以加个limit 1 看看会查询到结果吗