之前5.4 遇到过 insert 或者 update 数据之后。执行 select，提示 tiflash 找不到 region。貌似与这个也类似。列存副本同步延迟？

1，在某些“领导（领倒）”层面，没有单选题。肯定是Ctrl+A 全选，既要低成本，又要低风险啊。但凡专业一点儿的都会知道鱼和熊掌不可兼得。 2，某些公司，年底资产盘点会让你将买的云资源列出来。但是，云这种东西，你买的是服务而不是资产。 3，云给一些人的第一印象是，低风险、免运维。但是，深受其害的才会了解真的是免运维么？

这种对比，意义不是很大吧？

navicat 中执行，auto_random 也是时而有效，时而失效。

爱之深，责之切

深度好文啊！文中关于监控的描述，之前我在帖子里也提到过。TiDB Grafana 有很多监控（至少得上百个吧），数据库出问题的时候就一脸蒙蔽，图表太多无从下手。还有集群的配置调整，有pd的、有tidb的、有tikv的，有动态可调的，有需要改配置文件重新加载的。也是一脸懵B，参数太多了。记不住，根本记不住。

现在的 TiDB 似乎是一匹脱了疆的野马，各种新特性都很吸引人。但是，细细品味每个特性都做不到完美，需要更多地去优化。久而久之，越攒越多，越欠越多。 个人感觉，应该将一部分能切中用户痛点的特性，做细、做完美，而不是做一款大而全的产品。

和你家的那位一样。

针对这种索引与数据不一致的bug的问题，可否增加些定时任务，定期检查索引、数据的一致性。若不一致则自动修复？或者在 dashboard 的集群诊断增加对索引、数据一致性的诊断，以启用用户手动校验索引与数据？

不试了，太浪费精力了，已通过其他方式绕过了。毕竟是开源免费的，解决不了就想办法绕过。 在 MySQL 及 Oracle 都试过，没有此问题。

在 MySQL 中，执行没有任何问题。暂未得到官方的确认，不清除是什么问题。希望此类问题引起官方重视。

当时sql执行oom了，tidb实例重启了。

并且将 a*b/c/d 改写成 a*b/(c*d) 时，可以正常插入而无报错。

我这边 sql_mode 为 ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

所以就很奇怪，还没有到插入目标表，就已经报错了。并且如果将ab/c/d改写成ab/(c*d)就可以避开这个报错。计算过程中，在内存存中间值时，超过数据类型的存储范围了？ 但是，这个报错的中间值直接插入目标表，可以成功。

不存在超长的情况。 目标表字段定义decimal(40,2)。报错的数值是个中间值（截图红色框线内的值），并不是插入目标表的最终值。 数值在插入前已经 round(value,2) 四舍五入了。 报错的数值直接插入目标表，可以成功插入。

我看过这个文档，应该不是一回事。报错的数值是一个中间结果，并且在插入之前已经通过round函数取2位小数了。不存在数值太长的问题。

在 Linux 里就是一个挂载点而已，可按普通分区对待。为提高效率，单个 TiKV 实例的存储空间不建议超过 2T。

通过什么工具同步的？330300 是什么？确定不是同步工具的锅么？