统计信息 检查一下自动收集策略，是否在某个时间 dml 大量操作导致统计信息触发，导致执行计划问题。另外如果是有分区表，可以把统计信息提前导入然后锁住不收集。执行计划 如果确定是典型海量 update 业务场景的查询，total key 和 process key 命中率低，可以看看要不要开启 IME 配置，提高内存命中率。

参数配置问题，这个参数前后版本应该发生配置变化了，删掉重新配置看看

这个业务启动都有那些 SQL 执行看看比较低效？另外业务启动完以后，读写请求并发处理都正常嘛？

root 执行增加➕x 看看报错是啥

在 v7.5.6 测试也没有问题 mysql> CREATE TABLE `files` ( -> `id` bigint(20) NOT NULL AUTO_INCREMENT, -> `project` varchar(32) DEFAULT NULL, -> `parent_id` bigint(20) DEFAULT NULL, -> `name` varchar(255) DEFAULT NULL, -> PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */, …

我觉得可以收集一下表的统计信息看一下，我试了下在 v8.5.3 也是 IndexRageScan mysql> DESC SELECT * -> FROM `files` f0 -> LEFT JOIN `files` `f1` force index(uk_file_project) ON `f0`.`id` = `f1`.`parent_id` AND `f1`.`name` = "bbbb" -> LEFT JOIN `files` `f2` force index(uk_file_project) ON `f1`.`id` = `f2`.`pare…

统计信息收集过嘛？ 如果统计信息不准确，可能会导致全文索引。

explain analyze SQL 看一下哈，主要 exec info 的信息看看具体执行计划。

Swoole稍微好点，也是使用到 TiDB + PHP 场景嘛？能提升并发处理能力效果怎么样？有没有啥风险或者注意事项？求最佳实践

咱们是什么场景用过？ 最后 TiDB + PHP 方案使用了 Octane + Swoole 方案了吗？

emm ~ 是说 TiDB 这边拆表嘛？还要用三方的 PHP连接池，目前我知道 PHP 开发应用一般不会用。

是的，那文档错误应该不影响你部署。如果部署成功的话，也可以给官网提提建议文档应该怎么改哈。

确实门槛有点高，要不快速上手先体验一下？https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/get-started/

TiDB Operator 开源社区在这里哈，如果想要反馈问题，可以直接在这里找到 TiDB Operator 的 Group 反馈问题。https://github.com/pingcap/tidb-operator ，这里是 TiDB 的互助问答社区，大家可以开诚布公的解决问题，反馈相关问题。如果咱们实在不好解决问题，欢迎联系 商业化团队 协助解决问题。 [image]

TiDB Operator 部署成功了吗？看报错是 TiDB Operator 部署问题。所以现在部署 TiDB 集群报错。可以看一下 https://docs.pingcap.com/zh/tidb-in-kubernetes/v2.0/deploy-tidb-operator/#部署-tidb-operator-crd 操作，另外别用 v2.0.0-beta.0 版本，这个版本是 beta，不是 GA。

有检查过 TiKV 和 PD 网络隔离的情况吗？ 同样问题是集中在部分节点有没有做 label 设置，看一下 PD 的 config all 结果发出来。

物流仓库选址为主吗？

订单交易撮合指得是不是 拼车 和 上下车衔接的部分距离测算？

发一下监控看看这个监控数据是多少 [image]