已查出db_name和table_name，感谢

SQL已经停了，但是TIKV还在一致报类似图片中的错误

Key is locked (will clean up)，应该是出现了读写冲突 想通过region key 命令找到 region，但是内网环境没有tiup ctl 还有什么方式可以查询出ID 或者什么语句、方法找到冲突读写？ 有什么方式可以优化类似的问题？

手动强行使用TiFLASH啊，HTAP既然有就用起来

replace into在有主键或唯一索引冲突时，会执行delete+insert操作 对CPU影响肯定大

GIS吧

已点赞

牛 X 克拉斯

我去。。。又又又来了

如果有足够的资源，肯定是先在测试或模拟环境去升级验证，运行一段时间后评估，评估没有问题后再上生产环境（且提前将升级详细方案写好），降低风险。

10只产品，涵盖4个行业 可以的

不止有KFC [1712890676553]

还有MySQL有个 Index Condition Pushdown Optimization 优化器，只是了解过，没使用过，看看有没有啥帮助 https://dev.mysql.com/doc/refman/8.0/en/index-condition-pushdown-optimization.html

慢查询和索引没有必然联系，一个SQL语句的执行效率最终要看的是扫描行数。 另外可以使用虚拟列和联合索引来提升复杂查询的执行效率。

Region: 负载均衡的最小单元。TiKV 中的全量数据是以有序的方式存储的， PD 根据数据的尺寸将全量数据分割成一系列的 Region，每一个 Region 承载全量数据中一段较小范围的数据。 所以是单独的region

数据库就是个底层，是基础，上层还有中间件，应用层，网络层等等 貌似和你说的事情有一点点关系，但好像又没有啥关系 如果是计算能力和存储能力的话，HTAP，计算和存储分离的TiDB应该可以满足你的需求

有详细的功能对比，主要是 1.安全（比如审计功能） 2.技术支持 3.图形化平台组件 等方面的不同 [1712887370051] [1712887722301]

你这文章把TiDB换成任意一个其他名词都可以用，简直了！ 鸡汤如果有用，还要医院干什么？

参考 专栏 - TiDB PD 组件代码阅读 | TiDB 社区