你理解是对的，就是没啥用，写不写最后结果都一样 不知道为啥写

你现在用 TiDB 时，最卡业务、最费人力的问题是什么？ 感觉没有啥特费力的 如果加一个新功能就能少加班、少踩坑、少花钱，你最希望是什么？ 内核能力继续提升吧，数据库运行稳定最重要。 什么功能一旦上线，会让你更愿意升级 / 付费企业版？ 现在企业版的 TEM 白屏化运维能力 企业版的敏捷模式、聚能模式 还有快发布的物理备库功能 感觉这些都挺好的

连接数 Sleep 代表当前未执行 SQL

携手奔赴下一个十年！

grafana 监控中有个 lightning 的面板，然后有个 import/normal mode 的图 [image]

看下 iostat 的帮助，你就知道哪个指标对 nvme 来说没有啥意义的 %util Percentage of elapsed time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100% for devices serving requests serially. But for…

不是 bug，符合 SQL 标准，有个系统变量可以控制行为 tidb_remove_orderby_in_subquery，系统变量

tpch 测试要给表加 tiflash 副本

问的问题太泛，无法回答

看了下参数，可能是 tidb_audit_log_redacted 参数，控制是否审计日志是否脱敏 审计日志是企业版本功能，建议找原厂售后支持

看下操作系统日志有啥东西没 可以登录到目标 tikv 节点，先停止服务拉起 systemctl stop tikv-20160.service，然后去到部署目录下，找下有个启动脚本，手工运行试试

是的，TiCDC 当前的部署架构中，就是属于上游的的组件 A → B 则需要用 tiup 在 A 集群中扩容 TiCDC 节点 反过来 B → A 则需要用 tiup 在 B 集群中扩容 TiCDC 节点

主机层面的问题，找主机啊 部署在云平台上就去找云厂商

看下 tikv 日志目录下 stderr.log 有东西吗

无感分片不侵入业务、横向扩展避免算力不足、存算分离扩缩容灵活、分布式数据库的高可用能力、超大容量避免存不下、高度 mysql 兼容减少学习和迁移成本 让业务开发专注于业务

一般意义不大，因为数据默认就是分散在所有tikv机器的，每个节点都是既有 leader，既有follower的 只有在那种多中心部署架构，然后某中心又全是follower的时候，这种情况可以读取本中心的follower副本数据，避免产生大量的跨中心流量

先看慢查询日志，这块有执行计划，会显示每个算子执行效率

充电器头非常好用