TUG_Admin
(TiDB User Group)
1
亲爱的 TiDBer ，
大家好，马上就年末了，很多朋友也都在进行过去 2020 年的一些总结和盘点。过去一年，TiDB 在所有社区小伙伴的支持和帮助下快速发展，成长过程中难免会有一些磕磕绊绊，让大家觉得不舒服、不开心以及需要改进的地方。
因此，我们特地举办此次吐槽活动，不论您是开发者，还是社区用户，大家在了解、学习、使用、贡献 TiDB 过程中有任何需求、建议和问题都可以吐槽给我们。每一位小伙伴的吐槽我们都会认真倾听和思考，积极采纳与改进。 更重要的是，参与的小伙伴还有机会获得我们提供的丰厚的奖品，快快行动吧！
时间 ：
2021 年 1 月 27 日 — 2021 年 1 月 29 日
格式：
您可以任选其中的一些项目在本贴内留言吐槽
- 产品使用过程中遇到的问题及建议：
- 现有功能建议：
- 期望产品新增功能：
- 社区组织的活动体验：
- 对于目前的社区技术支持服务体验：
- 对于目前 TiDB 社区项目的吐槽：
- 对于目前 TiDB 社区运营人员的吐槽：
- 其他需求和建议：
礼品：
为了感谢大家给予的反馈，本次吐槽活动我们准备了丰厚的礼品：
留言点赞数第一名的小伙伴将获得蓝牙音箱一台；
留言点赞数前 5 名的小伙伴将获得 TUG 冬日定制围巾一条；
前 20 位认真吐槽的小伙伴将获得 TUG 周年定制T恤一件；
另外参与本次活动的小伙伴都可以获得 500 积分奖励。
感谢有您，让 TiDB 勇往直前；期待有您，陪伴和见证 TiDB 的每一点进步，欢迎您畅所欲言！
获奖名单公布：
恭喜 TUG微尘 获得蓝牙音箱一台
恭喜 18515065291，bbhy135258，Tjianke，sykp241095，honor100，tsthght 获得周年定制围巾一条
4 个赞
是否有可以有图形化的安装部署和配置管理及日志搜集呀？谢谢！
1、TiDB写入速度不能让人太满意，且调优复杂
2、TiFlash AP性能不能让人满意，且内存无限制
3、dashboard，拉时间范围的组件不好用
4、TiUP的问题居多，例如：
a:tiup执行pd-ctl 命令不能外部调用
b:离线部署多版本，才支持
c:对运维的工作、需求了解不好
d:对于3.x版本升级过来的，还会造成误删除节点
e:总改相关输出项目，导致自动化难度高，改自动化代码频繁（例如获取dashboard地址，新旧版本输出不一样）
5、TiDB对于机器资源要求、使用很高，尤其CPU/磁盘，导致选型困难
6、主键不能操作，最近的问题：自增主键，业务自己指定主键写入，导致写写冲突，主键值变的很大
7、alter 还是只能指定一个操作，不能一个SQL操作加多个索引
8、很多类型不能改，例如varchar只能加长，decimal不能改
16 个赞
后面稳定版本是否可以推出 日志结构描述的内容呀？谢谢
tsthght
(tsthght)
7
1 按业务场景，提供现有接入的最佳实践+采坑/避坑指南，用户之间分享经验
2 稳定性加强，确定每个组件异常宕机最大故障时间和故障范围，以及对应故障处理手册
3 TP性能提升，尤其是在混合TP workload 下的性能提升
4 可观测性增强，监控力度更细，能够在dashboard上可以提供按照表维度或者用户维度的监控等
2 个赞
honor100
(Honor100)
8
1、分区表一直不支持 key 分区，也就是不支持 字符串 hash 分区；等待了好久，说是 5.0 会出，结果 5.0 出了，还是没有
2、希望 tikv 也和 tiflash 一样，支持多块盘存储
2 个赞
为了支持online ddl，引入了一个非常致命的软肋。
tidb几次心跳内无法加载最新的schema就导致tidb服务不可用。
这个事儿有点大。
真正的生产环境，修改表结构是个非常低频的操作，为了支持一个非常低频的操作，引入一个几十秒就要同步一下schema信息，同步不到就拒绝服务的机制，代价有点大。
建议整个选项，或者优化这个机制，如果没有ddl的job，就不需要同步schema了。
1 个赞
老房
(葱头巴巴)
10
大家肯定会很多不爽的地方，只要实事求是，都可以吐槽。除此之外，我们还有个传统，就是会定期举办《吐槽大会》，本周末 TUG 牵头搞第三期《吐槽大会》，我们会邀请大家当中的代表和 TiDB 产研负责人进行面对面。目前已经有潇姐、春雷、晓磊报名。欢迎更多小伙伴来报名或者给直接给他们几位提供弹药与建议。
3 个赞
TUG微尘
(TUG微尘)
11
产品使用过程中遇到的问题及建议
问题：
1.执行计划突然改变导致业务出问题(频率较高影响较大)
2.Tiflash查询优化，Tiflash查询前需要同步所有数据，保证读取到最新的数据，会影响查询效率
3.tidb insert优化，目前在生产环境遇到过一些瓶颈，希望insert能更快
4. 关于调度，没配置label，我这边扩容之后新节点磁盘降的很慢(调大store limit会加快)，老节点磁盘还在快速下降(重点)，并且集群稳定后，各节点磁盘使用量并不平衡
5. 集群中有tikv节点磁盘爆掉之后drop partition未执行
6. cdc下游配置mysql/tidb时，配置的用户没检查权限是否满足要求
7. TiUP元数据怎么备份，目前元数据单份，有一定的风险
现有功能建议
1.加强分区表partition的功能
案例：下推至tiflash的执行计划未做分区裁剪
需求：
- 支持更优的分区裁剪功能，加快查询效率
- 目前mysql规范中，分区键一定要加入到pk/uk中，但是这对业务会有一些侵入性。比如分区键是时间字段，用upsert逻辑更新时间字段会导致多一条数据出来，业务还要先删除原来的数据。需求是upsert也能在原来的数据上直接改。（这个突破了mysql对分区表的定义，或许tiflash/tidb可以支持一种更高级的分区功能）
2.加强算子下推
案例：length、ADDDATE算子未下推至tiflash
需求：
- 案例中的 length, ADDDATE 等算子的下推，特别是和时间处理相关的函数下推，因为分析业务中时间是常用的过滤条件
- 下推能力至少能和tikv持平，即当前tikv能支持的下推，tiflash都需要支持一下，否则tikv就会比tiflash算得快，tiflash就没有使用的理由
- 我们某些特殊的业务，里面用到的json类型，相关的json算子也需要支持下推一下，比如json_length, json_extract…，不限于这些。
3.ddl同步至tiflash
案例: enum类型添加枚举值未同步到tiflash
一个是schema层面上忽略了这个enum的变化，第二个是存储层也不支持这个enum的变化
需求：
4.insert/update/delete/replace select不会走tiflash
案例：replace into select 语句无法走tiflash
需求：
- insert into xxx select from xxx 是很常见的sql业务，这是利用数据库本身的能力做一些简单的类似于物化视图的行为，一个sql同时存在读写，tiflash需要支持这种场景
5.Tiup没对网络打通这一块感觉考虑不足，一般存储服务都在内网，一些功能涉及到内外网或者管理网不通就无法使用了
6.TiUP的设计希望能更贴合一般公司的架构，更方便的接入公司系统。
期望产品新增功能
1.TiDB: 提供智能的表结构优化功能
背景:
- 一些平台化的服务，在后端建表仅会建字段和属性，并不会考虑加索引、sql优化等事情
- 业务侧开发人员水平不齐，会造成一些表未加索引或者索引不够优
- TiUP搞个Console?
社区组织的活动体验
希望能增加一些偏db开发的分享会
对于目前的社区服务体验
很赞
对于目前 TiDB 社区项目的吐槽
1.建议TUG答疑帖与技术文章分开
对于目前 TiDB 社区运营人员的吐槽
无
其他需求和建议
1.是否可以考虑对给开源组件首次提pr的同学安排个mentor
16 个赞
给线上资料的一些建议：有一种感觉，资料十分多，但找不到主线
5 个赞
Howie59
(Howie66)
13
期待小表场景的优化。如果Index 和 Data 在不同的 TiKV 上面，就多了一次额外的网络开销
田帅萌7
(田帅萌)
16
5.安全漏扫 绿盟等软件 扫描tidb时会报成MySQL版本，可以把MySQL版本号调高。或者跟安全厂商沟通，引入tidb漏扫机制。
6.可修改 添加删除自增主键列，使用自增主键也可以使用shard_row_id_bits(主键改为逻辑主键，实际存储还是使用row_id方式 作为物理主键)
7.tidb自带监控项目太多。tidb多套集群监控、报警系统整合一套，避免重复搭建 。
Hi，感谢提出这些中肯的回馈，先回答一下部分与 DDL 限制相关的问题：
总而言之，我们在持续地对 TiDB 的 DDL 能力进行改进，但考虑到元数据操作的重要性和影响，一些已经开发的功能还没有在正式的发布版本中支持，这一点还请理解并期待后续的 TiDB 版本。
感谢反馈和建议！
对于这一点，我有不同的想法：
tidb几次心跳内无法加载最新的schema就导致tidb服务不可用。
建议整个选项，或者优化这个机制，如果没有ddl的job，就不需要同步schema了。
在这种情况下，我个人会更担心 “这个 TiDB-server 为什么不能加载 schema”，很可能是 TiDB 与 PD/TiKV 之间的通信出现了问题，在这种情况下，即便我们不同步 Schema，TiDB 很可能也无法正常工作。
想象一下，这时候 TiDB 很可能无法确认 “是否真的没有 DDL Job”，相应地，也不敢跳过 “是否需要同步 Schema” 的检查。
2 个赞
比如说tikv很忙，确实没忙过来，导致tidb加载schema失败。tidb就完全拒绝服务了。这个不科学，一个tikv很忙，其他tikv可以继续提供部分服务，不至于某个tidb上所有请求全部block吧。这是我们集群确实遇到的问题，一个tikv很忙，发生了oom，导致整个tidb服务不可用，这符合tidb的设计理念吗？
至于怎么动态决定是否需要load schema，这个可以再考虑。或者干脆就一个选项，我的集群就关掉了online ddl的支持，我需要的改表结构的时候打开就行了。
