作者： Billmay 表妹原文来源：https://tidb.net/blog/c39bbcf9

本文档为 TiDB 社区用户一起共创的内容：关于 TiDB 产品发展的建议，感觉产品在设计的过程中，会经常由于一些细节问题，引发了一些本不应该出现的技术问题。

一、SQL 相关

建议一：SQL 应该向下兼容

• 原因：经常由于升级后查询 SQL 时，发现同一个 SQL ，旧版本上跑得通，但是在新版本上跑不通，导致了数据库报错问题

• 案例：在 5.3 版本里发现一个问题 lower_case_table_names=2，但是唯一索引列不区分大小写，而在 6.5.5 里却报冲突

• Asktug 相关链接及其他案例：

• TiDB 升级 7.1 之后，很多业务出现 SQL 不兼容问题

• 案例 1：tidb-5.0.4 升级到 tidb7.1.0 sql 不兼容反馈，踩坑血泪史【欢迎大家补充】
  

• 案例 2：https://asktug.com/t/topic/1013699/1
  

• TiDB 升级 7.1 之后，很多业务出现 SQL 不兼容问题

二、执行计划相关

建议二：新版本新增特性参数配置默认关闭（如 6.x 版本执行计划缓存参数开启有 OOM 风险）

• 原因：tidb_enable_prepared_plan_cache 从 6.1 版本开始引入，默认开启 Prepare、Execute 执行计划缓存（），在高 TPS 写入场景下，tidb 计算节点内存短时间暴涨至 20G 左右，发生 OOM

• 案例：生产环境案例

• 社区案例：https://asktug.com/t/topic/994893/11

建议三：执行计划参数如果新版本有增加一些新的参数，应该默认为：关闭，而不是开启

• 原因：TiDB 不像 Mysql，一般 TiDB 存放的数据量相比 mysql 来说会大很多，当升级新版后，一些执行计划参数默认开启经常让 DBA 有点措手不及，很容易引发 OOM ，一旦 OOM ，处理起来将特别麻烦，一朝出问题，永世不升级

• 案例：tidb_ddl_enable_fast_reorg v6.5 的默认值为 ON，但是依赖的temp-dir默认为 /tmp/tidb 目录，而不是`data-dir`，导致升级后有不少帖子出现 DDL 报错的问题。

https://docs.pingcap.com/zh/tidb/v6.5/tidb-configuration-file#temp-dir-%E4%BB%8E-v630-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5

https://docs.pingcap.com/zh/tidb/v6.5/tidb-configuration-file#temp-dir-%E4%BB%8E-v630-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5

• Topic:https://asktug.com/t/topic/1009793

三、升级相关

建议四：升级失败可以回退

• 原因：

好多生产环境，由于各种原因，只能通过原库直接升级的方式去升级。由于停机窗口有限，一旦升级失败或者遇到棘手问题，就比较麻烦。因此出现问题后及时回滚的功能就很重要。

• 案例：

https://asktug.com/t/topic/1000352

https://tidb.net/blog/8d94086c

• 原因：升级出现故障，由于时间窗口，回退功能是非常必要的

• 案例：https://asktug.com/t/topic/1010847

• 建议人：@裤衩儿飞上天

• 原因：官方发布新版本，有性能提交或修复 BUG。我们都想升级尝试一下。但是升级不能回退，相当于把退路都堵死了。万一有问题或者是效果不理想又没有办法解决。想升级，领导那关都过不了。

• 建议人：@zhimadi

四、监控相关

建议五：grafana 监控中 OPS 视图中 others 类型应该记录完整

• 原因：代码中以外的都在 others 中，理论上 tidb 跑的东西应该会有详细的记录，而不应该放在 others 里让人猜测。https://github.com/pingcap/tidb/blob/533998e5921a8f662c878b60a5d0c9608d52d736/parser/ast/ast.go#L166-L257 1
  

• 案例：一次监控视图中 ops 中 others 到达 200，select、update 等常规操作不到 100，无法看到集群在执行什么

• 建议人：@Soysauce520

建议六：文档或视频增加一些监控面板的常见使用案例及参数说明、指标正常区间

• 原因：经常会有小伙伴问某个参数的是否有问题或如何计算？且排查问题时，监控指标的文档部分有点不是特别清晰，之前根据读性能排查的帖子排查起来有时候也有点似是而非的感觉。

• Asktug 链接：

• https://asktug.com/t/topic/663669
  

• https://asktug.com/t/topic/1007724
  

• https://asktug.com/t/topic/1002937
  

• 建议人：@ealam_ 小羽

五、Dashboard 相关

建议七：正在执行中的比较消耗资源的 sql 语句能有地方看到内存实时消耗

• 原因：我们可以从慢查询等查到一个 sql 执行完消耗内存，但是执行中看不了。

• 案例： tidb 某个正在运行的 session/process 占用的 tidb 内存多少怎么看
  

• 建议人：@zhanggame1

建议八：对一些经典场景，把一些相关的指标集合到一个 dashboard

• 原因：虽然 tidb 提供了丰富的 grafana dashboard，但是在一些常用的场景，往往需要看多个 dashboard。

• 案例：比如热点写，热点读，读写冲突

• 建议人：@TiDB_C 罗

建议九：dashbaord 左上角增加可以自定义设置集群名地方

• 原因：相同版本集群多时可以能更好的识别是哪个集群

• 建议人：@h5n1

建议十： 建议将 TiKV 的 heap 分析集成进 dashboard

• 原因：tikv 的 heap 分析藏的很深，有点难找

• 案例： tikv 火焰图从哪里调出来的？
  

• Asktug 链接： 建议将 tikv 的 heap 分析集成进 dashboard
  

7.5 版本中已经集成到 tidb-dashboard 中了，敬请期待。相关 issue https://github.com/tikv/tikv/issues/15927

六、文档相关

建议十一：文档【系统变量】【配置文件参数】目录下，添加栏目用来记录弃用系统变量或配置文件参数。

• 原因：新版本发布后可能会有 系统变量或配置文件参数 弃用的情况，目前是分散记录在每个版本发布说明中。无法一次查看到所有已弃用的系统变量或配置文件参数

• 案例：当跨大版本或较多小版本升级时，只看新版本的文档无法知道哪些 系统变量和配置文件参数 弃用了，只能逐个版本说明查看，费时费力。

• Asktug 链接：tidb-server 的两个参数是有改变吗？
  

• 建议人：@Kongdom

建议十二：中英文文档保持一致

• 原因：发现最新版本的中英文版本的 cdc 文档不一致，有小伙伴查文档拿无效的配置参数在用。

• 案例：论坛问题连接 https://asktug.com/t/topic/1015638
  

• Asktug 需求链接：https://asktug.com/t/topic/1015652

• 建议人：@像风一样的男子

七、TiUP 相关

建议十三：建议在 tiup 时可选择部署分发器组件（如 haproxy）

• 原因：部署完数据库库后，还需要部署分发器组件，且分发器组件不能像其它组件一样，监控，管理，不能做到统一，建议增加分发器组件，进行统一，安装，监控，管理等。

• 案例：部署时只能选择 tidb, tikv ,pd pump, 等组件唯独没有分发器组件，配置管理易出错呀

• Asktug 链接 haproxy 之后连不上 tidb
  

• 建议人：@heiwandou

建议十四：tiup 安装时，可选择 grafana 更多的监控模版

• 原因：DM，BR， Lightning，等等一些工具需要手动的才能接入到 同一套 prometheus，希望能实现自动化配置接入

• 案例：监控分散，需要额外做很多手工处理才能达成这个需求，能否追加一个更加快捷的方式…

• Asktug 链接：

• https://docs.pingcap.com/zh/tidb/stable/migrate-data-using-dm# 第 -8- 步监控任务与查看日志
  

• https://docs.pingcap.com/zh/tidb/stable/monitor-tidb-lightning
  

• 建议人：@xfworld

八、统计信息相关

建议十五：可以设置自动收集统计信息的并发度和收集比例

原因：目前自动收集是单线程，表大的根本收集不完，都需要用户手工创建脚本来收集，这个可不是一个成熟的数据库应该出现的

案例：论坛中因为大表导致统计信息收集失败问题例子很多

九、负载均衡相关

建议十六： TiDB+keepalived 的版本问题

• 建议：TiDB 能统一访问层，出自己的或测试通过的统一版本负载均衡组件。

• 原因： TiDB 的负载均衡策略使用 HAproxy+keepalived 方案，此方案对于版本的支持没有详细建议，毕竟外部组件的自由度是一大隐患，论坛有因负载均衡造成的问题, 且 KEEPLIVE 版本的问题导致使用 2.0.18 的版本发现偶发丢包，造成业务超时。后来替换为低版本的 1.2.8 后解决。

• 案例：TiDB 使用的坑有哪些 - 大数据 - 亿速云 1
  

• Asktug 链接：大家都用什么做 tidb server 的负载均衡？
  

• 建议人：@TiDBer_ 小阿飞

十、集群管理相关

建议十七：希望增加一些可视化的管理界面，减少运维成本或者降低维护风险，比如支持组件或者节点服务相关配置的在线修改

• 原因：对于已经启动投入到生产使用的集群，需要修改相关配置或者性能分析调优时，如果通过命令行操作，操作不慎或者对相关变量不熟，容易影响业务使用或者造成集群的不可用

• 案例：集群部署后，修改相关配置；性能分析后，想要修改相关参数测试性能

• Asktug 链接：V7.1.0 tidb 安装部署时拓扑文件如何最优化 集群监控分析
  

• 建议人：@随缘天空

十一、可观测性相关

建议十八：可观测性，在数据库内核层面提供的数据还是太少了，且感觉较为混乱。

• 表的统计信息有的存在于 mysql 视图下，有的在 information 视图下，看似较多地方查询实则缺少较为实用直观的视图：比如

• 我想查某张表最近一次统计信息更新时间，如果这张表很久没有更新，那么就很难查询到，如果在 syscat.tables 中存在一列说明统计信息最后一次更新时间，那么还是很有帮助的。

• 太多的 show stats 但缺少直方图的视图查询（默认 mysql 库下的太不直观），比如快速的查询一个字段的分布频率（用于评估等值条件）和分位数（用于评估范围条件）情况，在视图中可以进行关联等操作。

• 对于 TiDB 来讲，多一个索引维护代价就增加较多，因此对索引的监控很重要，在 TiDB 中缺少自重启以来（或者统计信息搜集以来）索引和表的使用情况，包括：时间周期内某索引的 IndexOnlyScan 次数，IndexScan 次数，IndexFullScan 次数，全表扫描次数（或全分区扫描）等等，这样可以让 DBA 和开发人员根据索引使用情况来进行评估是否删减。

• 数据库提供的监控数据层次不太清晰，比如应分为数据库层、连接层、事务层、语句层。对于每一层还有很多指标需要更细力度的设计，可以参考 DB2 或者 Oracle（个人认为 DB2 设计的更简单易用清晰明了）做下加强。目前对于连接泄露，事务执行情况（是否包含多个增删改，修改过多少记录），语句的指标（rows_read,rows_select, 用了多少数据读，索引读，CPU，IO 等）都还较为粗糙，希望能进一步加强，最好整体设计参考 DB2、Oracle 做一个 TiDB 自己专有的视图库。

• 后台作业应统一视图来进行查询当前进度和近期历史，将统计信息、备份、DDL 统一起来，且都可以利用 kill 进行杀掉。

• 建议人：@人如其名

十二、TiCDC 相关

建议十九：

• 希望上下游都是 tidb 集群时，ticdc 摆脱对 GC 的依赖（大集群长时间 holdGC）。可以利用 BR backup 全量恢复，ticdc 读取 BRlog 来追增量，最终再拉去 tikv log。

• 希望摆脱对上游集群的依赖，目前上游集群挂掉，ticdc 无法工作，希望在上游集群挂掉后还是能完成已经传到 ticdc 中日志的同步到下游。

• ticdc redo，当上游出现灾难性故障时，下游的最终一致性可能遭到破坏，为了保证下游同步到一致性点引入了 redo 的概念，但是 6.5 后 ticdc 推荐部署在上游，ticdc redo 推荐写在下游（避免上游整体机房出问题），如果下游需跨中心访问，那么还要开通到下游的磁盘共享权限，这块可能有一些企业要求严格，不允许跨中心访问共享 NAS，能否提供下游 redo 的接受日志的客户端工具呢，这样中间还可能能压缩传输减少消耗。

• 尽早完成权限体系设计，权限独立和配置免密等。

• 建议人：@人如其名

建议二十：

• +1 TiCDC 对上游的影响，尤其是与 PD 的耦合程度如果能够大大降低，甚至是解耦独立出来，就可以比较好地保护原集群不受 TiCDC 的故障影响。曾经我们没什么经验用了低版本的 CDC，然后同步状态信息存储在 etcd 踩到坑导致整个 PD 集群不可用，全部业务受到了影响，深有感触。

• 建议人：@Jellybean

建议二十一：

• 这是使用 TiCDC 时遇到的一个问题，就称作 TiCDC 不支持无有效索引同步时可能出现的问题。看官方技术团队有没有解决或规避这种问题的办法

• 基于 TiCDC 的主从同步集群，在出现无效索引表进行 DDL 操作时导致同步任务失败。

• 案例：TiCDC 不支持同步无有效索引的表，但是同步所有的 DDL 操作。如果创建了无有效索引表，但是做相关的 DDL 操作时，基于 TiCDC 的主从同步任务就会报错，因为在从库中会找不见相关表，但是要执行 DDL 命令，这会导致数据同步任务的异常。

• 建议人：@TiCQ

十三、TiDB Server 相关

建议二十二：

• 对于 update、delete 操作，tidb 还是需要把整行记录拿到 tidb-server 中，我想这主要因为 1、需要维护 tidb-binlog，需要将整行记录传给下游；2、有较多涉及到的索引字段须读到 tidb-server 中加工处理后回填维护索引。但是这大量的数据搬动可能消耗大量的网络资源（网络带宽、GRPC 通道拥挤）。因此是否能下的功夫优化这个无法绕过的问题。后面不推荐 tidb-binlog（ticdc 代替下游供数、brlog 代替增量恢复），那么更应该着手优化这块，可以设置成开关对于关闭 tidb-binlog 的对于 update 和 delete 不应读取所有数据到 tidb-server，只读取需要修改的或者需要删除的 rowid 字段（包括索引字段）。

• 优化 decimal 等数据类型带来的放大问题，减少网络资源使用。

• 适当控制全表扫描并发度（存在无法下推函数，前端用游标读取等方式，可能读取大量数据到 tidb-server 又积压在 tidb-server 上），减少网络资源使用，也避免在 tidb-server 侧堆积数据占用大量 tidb-server 内存。

• 优化 tidb-server 的 clientGRPC 和 tikv-server 的 serverGRPC，增加资源隔离、队列优先级等策略保障小事务，点查，简单索引查的优先级，让全表查、大量回表查、大量数据写入等优先级排低（这块可能对优化器的评估是个巨大的考验）。

• 建议人：@人如其名

十四、drainer 相关

建议二十三：优化 drainer 增量同步时内存使用问题

• 原因：增量同步时使用内存过高

• 案例：之前生产环境不支持 cdc，使用 binlog 同步时 drainer 占用了 200 多 G 的内存，当时将服务器内存＋到近 300G，启用 drainer 时间也很长，ansible start 已经报 error，当时排查一头雾水

• Asktug 链接：https://asktug.com/t/topic/996124

• 建议人：@普罗米修斯

十五、sync_diff_inspector 相关

建议二十四：sync_diff_inspector 做上下游数据对比时可能会导致集群性能抖动

• sync_diff_inspector 是一个非常强大的数据比对工具，考虑了很多方面，且非常实用，完全比自己写对比脚本要好用很多，在功能、配置、效率、结果展现等方面都有点出乎我预期，但是在分析该工具时发现还是会存在一些可能会导致集群抖动的问题，在实际测试使用时也是验证了这一点。

• Asktug 链接：https://asktug.com/t/topic/1016331
  

• 建议人：@人如其名