本文档为 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和开发人员根据索引使用情况来进行评估是否删减。

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

建议人：@人如其名